我有常用的功能，例如调用数据库的语法糖、记录或站点范围的信息，例如查找表。
如果我将它们放在站点范围的基类中，我将可以访问它们，但是以这种方式使用父类在直觉上似乎是错误的。将基类用作“具有”关系而不是“是”关系会更有意义。
或者也许这是一个好的设计？这样做有什么问题吗？
问问题
148 次
3 回答
3
父类应实例化一些基本功能，子类应实例化区分代码。
IMNSHO，您所描述的是该过程的混蛋。
于 2013-01-09T16:41:43.120 回答
0
理想情况下，您只想序列化 POCO 类，因为它们只包含属性而没有方法。
拥有一个通用功能的基类可能是一个好主意，如果您将代码放入其中，那么在每个子页面中都是相同的，并且如果没有其他好地方。
例如，您可以将 Helper-methods 放在基类中，但我认为这会破坏 OOP。
在我看来，拥有一个派生自System.Web.UI.Page并替换OnInit event事件或其他事件中的某些逻辑的类是一个非常好的策略。我在各种项目中都使用了这种方法，但我将 baseblas 中的代码限制为成员页面的全球化和逻辑（如重定向到非公共页面）。
于 2013-01-09T16:42:48.637 回答
0
我相信你的做法是错误的。
首先，对象应该专门用于一项任务。在同一个类中拥有数据库连接处理、日志记录或查找表似乎非常难看，无论这些功能是否被继承。
此外，如上所述，您描述的功能似乎符合对象的确切概念。所以，回答你的问题：是的，has-a 关系似乎是一个更好的解决方案。
一般来说，我倾向于尝试将程序范围内可访问的函数放在单独的类中。如果可能，我尝试使用静态方法。这些背后有时是单例，有时是某种队列，有时是完全不同的东西。尽管如此，对于这些功能只有一个原点，代码非常灵活。如果静态方法不适用，特别是当需要在此类帮助类中存储一些信息时，我才会为其他类的每个实例实例化一个对象。即使这样，工厂/池单源静态方法通常也是一个好主意。
于 2013-01-09T16:54:11.360 回答