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

发布于 2024-11-27 03:16:31 字数 1393 浏览 0 评论 0原文

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

我有一系列 TableItemGroup 类:AccountTableItemGroup、PendingVoteTableItemGroup 和 RequestingVoteTableItemGroup。每个TableItemGrup都包含一个字符串SectionName和一个对应TableItem的List...这样:

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 的接口?我知道使用接口或抽象类最适合编码标准,但我不知道它会如何减少我将拥有的代码量?

非常感谢您的帮助。

I have this C# class structure that I would like to refactor to use best coding standards (use interfaces/abstract classes) so it can be more maintainable and reusable. The code as it is right now isn't awful, but it's not ideal.

I have a series of TableItemGroup classes: AccountTableItemGroup, PendingVoteTableItemGroup, and RequestingVoteTableItemGroup. Each TableItemGrup contains a string SectionName and a List for its corresponding TableItem ...as such:

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()
    {
    }
}

In the future there will be many more TableItemGroups and if they are all the same except for the List part, I don't want to have to copy the code and create a new Group every time and make that small change. I know there must be a better way. I would like to keep using the List<> generics so I don't have to cast anything later though.

The other part are the TableItems. I have AccountTableItem, PendingVoteTableItem, and RequestingVoteTableItem. The TableItems are different from each other, but they each share three common strings -- TitleLabel, DetailLabel, and ImageName. But after that, each TableItem may or may not have additional properties or methods along with it ..as such:

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()
    {
    }
}

So my question to all of you is, how do I redefine my class structure to allow for as much reuse of code as possible and to use best coding standards?

I was thinking of having an abstract TableItem class or use an interface for the TableItemGroup? I know that using an interface or an abstract class is best for coding standards, but I don't see how it would cut down on the amount of code I will have?

Thanks a lot for any help.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

梦幻的味道 2024-12-04 03:16:31

抽象出您的表项,将必要的字段添加到接口或基类中:

    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>();
        }
    }

Abstract away your table item adding necessary fields to the interface or base class:

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

Then can you make your item group generic with a constraint on generic parameter.

    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>();
        }
    }
你的背包 2024-12-04 03:16:31

考虑使用泛型来表示 TableItemGroup 容器,并为您的 TableItem 创建一个基类,您可以从该基类继承特定类型的表格项。如果您直接从 List 继承,则可以将项目组视为集合,而不必像在现有设计中那样使用 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 });

Consider using generics to represent the TableItemGroup container, and make a base class for your TableItem, which you can inherit from for specific types of table item. If you inherit directly from List<T>, then you can treat your item group as a collection without having to use the Items property as in your existing design.

There's not much point in using interfaces for these sorts of types. As they stand they are data classes so have no behavior. If they had behavior, using interfaces would make sense as you would then be able to change implementations and so vary behavior.

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; }
}

Now that we have a generic TableItemGroup container, you can re-use this for all TableItem types. Having a base class for TableItem again gives you some re-use.

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

items.Add(new AccountTableItem { SwitchSetting = true });
腹黑女流氓 2024-12-04 03:16:31

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

Unless you want users to be able to add and remove new lists at will, you should make the setter on the items list protected. Users will still be able to add and remove items, but not create a reference to a new list.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文