C#类设计原则

Question

让类(名称是Catalog)不带方法，而让另一个Manager类(CatalogManager)带有用于操作Catalog对象的方法，这是一种好的实践吗？

或者，类应该有自己的方法。耽误您时间，实在对不起。

namespace ESF.Configurator.CatalogManagement
{
    public class Catalog
    {
        public Catalog()
        { 
        }

        private int _ID;
        private string _Name;
        private string _Synonym;
        private string _Description;

        public int ID
        {
            get { return _ID; }
            set { _ID = value; }
        }

        public string Name
        {
            get { return _Name; }
            set
            {
                _Name = value;
            }
        }

        public string Synonym
        {
            get { return _Synonym; }
            set { _Synonym = value; IsDirty = true; }
        }

        public string Description
        {
            get { return _Description; }
            set { _Description = value; }
        }
    }


    public class CatalogManager
    {
        public CatalogManager()
        {
        }


        public Dictionary<int, Catalog> Catalogs;

        public Catalog CreateNewCatalog()
        {
        }

        public void SaveCatalogToDB(Catalog catalog)
        {
        }


        public void CreateCatalogInDB(Catalog catalog)
        {
        }

        public void UpdateCatalogInDB(Catalog catalog)
        {
        }

        public void DeleteCatalogFromDB(Catalog catalog)
        {
        }

        public string GenerateCatalogXML(Catalog catalog)
        {
        }

        public void PopulateCatalogList()
        {
        }

        public Catalog ConvertDataRowToCatalog(DataRow dataRow)
        {
        }

        public DataSet FetchAllCatalogs(int ConfigID)
        {
        }
    }
}

Answer 1

这是可以的，所以您将模型层(目录)与控制器层(ControllerManager)分开。许多操作系统使用MVC(模型-视图-控制器)架构。

更多信息

Answer 2

我通常将任何与数据库存储相关的函数放在一个单独的类中(可能类似于CatalogRepository)，它负责任何数据库事务。Catalog类不应在其实现中混合使用存储逻辑。更好的做法是将其从类中抽象出来，例如，有一天您可能希望更改正在使用的数据库(例如，从SQL Server到SQLite)。从您的类实现中抽象出数据库事务逻辑意味着您的类不需要知道(或关心)您是写入文本文件还是存储在数据库中。

此外，像"CreateNewCatalog“这样的函数可能更适合放在工厂中(比如CatalogFactory)。它将负责构建一个Catalog并将其返回给您，因为您已经需要一个Catalog实例来使用上面的代码调用"CreateNewCatalog“。

因此，在回答您的问题时，与持久化和创建有问题的类相关的任何函数都不应该包含在该类中，而应该由另一个类(或多个类)负责，就像您对CatalogManager所做的那样。

Answer 3

您通常希望您的类具有高内聚性，这就是为什么让模块的所有方法都位于其内部更好的原因。但我要提到一些警告，将行为委托给另一个类是一种优势。首先，看看下面的定义(来自Wikipedia )。

在计算机编程中，内聚是指模块的元素属于一起的程度。

然而，为了解决一些编程问题*，你可能会牺牲你的内聚性来解耦你的模块，或者让它们变得可扩展(*OCP原则)。我们通过委托来实现这一点。

*一个特定问题/问题的众所周知的解决方案，也就是设计模式，就是策略模式。此模式将其行为(也称为行为模式)从一个类委托给另一个类，允许在运行时更改此行为/算法。这是一个将方法与类分离的示例。

*在OOP中，模块应该是开放的可以扩展的，关闭的可以修改的。这是Open/closed principle (=OCP)。您可以使用继承而不是策略模式。但这样做是将行为耦合到模块。这不一定是不好的，但为了让算法独立变化，并将您的客户端耦合到接口(抽象)而不是实现(实现)，可以使用Strategy模式。这样，你的客户就不会经历任何与变化相关的剧变。

关于你的例子，如果你有很好的理由将你的CROUD行为委托给"CatalogManager“来分离关注点(SoC) -那就去做吧。你应该问自己：“它解决了我存在的任何问题吗？”