抽象型坏味
在软件设计中引入实际上不需要的抽象时,将导致这种坏味。
##为什么不可以有不必要的抽象?
抽象实体应该具有单一而重要的职责。如果创建的没必要或是只是为了方便,它们承担的职责微不足道,甚至没有承担任何职责,这违反了抽象原则。
##不必要的抽象的潜在原因
过程型思维常常会创建执行功能而不是表示事物的类。这种类通常只有一两个方法,而这些方法操作的数据位于独立地“数据类”中。
例如,使用"常量类"而不是枚举。这增加了不必要的类。
例如,为了表示与Customer对象相关联的客户ID,创建一个名为CustomerID的类。更好的设计是:在Customer对象中使用一个字符串来存储客户ID。
public class FormattableFlags
{
/// <summary>
/// 禁止显式实例化这个类
/// </summary>
private FormattableFlags()
{
}
/// <summary>
/// 将输出左对齐
/// </summary>
public const int LEFT_JUSTIFY = 1;
/// <summary>
/// 将输出转换为大写
/// </summary>
public const int UPPERCASE = 2;
/// <summary>
/// 要求输出使用替换类型
/// </summary>
public const int ALTERNATE = 3;
}
我们上面分析过,使用"常量类"而不是枚举,增加了不必要的类。可以使用枚举替换掉"常量类",消灭掉不必要的类。
public enum FormattableFlagsEnum
{
/// <summary>
/// 将输出左对齐
/// </summary>
LEFT_JUSTIFY = 1,
/// <summary>
/// 将输出转换为大写
/// </summary>
UPPERCASE = 2,
/// <summary>
/// 要求输出使用替换类型
/// </summary>
ALTERNATE = 3
}
一个电子商务应用程序,其中包含两个类:BestSellerBook和Book。每当客户程序要创建畅销书时,都创建一个BestSellerBook实例。在BestSellerBook内部只是将所有方法都委托给Book类,别的什么都不做。显然抽象BestSellerBook是多余的,因为其行为和抽象Book完全相同。
/// <summary>
/// 图书类
/// </summary>
public class Book
{
/// <summary>
/// 价格
/// </summary>
public decimal Price { get; private set; }
/// <summary>
/// 构造函数
/// </summary>
/// <param name="price"></param>
public Book(decimal price)
{
this.Price = price;
}
/// <summary>
/// 修改图书价格
/// </summary>
/// <param name="price">图书价格</param>
public void ModifyPrice(decimal price)
{
this.Price = price;
}
}
/// <summary>
/// 畅销图书类
/// </summary>
public class BestSellerBook
{
private Book book = null;
/// <summary>
/// 构造函数
/// </summary>
/// <param name="price"></param>
public BestSellerBook(decimal price)
{
book = new Book(price);
}
/// <summary>
/// 修改图书价格
/// </summary>
/// <param name="price">图书价格</param>
public void ModifyPrice(decimal price)
{
book.ModifyPrice(price);
}
}
对于功能有限,不值得创建的类,应将其删除。
我们可以将BestSellerBook类删除,并且在Book类中添加属性IsBestSeller。这样在客户程序创建Book实例时需要指出图书是否为畅销书,可设置属性IsBestSeller,而不用像以前那样创建BestSellerBook类的实例。
/// <summary>
/// 图书类
/// </summary>
public class Book
{
/// <summary>
/// 价格
/// </summary>
public decimal Price { get; private set; }
/// <summary>
/// 是否畅销书
/// </summary>
public bool IsBestSeller { get; private set; }
/// <summary>
/// 构造函数
/// </summary>
/// <param name="price">价格</param>
/// <param name="isBestSeller">是否畅销书</param>
public Book(decimal price, bool isBestSeller)
{
this.Price = price;
this.IsBestSeller = isBestSeller;
}
/// <summary>
/// 修改图书价格
/// </summary>
/// <param name="price">图书价格</param>
public void ModifyPrice(decimal price)
{
this.Price = price;
}
/// <summary>
/// 修改是否畅销书
/// </summary>
/// <param name="isBestSeller">是否畅销书</param>
public void ModifyIsBestSeller(bool isBestSeller)
{
this.IsBestSeller = isBestSeller;
}
}
###设计模式中的委托抽象
有些设计模式(如代理模式、门面模式和适配器模式)使用了委托,其中包含了一个看似不必要的类。例如,在对象适配器模式中,Adapter类看似只是将客户端请求委托给Adaptee类的相应方法。但是,Adapter类承担了明确而具体的职责:调整Adaptee类的接口,以满足客户端的需求。所以,判断抽象是否多余,还要具体情况具体分析。
对象适配器模式UML图
参考:《软件设计重构》
作者:撸码那些事
声明:本文为博主学习感悟总结,水平有限,如果不当,欢迎指正。如果您认为还不错,不妨关注一下下方的【微信公众号】按钮,谢谢支持。转载与引用请注明出处。
微信公众号:
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。