面向对象的软件设计原则
我非常喜欢SOLID和DRY等软件设计原则。 OO 软件设计还存在哪些其他原则？
笔记。 我不是在寻找“评论你的代码”之类的答案，而是寻找像 鲍勃叔叔。
I am a huge fan of software design principles such as SOLID and DRY. What other principles exist for OO software design?
Note. I’m not looking for answers like "comment your code" but instead looking for OO design principles like the ones discussed by Uncle Bob.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
维基百科上的一个相当全面的列表：
http://en.wikipedia.org/wiki/List_of_software_development_philosophies
A fairly comprehensive list from Wikipedia:
http://en.wikipedia.org/wiki/List_of_software_development_philosophies
高内聚 - 您正在设计的模块的职责有多集中。
低耦合 - 模块依赖其他模块的程度。
High Cohesion - How focused are the responsibilities of the modules you are designing.
Low Coupling - The degree to which modules rely on other modules.
KISS
KISS
选择组合而不是继承，就是其中之一。
许多人，尤其是那些刚刚接触 OO 的人，当他们真正需要的只是使用组合时，就会开始扩展类。 真的，如果你问自己，新的B班是A班吗？ 如果不是，那么你不应该延长。
例如，假设我有一个
Person类、一个Car类，并且我想创建一个名为DrivenCar类的新类。 一个天真的实现会说（假设我们有多重继承）DrivenCar 是 Person 的类型吗？ 不，所以它不应该扩展 Person。 DrivenCar 是汽车吗？ 是的，所以
使用组合扩展实现是有意义的
Chose composition over inheritance, is one.
Many people, especially those new to OO will start extending classes when all they really need to is to use composition. Really if you should ask your self, is the new class B a Class A? If not then you shouldn't extend.
For example, let's say I have a
PersonClass, aCarClass, and I would like to make a new class called aDrivenCarclass. A naive implementation would be to say (let's pretend we got multiple inheritance)Is the DrivenCar a type of Person? No so it shouldn't be extending Person. Is the DrivenCar a Car? yes so it makes sense to extend
Using composition the implmentation would look like
GRASP 模式。 是的，它们看起来相当微不足道。 更像是蒸馏到其他更复杂的模式所展示的核心品质。
The GRASP patterns. Yes, they seem rather trivial. More like distillation down to core qualities that other, more involved patterns demonstrate.
YAGNI
YAGNI
界面。 大多数设计模式都是基于界面和界面的分离。 执行。
Interface. Most design patterns are based on separation of interface & implementation.
当您的 API 预计会增长时，请使用抽象类而不是接口。 在接口中添加新方法需要更改实现它的所有类。
When your API are expected to grow, use Abstract class instead of Interface. Adding a new method in Interface requires to change ALL the classes which implement it.