设计原则[关闭]

Question

您在进行类设计时一般遵循哪些原则？

Answer 1

面向对象类设计原则（“SOLID”原则）

• 建议零售价：单一责任原则 一个班级应该有一个变化的理由，只有一个理由。
• 过流保护：开闭原则 您应该能够扩展类行为，而无需对其进行修改。
• LSP：Liskov替代原则 派生的类必须可以代替其基础类。
• 互联网服务提供商：界面隔离原理 制作特定于客户端的细粒界面。
• 蘸：依赖性反转原理 取决于抽象，而不是凝结。

来源： http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

Answer 2

不要忘记 德墨忒耳定律.

Answer 3

这 坚硬的。原则.
或者至少我尽量不远离他们太多。

Answer 4

最基本的设计模式应该是亲吻（保持简单的愚蠢），这意味着有时不适合某些元素的课程是正确的解决方案。

那和 CRC（类、责任、协作者）卡（将卡写在头文件中，而不是写在实际的卡上，因为它们也很容易理解文档）

Answer 5

如上所述，一些基本的面向对象设计原则是 OCP、LSP、DIP 和 ISP。

Robert C. 对这些内容进行了精彩的概述。Martin（Object Mentor 的）可以在这里找到： OOD原则和模式

Answer 6

这 ”资源获取即初始化“范例很方便，特别是在用 C++ 编写并处理操作系统资源（文件句柄、端口等）时。

这种方法的一个主要好处是，对象一旦创建，就是“完整的”——不需要两阶段初始化，也不可能出现部分初始化的对象。

Answer 7

松耦合，高内聚。

组合优于继承。

Answer 8

领域驱动设计通常是一个值得遵循的良好原则。

Answer 9

基本上我可以摆脱对接口的编程。我尝试封装因案例而变化的内容，以避免代码重复并将代码隔离为可管理的（对于我的大脑）块。稍后，如果需要，我可以很轻松地重构代码。

Answer 10

SOLID 原则和 Liskov 模式，以及单一职责模式。

Answer 11

我想添加的一件事是分层，在应用程序中定义层，层的总体责任，以及两层交互的方式。该层中只应允许与该层具有相同职责的类。这样做可以解决很多混乱，确保异常得到适当处理，并确保新开发人员知道将代码放在哪里。

另一种设计方法是将您的类设计为可配置的，创建一种机制，可以将配置插入到您的类中，而不是覆盖子类中的方法，确定哪些更改，看看是否可以配置并确保此功能从配置派生

Answer 12

我通常尝试将类放入 oo 之一 设计模式。