在制作可扩展和/或可插入的 cms 时，有哪些值得继承的好东西？
我可以看到创建数据库连接类在哪里有帮助，扩展该类，在任何地方使用它，更改一个位置，用它提交查询，等等。但是，除了数据库连接类、数据库设置、路径设置之外，您希望从顶级类继承什么类型的东西？
为什么 CMS 构建者让您必须继承该顶级类？我想任何人都可以破解一个页面并将原始 php 放入其中并使其工作，但不是按照其设计的方式......但除此之外，设计师“让”你继承该类。有没有一种方法可以构建一个接口来检查您是否确实像您应该的那样继承？
我试图弄清楚到底是什么让继承任何东西都是值得的。是否还有更多扩展或插入模块的内容？这到底意味着什么？
I can see where creating a database connection class is helpful, extend that class, use it wherever, change one place, submit queries with it, and so on. But, other than a database connection class, db settings, path setting, what would be the sort of thing that you would want to inherit from the top level class?
and why do CMS builders make it so that you have to inherit from that top class? I guess anyone can hack a page and put raw php in it and make it work but not in the fashion it was designed to do....but other than that the designer "makes" you inherit that class. Is there a way to build in an Interface that check to see if you did indeed inherit like you were supposed to?
I'm trying to figure out what exactly makes it worthwhile to inherit anything. Is there more to extending or plugging in modules and what that really means?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我通常认为 CMS 系统特有的 OO 继承的两个原因与持久性和表示层次结构有关。
如果您处理的系统有自己的 ORM 类型，那么持久性就会发挥作用。通过这种方式，您可以轻松地对实体进行 CRUD 和查询，而无需创建新表。它还更容易地为定义不同类型实体之间的关系提供了机会，例如文件夹类可能具有返回其他实体数组的 getContents 方法。
层次结构通过具有需要指定父实体的基本类型来发挥作用。大多数 CMS 系统严重依赖于以某种父子方式表示内容或直接对文件夹结构进行建模。因此，基类中的这种质量确保了遵守。
就界面而言，实际上取决于您使用的语言。如果您有一个弱类型系统，那么只要您的对象实现了正确的方法，您就不需要实现接口。如果您实际上正在扩展一个具体的顶层，您可能会发现挖掘其内部算法以实现上述持久性并通过其中的层次结构进行解析。
The two reasons I usually see for OO inheritance particular to CMS systems have to do with persistence and representing hierarchy.
Persistence comes into play if you're dealing with a system that has its own sort of ORM. In this way you can easily CRUD and query entities without the need for new tables. It also more easily opens up opportunities for defining relationships between different types of entities, such that a folder class might have a getContents method that returns say an array of other entities.
Hierarchy comes into play by have a base type that requires specifying a parent entity. Most CMS systems rely heavily on representing content in some sort of parent child fashion or modeling a folder structure directly. So, this type of quality in a base class ensures adherence.
As far as interfaces are concerned, really depends on language you're using. If you have a weakly typed system, then so long as your objects implement the correct methods you need not implement an interface. If you are actually extending a concrete top level, you'd probably find digging around its innards algorithms for the aforementioned persistence and parsing through hierarchy therein.