2015-07-10 55 views
1

让类(名称为Catalog)没有方法,并让另一个Manager类(CatalogManager)具有用于操作Catalog对象的方法是好习惯吗?C#类的设计原理

或者,类应该有自己的方法。谢谢你的时间。

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) 
     { 
     } 
    } 
} 
+0

为什么在每个方法名称中包含'Catalog'?该课程仅用于目录,对吗?在类名中有'Catalog'就足够了。 – jgauffin

+0

我总是坚持一个非常简单的想法:以“逻辑”方式分离功能的代码最少的解决方案通常是最佳解决方案。更少的代码通常更快,更容易维护。在你的问题中,我的答案是“那要看”。 – atlaste

回答

1

它可能没问题,因此您将模型图层(目录)与控制器图层(ControllerManager)分开。许多操作系统使用MVC(模型 - 视图 - 控制器)架构。

更多信息here

1

我一般都在一个单独的类(可能像CatalogRepository),这是对任何数据库事务与数据库存储的任何功能。您的Catalog类不应该在其实现中混合使用存储逻辑。将此类从类中抽象出来是比较好的做法,例如有一天您可能希望更改您正在使用的数据库(比如说从SQL Server到SQLite)。将数据库事务逻辑从您的类实现中抽象出来意味着您的类不需要知道(或关心)您是写入文本文件还是存储在数据库中。

此外,像“CreateNewCatalog”这样的函数可能会更好地位于工厂(比如CatalogFactory)。它将负责构建目录并将其返回给您,因为您已经需要使用上述代码来调用“CreateNewCatalog”目录的实例。

因此,在回答你的问题时,任何与持久化和创建有问题的类相关的函数都不应该包含在该类中,而应该是另一个类(或类)的责任,就像您使用CatalogManager 。

0

你会居多更喜欢你的类具有高度的凝聚力,这就是为什么最好让模块的所有方法都在它自己之内。但是我会提到一些警告,将行为委托给另一个班级是一个优势。首先,看看下面的定义(从Wikipedia)。

在计算机编程中,内聚是指模块的元素所属的程度。

然而,解决一些编程问题*,你可能会牺牲自己的凝聚力,以解耦模块或让他们可扩展的(* OCP原则)。我们通过授权实现这一点。

*特定问题/问题的一种众所周知的解决方案,a.k.a一个设计模式,是策略模式。这个模式将它的行为(也称为行为模式)从一个类委托给另一个类,让这个行为/算法在运行时被改变。这是从类中分离方法的一个例子。

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


关于你的例子,如果你有你的委托行为CROUD的“CatalogManager”一个很好的理由来分离关注(SoC) - 去了。你应该问你的问题:“它解决了我现有的任何问题吗?”。

0

下面是您可能需要考虑的示例。

using System; 
using System.Collections.Generic; 
using System.Linq; 
using System.Text; 
using System.Threading.Tasks; 

namespace TestOnly 
{ 
    public class TestClass 
    { 

     public void Test() 
     { 
      Catalog catalog = new Catalog(); 

      //Perform save 
      SaveCatalogAction save = new SaveCatalogAction(); 
      save.Catalog = catalog; 
      CatalogManager.Do(save); 

      //Perform delete 
      DeleteCatalogAction delete = new DeleteCatalogAction(); 
      delete.Catalog = catalog; 
      CatalogManager.Do(delete); 

      //Perform update 
      UpdateCatalogAction update = new UpdateCatalogAction(); 
      update.Catalog = catalog; 
      CatalogManager.Do(update); 
     } 

    } 

    public class Catalog 
    { 
     public int Id { get; set; } 
     public int Name { get; set; } 
    } 

    public class CatalogManager 
    { 
     static public void Do(CatalogAction catalogAction) 
     { 
      catalogAction.Perform(); 
     } 
    } 

    public abstract class CatalogAction 
    { 
     //Note we can move this CatalogList to somewhere appropriate (like in CatalogManager) it's here for sake of simplicity 
     public Dictionary<int, Catalog> CatalogList = new Dictionary<int, Catalog>(); 
     public Catalog Catalog { get; set; } 

     public abstract void Perform(); //Or you can put the Catalog as parameter 
    } 

    public class SaveCatalogAction : CatalogAction 
    { 

     public override void Perform() 
     { 
      //Do saving with catalog 
      if (base.Catalog != null) 
      { 
       //Save 
       base.CatalogList.Add(base.Catalog.Id, base.Catalog); 
      } 
     } 
    } 

    public class DeleteCatalogAction : CatalogAction 
    { 

     public override void Perform() 
     { 
      //Do deleting 
      if (base.Catalog != null) 
      { 
       //Delete (note no checking just to make it simple) 
       base.CatalogList.Remove(base.Catalog.Id); 
      } 
     } 
    } 

    public class UpdateCatalogAction : CatalogAction 
    { 

     public override void Perform() 
     { 
      //Do updating 
      if (base.Catalog != null) 
      { 
       //Update (note no checking just to make it simple) 
       base.CatalogList[base.Catalog.Id] = base.Catalog; 
      } 
     } 
    } 
} 

几点:

  • 目录对象(可能是持久的),我想会更好,如果所有的只是性。就像你拥有的那个一样。
  • 让管理员像CatalogManager一样执行上述操作。
  • 将每个目录操作都放在一个类上,以避免臃肿的代码。在设计课程时请记住:https://en.wikipedia.org/wiki/Single_responsibility_principle

希望这种模式有帮助!