关于C#中内部类的使用和结构的最佳实践是什么?
例如,如果我有一个非常大的基类和两个大的内部类,我应该将它们分成单独的(部分类)代码文件,还是将它们作为一个非常大的笨重的代码文件?
具有抽象类的公共继承内部类也是不好的做法吗?
STW*_*STW 25
通常我会为两个目的之一保留内部类:
从其父类派生的公共类,其中父类是具有一个或多个抽象方法的抽象基础实现,每个子类是为特定实现提供服务的实现.在阅读框架设计和指南之后,我看到它被标记为"避免",但我在类似于枚举的场景中使用它 - althogh也可能给人留下不好的印象
内部类是私有的,是业务逻辑的单元,或者以其他方式紧密耦合到它们的父类,它们在被任何其他类消费或使用时从根本上被破坏.
对于所有其他情况,我尝试将它们保持在与其使用者/逻辑父代相同的名称空间和相同的可访问性级别 - 通常使用比"主"类稍微不友好的名称.
在大型项目中,您会惊讶地发现自己最初构建一个强耦合组件的频率是因为它的第一个或主要目的使它看起来合乎逻辑 - 但除非您有非常好或技术上的理由将其锁定并隐藏从视线开始,暴露课程几乎没有什么害处,以便其他组件可以消耗它.
编辑请记住,即使我们谈论的是子类,它们应该是设计得很好或松散耦合的组件.即使它们是私有的,也是外部世界不可见的,在类之间保持最小的"表面区域"将极大地简化代码的可维护性,以便将来扩展或更改.
Tim*_*son 18
我没有这本书,但框架设计指南建议使用public内部类,只要客户不必引用类名.private内部阶级很好:没有人会注意到这些.
坏: ListView.ListViewItemCollection collection = new ListView.ListViewItemCollection();
好: listView.Items.Add(...);
关于你的大班:通常值得将这样的东西分成更小的类,每个类都有一个特定的功能.最初很难打破它,但我预测它会让你以后的生活变得更轻松......
通常,内部类应该是私有的,并且只能由包含它们的类使用.如果他们的内部类非常大,则表明他们应该是他们自己的类.
通常当你有一个很大的内部类时,因为内部类与它的包含类紧密耦合,需要访问其私有方法.
我认为这是相当主观的,但我可能会通过使"主机"类部分而将它们拆分为单独的代码文件.
通过这样做,您可以通过编辑项目文件来获得更多概述,使文件组与Windows窗体中的设计器类一样.我想我已经看过一个Visual Studio插件,可以自动为你做这个,但我不记得在哪里.
编辑:
经过一番看,我找到了Visual Studio加载项,用于执行此操作,称为VSCommands
仅关于如何构建这样的野兽......
您可以使用部分类来拆分主类和嵌套类.当您这样做时,建议您适当地命名文件,以便明显发生了什么.
// main class in file Outer.cs
namespace Demo
{
public partial class Outer
{
// Outer class
}
}
// nested class in file Outer.Nested1.cs
namespace Demo
{
public partial class Outer
{
private class Nested1
{
// Nested1 details
}
}
}
Run Code Online (Sandbox Code Playgroud)
以同样的方式,您经常在自己的文件中看到(显式)接口.例如,Outer.ISomeInterface.cs而不是编辑器默认#region他们.
您的项目文件结构然后开始看起来像
/Project/Demo/ISomeInterface.cs /Project/Demo/Outer.cs /Project/Demo/Outer.Nested1.cs /Project/Demo/Outer.ISomeInterface.cs
通常,当我们这样做时,它就是Builder模式的变体.
| 归档时间: |
|
| 查看次数: |
48200 次 |
| 最近记录: |