我是否应该在父/基类中存储常见功能

我有一些常用功能，例如调用数据库的语法糖，日志记录或站点范围的信息，例如查找表。我是否应该在父/基类中存储常见功能

如果我把这些放在一个站点范围内的基类中，我可以访问它们，但是这样使用父类看起来似乎是错误的。使用基类作为'有'关系而不是'是'是更有意义的。

或者这是很好的设计？这样做有什么问题吗？

来源

2013-01-09 happygilmore

父类应该实例化一些基本功能，并且子应该实例化区分代码。

IMNSHO，你所描述的是这个过程的混蛋。

来源

2013-01-09 16:41:43 KevinDTimm

谢谢。什么构成相关的“基本功能”？为什么上述描述不算数？ – happygilmore

基本功能包含您在问题中提到的'是'。例如，“Shape”是“Square”，“Circle”，“Triangle”的父类。 '安装程序'不会是上述孩子的父类，因为它没有定义任何有关它们的特性。 – KevinDTimm

理想情况下，你只想要序列化POCO类，因为它们只包含属性而没有方法。

拥有一个通用功能的基类可能是一个好主意，如果您将代码放入其中，那么在每个子页面中都是相同的，并且如果没有其他好的地方。

例如你可以把Helper-methods放在一个基类内，但是在我看来这会打破OOP。

在我看来，拥有一个源自System.Web.UI.Page的类并替换了OnInit event或其他事件中的某些逻辑是非常好的策略。我在各种项目中使用了这种方法，但是我将代码限制在全球化和成员页面的逻辑（如重定向到非公开页面）。

来源

2013-01-09 16:42:48 citronas

我相信你在做什么是错的。

首先，对象应该专用于一项任务。有了db连接处理，同一类中的日志或查找表看起来非常难看，无论这些功能是否被继承。

此外，您描述的功能看起来像拟合对象的确切想法，就像上面描述的那样。所以，回答你的问题：是的，一个关系似乎是一个更好的解决方案。

一般来说，我倾向于尝试将程序范围内的可访问功能放在单独的类中。如果可能的话，我尝试使用静态方法。在这些背后有时是单身人士，有时候会有某种队列，有时甚至完全不同。尽管如此，这些功能的单一来源点的代码非常灵活。如果静态方法不适用，尤其是当需要在这样的辅助类中存储一些信息时，才可以为其他类的每个实例实例化一个对象。即使这样，工厂/池单点来源静态方法通常是一个好主意。

来源

2013-01-09 16:54:11 Dariusz

我是否应该在父/基类中存储常见功能

回答

相关问题