Question

我仍在尝试分析函数的分离以及它如何应用于类创建和命名空间包含。我有一个自定义类SoftwareComponent，当呈现给用户时，通常会显示为ListItem。创建ToListItem方法是个好主意吗？我担心，因为我现在已经在类中放置了一个依赖项，需要包含System.Web.UI.WebControls命名空间。

    public ListItem ToListItem()
    {
        ListItem li = new ListItem();
        li.Text = ComponentName + " (+" + ComponentCost + ")";
        li.Selected = Selected;

        return li;
    }

我的另一个倾向是根据类本身之外的属性从SoftwareComponent创建ListItem。请提供关于哪种方法更合适/更好的想法。

Answer 1

你能否提供这种额外的方法作为扩展方法？它似乎更适合作为实用程序类的一部分，可以通过创建提供此功能的静态方法作为选择，而不是将其作为第一类方法提供在主类上。

public static class SoftwareComponentExtensions
{
    public static ListItem ToListItem(this SoftwareComponent component)
    {
        ListItem li = new ListItem(component.ComponentName + " (+" + component.ComponentCost + ")");
        li.Selected = component.Selected;

        return li;
    }
}

Answer 2

听起来像SoftwareComponent是一个域对象 - 一个描述应用程序所在世界中“事物”的对象。

我尽量避免让这些域对象依赖于域外的任何东西 - 这可能是较低级别（如何存储？是序列化？存储在数据库中）还是在UI级别。

我同意很难这样做，通常最终会有单独的类层次结构来管理--ii类，数据库映射等等。因此，根据您构建的东西的大小，在域对象中包含UI或数据库代码或保留内容是一种权衡。

针对具体问题，您已经了解了C＃3.5扩展方法。它们很容易使静态方法看起来像是在类中定义的 - 只要它们不访问私有/受保护的东西（它们只能访问公共方法，就像任何其他方法一样），你可以使用它们。我将它们用于你想要做的事情（域对象的UI级别“方法”），但是。

但请记住，扩展方法对于静态类中的旧静态方法来说只不过是语法糖。

Answer 3

我不会让SoftwareComponent了解ListItems等。显然，某人必须知道如何使用SoftwareComponent并将其碎片插入ListItem，但我认为这不是SoftwareComponent的关注点。

问问自己每次需要为另一个UI元素工作或者从其属性构造一些新类时是否要添加新的ToXYZ（）方法。不太可能，我猜。

类设计C＃命名空间分离

3 个答案: