我有一些常见的功能，例如用于调用数据库的语法糖，日志记录或站点范围的信息，例如查找表。
如果我将它们放在一个站点范围的基类中，我将可以访问它们，但是以这种方式使用父类似乎是非常错误的。使用基类作为一个＆＃39;有一个＆＃39;更有意义。关系而不是＆＃39;是＆＃39;。
或者这可能是个好设计？这样做有什么问题吗？
答案 0 :(得分：3)
父类应该实例化一些基本功能，而子应该实例化差异化代码。
IMNSHO，你所描述的是对这个过程的卑鄙。
答案 1 :(得分：0)
理想情况下，您只需要可序列化的POCO类，因为它们只包含属性而没有方法。
拥有基本类的通用功能可能是一个好主意，如果你将代码放入其中，在每个子页面中都是相同的，如果没有其他好的地方。
例如，您可以将Helper方法放在基类中，但在我看来这会打破OOP。
在我看来，拥有一个派生自System.Web.UI.Page的类并替换OnInit event或其他事件中的一些逻辑是一个非常好的策略。我在各种项目中都使用过这种方法，但是我将基类中的代码限制为成员页面的全球化和逻辑（比如重定向到非公共页面）。
答案 2 :(得分：0)
我相信你所做的是错误的。
首先，对象应该专注于一项任务。无论这些功能是否被继承，在同一个类中进行数据库连接处理，日志记录或查找表似乎都非常难看。
此外，您所描述的功能似乎符合对象的确切概念，如上所述。所以，回答你的问题：是的，有一种关系似乎是一个更好的解决方案。
通常，我倾向于尝试将程序范围的可访问函数放在单独的类中。如果可能的话，我尝试使用静态方法。在这些背后有时候是单身人士，有时会有某种排队，有时甚至是完全不同的东西。尽管如此，对于这些功能而言只有一个单一的起源点，代码非常灵活。如果静态方法不适用，特别是当需要在这样的帮助程序类中存储某些信息时，我才会为其他类的每个实例实例化一个对象。即使那时工厂/池单点原点静态方法通常也是个好主意。