0

我仍在尝试锻炼功能分离以及它如何应用于类创建和命名空间包含。我有一个自定义类 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。请就哪种方法更合适/更好提供任何想法。

4

3 回答 3

5

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

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;
    }
}
于 2009-03-10T19:32:47.340 回答
1

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

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

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

对于特定问题，您可以查看 C#3.5 扩展方法。它们是使静态方法看起来像是在类中定义的一种花招​​——只要它们不访问私有/受保护的东西（它们只能像任何其他方法一样访问公共方法），你就可以摆脱它们. 但是，我将它们用于您想做的事情（域对象的 UI 级“方法”），但这些事情在别处定义。

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

于 2009-03-10T19:32:33.863 回答
1

我不会让 SoftwareComponent 知道 ListItems 等。显然，必须有人知道如何获取 SoftwareComponent 并将其片段塞入 ListItem，但我认为这不是 SoftwareComponent 关心的问题。

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

于 2009-03-10T19:36:49.593 回答