帮助重构我的 C# 代码,使其更易于维护并使用最佳编码实践
我有这个 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 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
抽象出您的表项,将必要的字段添加到接口或基类中:
然后您可以使您的项组具有通用参数的约束,从而变得通用。
Abstract away your table item adding necessary fields to the interface or base class:
Then can you make your item group generic with a constraint on generic parameter.
考虑使用泛型来表示
TableItemGroup
容器,并为您的TableItem
创建一个基类,您可以从该基类继承特定类型的表格项。如果您直接从List
继承,则可以将项目组视为集合,而不必像在现有设计中那样使用Items
属性。对于这些类型使用接口没有多大意义。正如它们所代表的,它们是数据类,因此没有任何行为。如果它们有行为,那么使用接口就有意义,因为您可以更改实现并因此改变行为。
现在我们有了一个通用的
TableItemGroup
容器,您可以将其重新用于所有TableItem
类型。再次拥有TableItem
的基类可以让您进行一些重用。Consider using generics to represent the
TableItemGroup
container, and make a base class for yourTableItem
, which you can inherit from for specific types of table item. If you inherit directly fromList<T>
, then you can treat your item group as a collection without having to use theItems
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.
Now that we have a generic
TableItemGroup
container, you can re-use this for allTableItem
types. Having a base class forTableItem
again gives you some re-use.除非您希望用户能够随意添加和删除新列表,否则您应该保护项目列表上的设置器。用户仍然可以添加和删除项目,但无法创建对新列表的引用。
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.