ooad设计模式_OOAD-面向对象的分析与设计

ooad设计模式

让我们分为以下几节来讨论OOAD： (Lets discuss OOAD by dividing into the below sections:)

• OOS
  操作系统
• OOA
  OOA
• OOD
  面向对象
• Thumbnails principles of the object oriented design
  面向对象设计的缩略图原则
• OO Design Quality Metrics
  OO设计质量指标

面向对象系统（OOS） (Object-Oriented System (OOS))

• An object-oriented system is composed of objects
  面向对象的系统由对象组成
• Behavior of the system is achieved through collaboration between these objects
  通过这些对象之间的协作来实现系统的行为
• State of the system is the combined state of all the objects in it
  系统状态是其中所有对象的组合状态
• Collaboration between objects involves them sending messages to each other.
  对象之间的协作涉及它们彼此之间发送消息。
• Exact semantics of message sending between objects varies depending on what kind of system is being modeled.
  
  • By “Invoking a method"
  • By Sending data via a socket
  对象之间发送消息的确切语义取决于所建模的系统类型。
  
  • 通过“调用方法”
  • 通过套接字发送数据

面向对象分析（OOA） (Object-Oriented Analysis (OOA))

面向对象设计（OOD） (Object-Oriented Design (OOD))

面向对象设计的缩略图原则 (Thumbnails-principles of the Object Oriented Design)

原理-SOLID (Principles -SOLID)

单一责任原则 (Single Responsibility Principle)

• A class should have a single responsibility:
  班级应负单一责任：
• it does it all,
  这一切都做得到
• does it well, and
  做得好，并且
• does it only.
  只做。
• A class should have one, and only one, reason to change.
  一堂课应该只有一个改变的理由。
• Each responsibility should be a separate class, because each responsibility is an axis of change.
  每个责任应该是一个单独的类，因为每个责任都是变更的轴。
• If a change to the business rules causes a class to change, then a change to the database schema, GUI, report format, or any other segment of the system should not force that class to change
  如果业务规则的更改导致类发生更改，则对数据库模式，GUI，报表格式或系统的任何其他部分的更改都不应强制更改该类

经验法则 (Rule of thumb)

• Unless description of a class is in 25 words or less, with mouse of "and" or "or" may actually have more than one class.
  除非用25个单词或更少的文字描述一个类，否则“ and”或“ or”的鼠标可能实际上具有一个以上的类。
• Classes, interfaces, functions, etc. all become large and bloated when they're trying to do too many things.
  当它们试图做太多事情时，类，接口，函数等都会变得庞大而肿。
• To avoid bloat and confusion, and ensure that code is truly simple (not just quick to hack out), we have to practice Code Normalization, which seems to be a variation on OnceAndOnlyOnce and alsoDoTheSimplestThingThatCouldPossiblyWork. This is part of ResponsibilityDrivenDesign.
  为了避免膨胀和混乱，并确保代码真正简单（不仅可以快速破解），我们必须练习代码规范化，这似乎是对OnceAndOnlyOnce和DoTheSimplestThingThatCouldPossibleWork的变体。 这是ResponsibilityDrivenDesign的一部分。

开/关原则 (Open/Closed Principle)

• Software entities (classes, modules, etc.) should be open for extension, but closed for modification.
  软件实体（类，模块等）应打开以进行扩展，但应关闭以进行修改。
• In other words (in an ideal world...), you should never need to change existing code or classes: All new functionality can be added by adding new sub-classes and overriding methods, or by reusing existing code through delegation.
  换句话说（在理想的世界中...），您永远不需要更改现有的代码或类：可以通过添加新的子类和重写方法或通过委派重用现有的代码来添加所有新功能。
• This prevents you from introducing new bugs in existing code. If you never change it, you can't break it.
  这样可以防止您在现有代码中引入新的错误。 如果您从不更改它，就无法打破它。

里斯科夫替代原理 (Liskov Substitution Principle- LSP)

• Derived classes must be usable through the base class interface without the need for the user to know the difference.
  派生类必须可以通过基类接口使用，而无需用户知道区别。
• "An instance of a derived should be able to replace any instance of its super-class"
  “派生的实例应该能够替换其超类的任何实例”

详细地 (In Detail)

• The use of hierarchy is an important component in object-oriented design. Hierarchy allows the use of type families, in which higher level super-types capture the behavior that all of their sub-types have in common. For this methodology to be effective, it is necessary to have a clear understanding of how sub-types and super-types are related.
  层次结构的使用是面向对象设计中的重要组成部分。 层次结构允许使用类型族，其中更高级别的超类型捕获其所有子类型都具有的共同行为。 为了使这种方法有效，有必要对子类型和超类型之间的关系有一个清晰的了解。
• "objects of the sub-type ought to behave the same as those of the super-type as far as anyone or any program using super-type objects can tell".
  “只要任何人或任何使用超类型对象的程序都能看出来，子类型的对象就应与超类型的对象具有相同的行为”。

重要 (Important)

1. Because if not, then class hierarchies would be a mess. Mess being that whenever a subclass instance was passed as parameter to any method, strange behavior would occur.
   因为如果没有，那么类层次结构将是一团糟。 令人困惑的是，每当将子类实例作为参数传递给任何方法时，都会发生奇怪的行为。
2. Because if not, unit tests for the super-class would never succeed for the subclass
   因为如果不是这样，那么针对超类的单元测试将永远不会对子类成功

接口隔离原理 (Interface Segregation Principle)

• Many client specific interfaces are better than one general purpose interface
  许多客户端特定的接口优于一个通用接口
• The dependency of one class to another one should depend on the smallest possible interface
  一类与另一类的依赖关系应取决于最小的接口

依赖倒置原则 (Dependency Inversion Principle)

• Details should depend upon abstractions. Abstractions should not depend upon details.
  细节应取决于抽象。 抽象不应依赖细节。
• "The modules that implement a high level policy should not depend on the modules that implement the low level policies, but rather, they should depend on some well-defined interfaces. It stems from the realization that we must reverse the direction of these dependencies to avoid rigidity, fragility and immobility.
  “实施高级策略的模块不应依赖于实施低级策略的模块，而应依赖于一些定义明确的接口。这源于我们必须将这些依赖关系的方向转向避免僵化，脆弱和停滞不前。
• Avoid designs which are:
  
  • Rigid (Hard to change due to dependencies. Especially since dependencies are transitive.)
  • Fragile (Changes cause unexpected bugs.)
  • Immobile (Difficult to reuse due to implicit dependence on current application code.)
  避免以下设计：
  
  • 刚性（由于依赖关系而难以更改。尤其是因为依赖关系是可传递的。）
  • 易碎（更改会导致意外的错误。）
  • 固定的（由于隐式依赖当前应用程序代码，因此难以重用。）

包装凝聚原理 (Principles of package cohesion)

• Reuse/Release Equivalency Principle: The granule of reuse is the same as the granule of release. Only components that are released through a tracking system can be effectively reused.
  重用/发布等效性原理：重用粒度与释放粒度相同。 只有通过跟踪系统发布的组件才能有效地重用。
• Common Closure Principle: Classes that change together, belong together.
  通用关闭原则：一起变化的类属于一起。
• Common Reuse Principle: Classes that aren't reused together should not be grouped together.
  通用重用原则：不能一起重用的类不应组合在一起。

封装耦合原理 (Principles of Package Coupling)

• The Acyclic Dependencies Principle: The dependency structure for released components must be a directed acyclic graph. There can be no cycles.
  非循环依赖性原则：已发布组件的依赖性结构必须是有向非循环图。 不可能有周期。
• The Stable Dependencies Principle: Dependencies between released categories must run in the direction of stability. The dependee must be more stable than the depender.
  
  
  稳定依赖性原则：已发布类别之间的依赖性必须朝着稳定性的方向运行。 受抚养人必须比受抚养人更稳定。
  
• The Stable Abstractions Principle: The more stable a class category is, the more it must consist ofabstract classes. A completely stable category should consist of nothing but abstract classes.
  
  
  稳定抽象原理：类类别越稳定，抽象类就必须包含更多的类。 完全稳定的类别应仅由抽象类组成。
  

最佳设计 (Best Designs)

OOD准则–（最佳设计的设计规则） (OOD Guidelines –(Design Rules for Best Designs))

遗产 (Inheritance)

• A subclass is coupled to its super-class in terms of attributes & methods
  子类在属性和方法方面耦合到其超类
• High inheritance coupling is desirable
  高继承耦合是可取的
• Each specialization class should not inherit lots of unrelated & unneeded methods & attributes
  每个专业类不应继承许多不相关且不需要的方法和属性

耦合类型和程度 (Coupling Types and Degree)

内聚（单个对象或swcomponent内的交互） (Cohesion (interaction within a single object or swcomponent))

• Reflects the ’single-purposeness’ of an object
  反映对象的“单一目的”
• Method cohesion
  方法凝聚力
• A method should carry only one function. Carrying multiple functions is undesirable.
  一种方法应仅包含一个功能。 携带多种功能是不可取的。

优化技术 (Optimization Techniques)

重组考虑 (Restructure Consideration)

识别不良设计的规则 (Rules for Identifying Bad Design)

OO设计质量指标 (OO Design Quality Metrics)

指标（用于衡量面向对象设计的质量） (Metrics (To measure the quality of an object-oriented design))

相互依赖（子系统之间） (Interdependence (between the subsystems))

• High-interdependent tend to be rigid, un-reusable , hard to maintain and cascade changes in dependent modules
  
  • Collaboration of subsystems need interdependence
  • Support communications within the design
  • Isolate reusable elements from non-reusable elements, and
  • Block the propagation of change due to maintenance
  • Decide ability of design to survive change, or to be reused
  • Fragile on single change
  高相关性往往是僵化的，不可重用的，难以维护的，并且会在相关模块中级联更改
  
  • 子系统的协作需要相互依赖
  • 支持设计中的通讯
  • 将可重用元素与不可重用元素隔离开，并且
  • 阻止由于维护而传播的更改
  • 决定设计承受变更或重新使用的能力
  • 单一更改易碎

相依性 (Dependency)

• “Good Dependency” is a dependency upon something that is very stable
  “良好依赖”是对非常稳定的事物的依赖
• “Bad Dependency” is a dependency upon something that is unstable
  “不良依赖”是对不稳定事物的依赖

稳定性 (Stability)

• Most stable classes of all, are classes that are both Independent and Responsible. Such classes have no reason to change, and lots of reasons not to change.
  所有最稳定的类别是既独立又负责的类别。 这样的类没有理由改变，有很多理由没有改变。

类类别：复用和释放的颗粒 (Class Categories: the granule of Reuse and Release)

It is seldom that a class can be reused in isolation.

很少可以孤立地重用一个类。

“Class Category” - A Class Category (hereinafter referred to as simply a category) is a group of highly cohesive classes that obey the following three rules:

“类别类别”-类别类别（以下简称为类别）是一组具有高度凝聚力的类别，它们遵循以下三个规则：

1. Classes within a category are closed together against any force of change. If one class must change, all of the classes within the category are likely to change.
   类别中的类可以抵御任何变化的力量而封闭在一起。 如果必须更改一个类别，则该类别中的所有类别都可能会更改。
2. Classes within a category are reused together. Strongly interdependent and cannot be separated from each other. Thus if any attempt is made to reuse one class within the category, all the other classes must be reused with it.
   类别中的类可一起重用。 相互依存性强，不能彼此分离。 因此，如果尝试重用类别中的一个类，则所有其他类都必须与其重用。
3. Classes within a category share some common function or achieve some common goal.
   类别中的类具有某些共同的功能或达到某些共同的目标。

The authors must provide releases of their categories and identify them with release numbers so that reusers can be assured that they can have access to versions of the category that will not be changed.

作者必须提供其类别的版本，并用版本号标识它们，以便可以确保重用者可以访问不会更改的类别版本。

依赖性指标 (Dependency Metrics)

Responsibility, Independence and Stability of a category can be measured by counting the dependencies that interact with that category.

类别的责任，独立性和稳定性可以通过计算与该类别交互的依存关系来度量。

• Ca : Afferent Couplings : The number of classes outside this category that depend upon classes within this category
  Ca：传入联轴器：此类别外的类数，取决于该类别内的类
• Ce : Efferent Couplings: The number of classes inside this category that depend upon classes outside this categories
  Ce：传出联轴器：此类别内的类数，取决于该类别外的类
• I : Instability : (Ce ÷ (Ca+Ce)) : This metric has the range [0,1]
  I：不稳定性：（Ce÷（Ca + Ce））：该指标的范围为[0,1]
• I=0 indicates a maximally stable category
  I = 0表示类别最大稳定
• I=1 indicates a maximally unstable category
  I = 1表示类别最大不稳定
• Highly stable categories depend upon nothing
  高度稳定的类别不依赖任何内容
• Unstable categories should not be abstract, they should be concrete
  不稳定的类别不应抽象，而应具体
• Desirably portion of the design to be flexible enough to withstand significant amount of change
  希望设计的一部分足够灵活以承受大量更改

结论 (Conclusion)

Hope you got an interesting and easier understanding on OOAD.

希望您对OOAD有一个有趣且更轻松的理解。

翻译自: https://www.experts-exchange.com/articles/28797/OOAD-Object-Oriented-Analysis-and-Design.html

ooad设计模式