【抽象那些事】 命令式抽象

命令式抽象

这种坏味是由操作转换为类引起的，表现为类中只定义了一个方法，有时候类名和方法名相同。这种坏味还常常表现为方法操作的数据位于另一个类中。

为什么不能命令式抽象？

面向对象的基本原则是，识别真实世界中的事物，并使用抽象来表示它们。在解决方案域中，必须将问题域的对象表示出来，为此可采用映射域实体这一实现手法，抽象的每个类都必须封装数据和相关的方法。只包含一个操作的类根本不是抽象，其操作的数据位于其它地方时尤其如此。这样很多操作相同数据的方法位于不同的类中，减低了类的内聚性，违反了封装和模块化原则。

命令式抽象潜在的原因

过程式思维

数据和操作这些数据的方法被封装在不同类中，典型的过程式思维。

示例分析

来看报表生成功能，它使用了CreateReport、CopyReport、DisplayReport等类。其中每个类只包含一个方法。与报表相关的数据项，如报表名称等都放在了Report类。很显然程序中存在“命令式抽象”，这种坏味不仅增加了类的数量（至少4个类，理想情况下只需要1个类），而且内聚的方法进行了分离，增加了开发和维护的复杂性。该设计采取的是“功能分解”，而非“面向对象分解”。

public class Report
{
    public string ReportName { get; set; }
}

public class CreateReport
{
    public void Create()
    {
        //Create
    }
}

public class DisplayReport
{
    public void Display()
    {
        //Display
    }
}

public class CopyReport
{
    public void Copy()
    {
        //Copy
    }
}

重构：我们将所有存在“命令式抽象”坏味的类中的方法都移到Report类中，那么Report类就变成了一个恰当的抽象，同时消除了“命令式抽象”坏味。

重构后的实现：

public class Report
{
    public string ReportName { get; set; }

    public void Create()
    {
        //Create
    }
    public void Display()
    {
        //Display
    }
    public void Copy()
    {
        //Copy
    }
}

现实考虑

具体化

具体化指的是将不是对象的东西提升为对象。将行为具体化后，便可对其进行存储、传递和转换。具体化可提高系统的灵活性，但是代价是增加了系统的复杂度。

很多设计模式都使用了具体化：状态模式、命令模式、策略模式。

扫描二维码关注公众号，回复： 111985 查看本文章

为了提高可重用性、灵活性和可扩展性而有意识地将原本不是对象的东西提升为对象，这不能算是坏味。

参考：《软件设计重构》

作者： 喜欢天黑却怕鬼

来源：http://songwenjie.cnblogs.com/

声明：本文为博主学习感悟总结，水平有限，如果不当，欢迎指正。如果您认为还不错，不妨点击一下下方的 【推荐】按钮，谢谢支持。转载与引用请注明出处。