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

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指令来分割方法和属性.