有哪些可扩展性设计模式以及它们的优缺点是什么？
我正在开发一个新的 CMS 系统，我希望它的核心能够针对特定客户进行扩展或覆盖。 那里的信息稀疏，或者我看起来不够好，但我想要双手-来自其他开发人员的经验。
I'm working on a new CMS system and I want it's core to be extended or overwritten for specific customers.
The information out there is sparse, or I haven't been looking good enough, but I want hands-on experience from fellow developers.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在设计 CMS 时，您可能正在寻找的是它的可插拔性。您的扩展点是否经过精心构思和思考？查看以下可扩展性方面的链接
对于设计方面的标准模式，例如开放/关闭原则、接口隔离 原则应该有帮助。
最终，它涉及您的 CMS 的可插拔程度以及核心 CMS 的使用者必须付出多少努力来添加新组件。您可能还会发现此 stackoverflow 主题很有用。
What probably you are looking for when designing a CMS is how pluggable it is. Are your extension points well conceived and thought of. Check out following links for the extensibility aspect
For the design aspect standard patterns like Open/Close Principle, Interface Segregation Principle should help.
Ultimately its about how much pluggable your CMS is and how much effort your consumers of core CMS have to put in to add the new components. You may also find this stackoverflow thread useful.
首先听起来很复杂。然而，在我看来，它可以通过简单地遵循基础知识来实现。在开发框架时，您应该重点关注以下内容 -
努力实现模块化设计 - 始终针对接口进行编码，支持组合而不是继承等。
为所有代码编写单元测试 - 这非常重要，因为测试不仅会引导您进行松散耦合的设计，而且在验证向后兼容性方面也很重要，这是此类项目中的一个重要问题。
仅构建需要的内容，避免过多的前期设计和过度设计 -请注意，框架最好从代码中提取，而不是预先构建。在这样的项目中，很容易得意忘形并构建不需要的东西。不需要的功能不仅会浪费时间和金钱，而且还会使将来的更改变得困难。不要做太多的前期设计并以小迭代的方式构建东西，经常重构并使用单元测试作为你的安全网。
To start with it sounds complex. However, IMO it can be achieved by simply following the basics. While you develop your framework you should have strong focus on following -
Strive for modular design - Always code to interfaces, favor composition over inheritance etc.
Write Unit Tests for all code - This is very important as tests will not only guide you towards loosely coupled design but also will prove important in verifying backward compatibility, which is an important issue in such projects.
Build only what is needed and avoid too much upfront design and over-designing - Note that frameworks are best extracted from code rather than built up-front. In such projects it is very easy to get carried away and build something that is not needed. Unwanted features will not only waste time and money but will also make it difficult to make future changes. Don't do too much upfront design and build things in small iterations, refactor often and use unit-tests as your safety net.