HackingC++ Learning笔记 Chapter12-Software Design Basics软件设计基础

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.
大多数模式反映了某些语言特性的缺乏。