Question

我正在为应用程序编写基础类，并希望正确构建它们以实现长期可维护性。为此，我正在研究实现哪些设计模式，使用接口，抽象类以及将持久性与活动分离。我的脑袋里游着模式，范例和原则。

我有一个类Product，我为其创建了一个接口IProduct。我相信我需要创建Product和抽象类，因为它的任何实例都必须是属性Category的六个值之一。所以，我的第一个问题是：以下是适当的方法吗？

abstract class Product : IProduct
{
    // Fields
    // Properties
    // Methods
}

interface IProduct
{
    // Properties
}

public class Model : IProduct
{
    public Model()
    {
        Category = "Model";
    }

    // Model-specific fields
    // Model-specific properties
    // Model-specific methods
}

我读过的文章，包括此前回答的问题，表明我应该设计属性和方法的分离（持久性和活动性）。为此，上面的代码真的应该是这样的吗？

abstract class Product : IProduct
{
    // Fields
    // Properties
    // Methods
}

interface IProduct
{
    // Properties
}

public partial class Model : IProduct
{
    public Model()
    {
        Category = "Model";
    }

    // Model-specific fields
    // Model-specific properties
}

public partial class Model : IProduct
{
    // Model-specific methods
}

当然，这假设我的第一部分是正确的，但也许答案会启发我如何做事。

最后，如果属性和方法的分离是一件好事，并且Product有一些适用于它的所有具体版本的方法，我应该将它们移动到这样的单独的抽象类吗？

abstract class Product : IProduct
{
    // Fields
    // Properties
}
abstract class Product : IProduct
{
    // Methods
}

Answer 1

我在保持partial类时看到的唯一用途是当两个独立的系统更新这两个文件时。例如，当使用Visual Studio设计器（例如Windows窗体设计器）更新自己的类文件时就是如此。对于您拥有的另一个自动生成的类，另一件事情可能是真的。一个由系统维护，一个由您维护。

我从来没有想过要自己维护两个单独的partial类文件。我通常使用#region指令来分割方法和属性。

Answer 2

我个人更喜欢将基于语义和基于可见性的方法结合到一个类中对成员进行排序。实际上，我不知道是谁发明了＆＃39;根据语言实体的类型（即组中的字段，组中的属性等）对成员进行排序的规则。这在可读性方面几乎没有任何意义。

使用#region指令将它们分开是个好主意。此外，我倾向于使用水平线（------…---）来使代码更具可读性。

示例：

public class SomeClass : ParentClass, ISomeInterface
{
    #region ------ Large feature 1 ----------------------------
    … // any non-private members related to 'Large feature 1' go here
    #endregion

    #region ------ Large feature 2 ----------------------------
    … // any non-private members related to 'Large feature 2' go here
    #endregion

    #region ------ Implementation of ISomeInterface -----------
    … // ISomeInterface implementation goes here, comments are *not* repeated
    #endregion

    #region ------ ParentClass overrides ----------------------
    … // parent class members' overrides go here, comments are *not* repeated
    #endregion

    #region ------ Internals ----------------------------------
    … // any private members, i.e. the actual implementation
    #endregion
}

除非您确实需要将它们放在单独的文件中，否则没有理由过度使用部分声明。一个很好的理由是当一部分类是自动生成的。但是，仅仅为了分离成员而使用部分声明远比一致使用区域更难以阅读和维护。

另外，我不喜欢分离属性声明和相应的后备字段声明（如果你不能使用自动属性）。以下内容更具可维护性和可读性：

public int SomeProperty
{
    get { … return someProperty; }
    set { someProperty = value; … }
}
private int someProperty;

我应该在分部类中分离属性和方法吗？

2 个答案: