帮助重构我的 C# 代码，使其更易于维护并使用最佳编码实践答案

【问题标题】：Help refactor my C# code to be more maintainable and to use best coding practices帮助重构我的 C# 代码，使其更易于维护并使用最佳编码实践
【发布时间】：2011-07-29 13:27:20
【问题描述】：

我有这个 C# 类结构，我想重构它以使用最佳编码标准（使用接口/抽象类），以便它更易于维护和重用。现在的代码并不糟糕，但并不理想。

我有一系列 TableItemGroup 类：AccountTableItemGroup、PendingVoteTableItemGroup 和 RequestingVoteTableItemGroup。每个 TableItemGrup 都包含一个字符串 SectionName 和一个与其对应的 TableItem 的列表 ...例如：

public class AccountTableItemGroup {
    public string SectionName { get; set; }

    public List<AccountTableItem> Items
    {
        get { return this._items; }
        set { this._items = value; }
    }        
    public List<AccountTableItem> _items = new List<AccountTableItem>();

    public AccountTableItemGroup()
    {
    }
}

将来会有更多的 TableItemGroups，如果除了 List 部分之外它们都相同，我不想每次都复制代码并创建一个新组并进行微小的更改。我知道一定有更好的方法。我想继续使用 List 泛型，所以我以后不必再转换任何东西了。

另一部分是 TableItems。我有 AccountTableItem、PendingVoteTableItem 和 RequestingVoteTableItem。 TableItem 彼此不同，但它们各自共享三个公共字符串——TitleLabel、DetailLabel 和 ImageName。但在那之后，每个 TableItem 可能有也可能没有额外的属性或方法......就像这样：

public class AccountTableItem
{
    public string TitleLabel { get; set; }

    public string DetailLabel { get; set; }

    public string ImageName { get; set; }

    public bool SwitchSetting { get; set; }

    public AccountTableItem()
    {
    }
}

所以我对你们所有人的问题是，我如何重新定义我的类结构以允许尽可能多地重用代码并使用最佳编码标准？

我想有一个抽象的 TableItem 类或使用 TableItemGroup 的接口？我知道使用接口或抽象类最适合编码标准，但我不明白它会如何减少我将拥有的代码量？

非常感谢您的帮助。

【问题讨论】：

标签： c# class coding-style class-design class-structure

【解决方案1】：

抽象出你的表项，向接口或基类添加必要的字段：

    interface ITableItem // or just a simple or abstract class
    {
        // common fields go here
    }

那么您能否通过对通用参数的约束使您的项目组通用。

    public class ItemGroup<T> where T: ITableItem
    {
        public string SectionName { get; set; }

        public List<T> Items { get; private set; }

        public ItemGroup()
        {
            Items = new List<T>();
        }
    }

【讨论】：

【解决方案2】：

考虑使用泛型来表示TableItemGroup 容器，并为您的TableItem 创建一个基类，您可以从中继承特定类型的表项。如果您直接从List<T> 继承，那么您可以将您的项目组视为一个集合，而不必像在现有设计中那样使用Items 属性。

为这些类型使用接口没有多大意义。按照他们的立场，它们是数据类，所以没有行为。如果他们有行为，那么使用接口将是有意义的，因为您将能够更改实现并因此改变行为。

public class TableItemGroup<T> : List<T> where T : TableItem
{
    public TableItemGroup(string sectionName)
    {
        SectionName = sectionName;
    }

    public string SectionName { get; private set; }
}

public class TableItem
{
    public string TitleLabel { get; set; }

    public string DetailLabel { get; set; }

    public string ImageName { get; set; }
}

public class AccountTableItem : TableItem
{
    public bool SwitchSetting { get; set; }
}

现在我们有了一个通用的TableItemGroup 容器，您可以对所有TableItem 类型重复使用它。再次为TableItem 提供一个基类可以让您重用。

var items = new TableItemGroup<AccountTableItem>("Accounts");

items.Add(new AccountTableItem { SwitchSetting = true });

【讨论】：

我真的很喜欢这种方法。尤其是继承自 List 的 TableItemGroup。问题：我是否必须为所有 TableItems 提供实现，即使它们不添加其他属性？就像“public class OptionsTableItem: TableItem { }”...把它留空，或者我根本不需要实现它？谢谢。
@Apex 如果您遇到TableItem 将提供所有必需属性的情况，请删除abstract 修饰符。这样就可以直接使用TableItem，无需继承。
感谢 Chibacity。对我成为更好的程序员的巨大帮助:)

【解决方案3】：

除非您希望用户能够随意添加和删除新列表，否则您应该使项目列表上的设置器受到保护。用户仍然可以添加和删除项目，但不能创建对新列表的引用。

【讨论】：