Design Principles
Why bother?
- Correctness 正确性
- Maintainability 可维护性
What we want:
- understandable programs/functions/classes/...
- compiler as correctness checker if it compiles it will (almost certainly) be correct!
interfaces should be easy to use correctly and hard to use incorrectly. - Scott Meyers
Common Sources of Bad Design 坏设计的常见来源
The road to (code) hell is paved with good intentions:
通往（代码）地狱的道路是由良好的意图铺成的。
- trying too hard to anticipate future changes
太过努力去预测未来的变化 - class interfaces and interactions too closely modeled after real-world or abstract math objects
类的界面和互动太过接近于现实世界或抽象数学对象的模式 - trying to build the ultimate and universal system or inheritance hierarchy that can do/describe/model anything
试图建立一个终极的、通用的系统或继承权 层次结构，可以做/描述/模拟任何事情 - trying to "abstract away" hardware restrictions
试图 "抽象化 "硬件限制
Common Manifestations of Bad Design 不良设计的常见表现形式
- inconsistent naming
命名不一致 - inheritance used to avoid data redundancy
用继承来避免数据冗余 - setter/getter-for-every-member
每一个成员的设置器/获取器 - classes or functions with way more than one purpose ("god classes", 1000-line functions with 10 if-levels)
类或函数的目的远不止一个 ("神类"，有10个if-levels的1000行函数) - functions with many parameters (often of the same type)
有许多参数的函数（通常是同一类型的） - interfaces that expose (too much) implementation details
暴露（太多）实现细节的接口 - deep inheritance hierarchies
深度继承层次结构 - hyper-flexible and ultra-modular systems with a gazillion of possible ways to let objects interact with each other
超灵活和超模块化的系统，有无数的 让对象之间相互作用的可能方式
Make Your Intent Clear & Avoid Confusion 明确你的意图，避免混淆
- unambiguous & consistent naming
毫不含糊的、一致的命名 - restrict choices (e.g. set of possible/valid values)
限制选择（例如，可能/有效值的集合） - dedicated types with clearly defined purpose
有明确目的的专用类型 - few function parameters with distinct types, avoid output parameters (call by non-const reference)
少数具有不同类型的函数参数。避免输出参数（通过非常量引用调用） - prefer standard library containers & algorithms
喜欢标准库中的容器和算法 - prefer patterns that are well-known in the C++ community
喜欢C++社区中众所周知的模式
You don't know what's coming! 你不知道会发生什么!
… neither do your customers/users!
Change is coming - and not the way you thought it would:
变化正在到来--而且不是你想象的那样。
- do not try to anticipate future changes/use cases
不要试图预测未来的变化/用例 - only add customization points that are needed/requested right now
只添加现在需要/要求的定制点 现在就需要/要求的定制点 - limit the potential impact of future changes
限制未来变化的潜在影响
Limit The Scope/Impact of Potential Changes 限制潜在变化的范围/影响
Isolate Functionality! 隔离功能!
- declare variables in the smallest possible scope
在尽可能小的范围内声明变量 - each function and type should have one responsibility
每个函数和类型应该有一个责任 - avoid elaborate, hard to check preconditions
避免复杂的、难以检查的前提条件 - avoid deep inheritance hierarchies
避免深层次的继承层次结构
OOP Design Patterns OOP设计模式
Patterns that you should probably know include:
- Composite, Decorator, Bridge, Visitor, Proxy, Façade,
- Iterator, Strategy, Observer, Command, Template Method,
- Factory Method, Abstract Factory, Singleton,
Classic Book:
Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides
Design Patterns: Elements of Reusable Object-Oriented Software
Please Take Note:
Most patterns reflect the lack of certain language features.
大多数模式反映了某些语言特性的缺乏。
