面向对象分析设计原则
面向对象设计原则
面向对象设计原则
面向对象设计原则是一种实践性的指导，它指导程序员如何使用面向对象的方式设计出优秀的程序。
它旨在提升程序的可读性、可维护性、可测试性和可扩展性，以及可重用性和可扩展性。
面向对象设计原则涵盖了一系列的原则，可以帮助程序员在设计时避免常见的错误，从而确保程序的可靠性和可维护性。
1、单一职责原则（SRP）：单一职责原则要求每个类只负责一件事情，而不是多个职责。
这样，在维护类时，程序员就可以更加专心致志，从而减少出错的可能性，也减少了代码的复杂程度。
2、开放-封闭原则（OCP）：开放-封闭原则要求一个软件实体（类、模块、函数）应该是可以扩展的，但不可修改。
这样，在需求变更的情况下，程序员只需要增加新的代码，而不用修改现有的代码，从而确保程序的稳定性。
3、接口隔离原则（ISP）：接口隔离原则要求程序员应该尽量将接口分解为多个小接口，并要求每个类只实现自己需要的接口，而不是实现一个大而全的接口。
这样，程序员就可以在实现接口时不会出错，从而提高程序的可读性、可维护性和可测试性。
4、依赖倒置原则（DIP）：依赖倒置原则要求程序员在编写代码时，应该尽量避免“程序依赖于具体类型”的情况，而是要求“程序依赖于
抽象类型”，这样，在后期的维护时，程序员就可以根据实际情况自由地更换依赖的类型，从而提高程序的可扩展性和可维护性。
通过实施面向对象设计原则，程序员可以更好地管理代码，并可以让程序更加规范，从而提高程序的可读性、可维护性和可测试性。
简述面向对象分析的基本原则
简述面向对象分析的基本原则
1、模块化原则，把复杂的软件系统分解为模块，每个模块完成单一任务。
2、抽象性原则，将具有相同属性和功能的单元放在一起，实现了局部性和抽象性。
3、信息隐蔽性原则，软件系统将内部状态转化为对外界事物变化的描述，使得外部人员难以理解其中的细节。
4、接口隔离性原则，为保证子系统间接口的清晰与合法，使得它们彼此独立又相互关联。
5、接口对等原则，为了更好地交流信息，提高软件的维护性和可靠性，应该建立接口来表示数据流，且接口应该是开放的。
6、面向对象分析基本原则之接口优先的原则，面向对象分析时必须考虑接口因素，没有接口就不会有对象。
1）所谓的“接口”，就是面向对象的软件系统中用来描述各种模块间相互关系的术语，这些模块间的结构关系和操作关系就是对应的接口。
在设计中，接口的选择要慎重，要遵循面向对象分析的原则。
7、面向对象分析基本原则之封装原则，封装的概念：将一个接口中的数据转换成另一个接口中的数据;或者说封装指一个对象被转换成多个对象，而不改变它们的功能和行为。
通俗地讲，就是将类中的信息以一定的方式（比如：封装类的信息、静态变量的存储、实现类的构造函数等）存放在数据库中，这样即便是改变了类中的数据也只需修改对应的数据库即可，从而避免了大量的修改工作，还可以提高代码的复用率。
面向对象分析设计原则
一、单一职责原则（ＳＲＰ）就一个类而言，应该仅有一个引起它变化的原因。
软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离。
测试驱动的开发实践常常会在设计出现臭味之前就迫使我们分离职责。
二、开闭原则（ＯＣＰ）软件实体（类、模块、函数）应该是可扩展的，但是不可修改的。
也就是说：对于扩展是开放的，对于更改是封闭的。
怎样可能在不改动模块源代码的情况下去更改它的行为呢？怎样才能在无需对模块进行改动的情况下就改变它的功能呢？关键是抽象！因此在进行面向对象设计时要尽量考虑接口封装机制、抽象机制和多态技术。
该原则同样适合于非面向对象设计的方法，是软件工程设计方法的重要原则之一。
三、替换原则（ＬＳＰ）子类应当可以替换父类并出现在父类能够出现的任何地方。
这个原则是Liskov于1987年提出的设计原则。
它同样可以从Bertrand Meyer 的DBC (Design by Contract〔基于契约设计〕) 的概念推出。
四、依赖倒置原则（ＤＩＰ）１、高层模块不应该依赖于低层模块。
二者都应该依赖于抽象。
２、抽象不应该依赖于细节。
细节应该依赖于抽象。
在进行业务设计时，与特定业务有关的依赖关系应该尽量依赖接口和抽象类，而不是依赖于具体类。
具体类只负责相关业务的实现，修改具体类不影响与特定业务有关的依赖关系。
在结构化设计中，我们可以看到底层的模块是对高层抽象模块的实现（高层抽象模块通过调用底层模块），这说明，抽象的模块要依赖具体实现相关的模块，底层模块的具体实现发生变动时将会严重影响高层抽象的模块，显然这是结构化方法的一个"硬伤"。
面向对象方法的依赖关系刚好相反，具体实现类依赖于抽象类和接口。
五、接口分离原则（ＩＳＰ）采用多个与特定客户类有关的接口比采用一个通用的涵盖多个业务方法的接口要好。
ISP原则是另外一个支持诸如COM等组件化的使能技术。
缺少ISP，组件、类的可用性和移植性将大打折扣。
软件工程-面向对象分析
第7章面向对象分析•7.1.1 面向对象分析过程面向对象的分析主要以用例模型为基础。
开发人员在收集到的原始需求的基础上，通过构建用例模型从而得到系统的需求。
进而再通过对用例模型的完善，使得需求得到改善。
所谓用例是指系统中的一个功能单元，可以描述为参与者与系统之间的一次交互。
用例常被用来收集用户的需求。
①首先要找到系统的操作者，即用例的参与者。
参与者是在系统之外，透过系统边界与系统进行有意义交互的任何事物。
②可以把参与者执行的每一个系统功能都看作一个用例。
可以说，用例描述了系统的功能，涉及系统为了实现一个功能目标而关联的参与者、对象和行为。
③确定了系统的所有用例之后，就可以开始识别目标系统中的对象和类了。
把具有相似属性和操作的对象定义为一个类。
边界类示意图控制类示意图目标系统的类可以划分为边界类、控制类和实体类。
Ø边界类代表了系统及其操参与者的边界，描述参与者与系统之间的交互。
它更加关注系统的职责，而不是实现职责的具体细节。
通常，界面控制类、系统和设备接口类都属于边界类。
Ø控制类代表了系统的逻辑控制，描述一个用例所具有的事件流的控制行为，实现对用例行为的封装。
通常，可以为每个用例定义一个控制类。
Ø实体类描述了系统中必须存储的信息及相关的行为，通常对应于现实世界中的事物。
确定了系统的类和对象之后，就可以分析类之间的关系了。
对象或类之间的关系有依赖、关联、聚合、组合、泛化和实现。
①依赖关系是“非结构化”的和短暂的关系，表明某个对象会影响另外一个对象的行为或服务。
②关联关系是“结构化”的关系，描述对象之间的连接。
③聚合关系和组合关系是特殊的关联关系，它们强调整体和部分之间的从属性，组合是聚合的一种形式，组合关系对应的整体和部分具有很强的归属关系和一致的生命期。
比如，计算机和显示器就属于聚合关系。
④泛化关系与类间的继承类似。
⑤实现关系是针对类与接口的关系。
明确了对象、类和类之间的层次关系之后，需要进一步识别出对象之间的动态交互行为，即系统响应外部事件或操作的工作过程。
面向对象的系统分析与设计方法
面向对象的系统分析与设计方法在信息化时代，各种软件系统已经深入到人们日常生活的方方面面。
如何将软件设计得更加高效、安全、易用成为设计人员不断探索的问题。
其中，面向对象的系统分析与设计方法被广泛应用于软件领域，成为当前软件研发中的流行趋势。
一、面向对象思想面向对象思想是一种软件分析、设计和编程思路。
它将现实世界中的实体抽象为对象，通过对象之间的交互和信息处理来实现系统的功能。
对象的行为和属性都与现实世界中的事物相对应，因此可以更加符合人类的思维方式，易于理解和维护。
同时，面向对象的设计还具有可重用性好、扩展性强、易维护等优点，因此被广泛应用于软件开发中。
二、面向对象的系统分析与设计面向对象的系统分析与设计方法采用面向对象思想，以系统的对象为中心，对系统所涉及到的实体进行抽象分析和设计。
其主要步骤包括系统需求分析、面向对象的分析和面向对象的设计。
1.系统需求分析系统需求分析是整个软件开发的关键，需要通过对用户需求、客户需求和用户交互接口需求等方面进行深入分析和调研，明确软件的功能、性能、可靠性和安全性等需求要求，为后续的设计和编码打下基础。
2.面向对象的分析面向对象的分析将系统需求分析的结果转化为面向对象的模型，具体包括对象、类、关系、约束条件等方面的分析。
其中，最重要的是通过实体之间的关系和交互来建立对象模型，理清对象之间的依赖关系和功能流程，同时将软件的功能划分为一个个模块，为后续的设计提供可靠的基础。
3.面向对象的设计面向对象的设计是指基于面向对象的分析结果，对系统进行更加详细的设计。
在设计过程中，需要运用各种通用的面向对象设计模式，如单例模式、工厂模式、观察者模式等，从而提高系统的可维护性、可扩展性和可重用性，同时还需考虑系统安全性、性能等方面的设计。
三、面向对象设计方法的优势1.提高系统的可维护性面向对象设计方法可以将系统中的实体进行模块化的设计，每个模块都可以自行管理本身功能的维护和更新，同时多个模块之间的协调和合作也容易实现，从而提高了系统的可维护性。
面向对象设计六大原则
面向对象设计六大原则面向对象设计的原则是面向对象思想的提炼，它比面向对象思想的核心要素更具可操作性，但与设计模式相比，却又更加的抽象，是设计精神要义的抽象概括。
形象地将，面向对象思想像法理的精神，设计原则则相对于基本宪法，而设计模式就好比各式各样的具体法律条文了。
面向对象设计原则有6个：开放封闭原则，单一职责原则，依赖倒置原则，Liskov替换原则，迪米特法则和接口隔离原则或合成/聚合复用原则（不同资料略有不同，这里对7个都做了整理）。
1单一职责原则(Single Responsibility Principle SRP)There should never be more than one reason for a class to change. 什么意思呢？所谓单一职责原则就是一个类只负责一个职责，只有一个引起变化的原因。
如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化会削弱或抑制这个类完成其他职责的能力，这个耦合会导致脆弱的设计。
软件设计真正要做的许多内容，就是发现职责并把这些职责相互分离；如果能够想到多于一个动机去改变一个类，那么这个类就具有多于一个职责，就应该考虑类的分离。
以调制解调器为例如下图：从上述类图里面我们发现有四个方法Dial(拨通电话)，Hangup(挂电话)，Receive(收到信息)，Send(发送信息)，经过分析不难判断出，实际上Dial(拨通电话)和Hangup(挂电话)是属于连接的范畴，而Receive(收到信息)和Send(发送信息)是属于数据传送的范畴。
这里类包括两个职责，显然违反了SRP。
这样做有潜在的隐患，如果要改变连接的方式，势必要修改Modem，而修改Modem 类的结果导致凡事依赖Modem类可能都需要修改，这样就需要重新编译和部署，不管数据传输这部分是否需要修改。
因此要重构Modem类，从中抽象出两个接口，一个专门负责连接，另一个专门负责数据传送。
实验报告面向对象分析设计
实验报告面向对象分析设计1. 引言面向对象分析与设计（Object-Oriented Analysis and Design，简称OOAD）是一种软件开发方法论，它以对象为中心，将软件系统看作是一组互相协作的对象集合。
本实验旨在通过一个具体的案例，通过分析和设计实践，掌握面向对象分析与设计的基本原则和方法。
2. 实验目的通过本实验，我们将学习和掌握以下内容：- 了解面向对象分析与设计的概念和基本原则- 学习使用UML（Unified Modeling Language）进行面向对象分析和设计- 掌握面向对象分析与设计的基本流程和方法- 熟悉常用的面向对象分析与设计工具和技术3. 实验内容及步骤3.1 实验环境本实验使用以下工具和环境：- UML工具：如Visual Paradigm、StarUML等- 编辑器：如Visual Studio Code、Eclipse等- 编程语言：Java、C++等3.2 实验步骤本实验主要分为以下几个步骤：1. 了解案例需求：首先，我们需要明确一个具体的案例，如图书馆管理系统、学生选课系统等。
本实验以图书馆管理系统为例。
2. 创建用例图：使用UML工具，根据需求，创建图书馆管理系统的用例图。
用例图描述系统的功能需求，包括用户角色、用户的需求和系统的功能。
3. 创建类图：基于用例图和需求分析，使用UML工具创建类图。
类图描述系统的静态结构，包括类和类之间的关系。
4. 创建时序图：基于用例图和类图，使用UML工具创建时序图。
时序图描述系统的动态行为，展示对象之间的交互关系和顺序。
5. 完善设计：基于用例图、类图和时序图，进一步完善系统设计。
包括类的属性和方法的设计、系统的架构设计等。
4. 实验结果与分析通过本实验，我们完成了图书馆管理系统的面向对象分析与设计。
通过用例图、类图和时序图的创建，我们清晰地描述了系统的功能需求、静态结构和动态行为。
通过系统设计的完善，我们定义了系统的架构和各个类的属性和方法。
面向对象分析与设计原理及实践
面向对象分析与设计原理及实践面向对象程序设计（Object Oriented Programming, OOP）是目前程序设计领域中最为流行的一种设计方法，伴随着软件开发的日益复杂，我们需要高效的方法来管理和维护软件的复杂性。
在OOP中，一切皆为对象，对象是根据类定义而创建的。
类定义了一组属性和行为，对象是类的实例，拥有这些属性和行为。
使用面向对象的方式，可以更好地组织代码，提高代码重用和可维护性。
面向对象程序设计的三大特征面向对象程序设计的三大特征分别为封装、继承和多态。
封装是指将数据和行为打包到一个单元（class）中，通过访问权限限制来保证数据的安全性。
继承是指通过已有类派生出新的类，子类继承父类的所有属性和行为，同时可以添加自己的属性和行为，这种方式可以减少代码的重复性。
多态是指同一行为对于不同的对象具有不同的表现形式。
多态的实现方式有重载、重写和向上转型等。
面向对象分析与设计面向对象分析（Object Oriented Analysis, OOA）是一种软件工程方法，是软件设计中的第一步，它主要是从用户的需求出发，描述系统中的对象和他们之间的关系。
面向对象设计（Object Oriented Design, OOD）是软件设计的第二步，它主要是在OOA的基础上，根据系统需求，定义系统中的类以及类之间的关系。
在面向对象分析和设计中，主要有以下步骤：1. 需求收集和分析：通过与用户沟通，理解用户的需求，收集和分析需求。
2. 建立用例图和场景描述：从需求中抽取功能点，建立用例，同时描述用例的详细场景。
3. 建立类图：根据用例图和场景描述，建立类图，描述类之间的关系和属性。
4. 设计框架和结构：根据类图，设计系统的框架和结构。
5. 编写代码：在完成以上步骤后，编写代码实现系统。
面向对象实践在面向对象程序设计中，我们可以使用很多编程语言来实践，较为常见的有Java、C++、Python等。
在实践中，我们首先需要了解各种编程语言的特点和优势，根据需求选择合适的编程语言。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
一、单一职责原则（ＳＲＰ）就一个类而言，应该仅有一个引起它变化的原因。
软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离。
测试驱动的开发实践常常会在设计出现臭味之前就迫使我们分离职责。
二、开闭原则（ＯＣＰ）软件实体（类、模块、函数）应该是可扩展的，但是不可修改的。
也就是说：对于扩展是开放的，对于更改是封闭的。
怎样可能在不改动模块源代码的情况下去更改它的行为呢？怎样才能在无需对模块进行改动的情况下就改变它的功能呢？关键是抽象！因此在进行面向对象设计时要尽量考虑接口封装机制、抽象机制和多态技术。
该原则同样适合于非面向对象设计的方法，是软件工程设计方法的重要原则之一。
三、替换原则（ＬＳＰ）子类应当可以替换父类并出现在父类能够出现的任何地方。
这个原则是Liskov于1987年提出的设计原则。
它同样可以从Bertrand Meyer 的DBC (Design by Contract〔基于契约设计〕) 的概念推出。
四、依赖倒置原则（ＤＩＰ）１、高层模块不应该依赖于低层模块。
二者都应该依赖于抽象。
２、抽象不应该依赖于细节。
细节应该依赖于抽象。
在进行业务设计时，与特定业务有关的依赖关系应该尽量依赖接口和抽象类，而不是依赖于具体类。
具体类只负责相关业务的实现，修改具体类不影响与特定业务有关的依赖关系。
在结构化设计中，我们可以看到底层的模块是对高层抽象模块的实现（高层抽象模块通过调用底层模块），这说明，抽象的模块要依赖具体实现相关的模块，底层模块的具体实现发生变动时将会严重影响高层抽象的模块，显然这是结构化方法的一个"硬伤"。
面向对象方法的依赖关系刚好相反，具体实现类依赖于抽象类和接口。
五、接口分离原则（ＩＳＰ）采用多个与特定客户类有关的接口比采用一个通用的涵盖多个业务方法的接口要好。
ISP原则是另外一个支持诸如COM等组件化的使能技术。
缺少ISP，组件、类的可用性和移植性将大打折扣。
这个原则的本质相当简单。
如果你拥有一个针对多个客户的类，为每一个客户创建特定业务接口，然后使该客户类继承多个特定业务接口将比直接加载客户所需所有方法有效。
以上五个原则是面向对象中常常用到的原则。
此外，除上述五原则外，还有一些常用的经验诸如类结构层次以三到四层为宜、类的职责明确化（一个类对应一个具体职责）等可供我们在进行面向对象设计参考。
但就上面的几个原则看来，我们看到这些类在几何分布上呈现树型拓扑的关系，这是一种良好、开放式的线性关系、具有较低的设计复杂度。
一般说来，在软件设计中我们应当尽量避免出现带有闭包、循环的设计关系，它们反映的是较大的耦合度和设计复杂化。
面向对象之代码复用规则1、对接口编程"对接口编程"是面向对象设计（OOD）的第一个基本原则。
它的含义是：使用接口和同类型的组件通讯，即，对于所有完成相同功能的组件，应该抽象出一个接口，它们都实现该接口。
具体到JAVA中，可以是接口，或者是抽象类，所有完成相同功能的组件都实现该接口，或者从该抽象类继承。
尽量使用接口。
接口只是对象打交道的入口，只有具有继承关系才使用抽象类。
2、优先使用对象组合，而不是类继承"优先使用对象组合，而不是类继承"是面向对象设计的第二个原则。
并不是说继承不重要，而是因为每个学习OOP的人都知道OO的基本特性之一就是继承，以至于继承已经被滥用了，而对象组合技术往往被忽视了。
只有有现实生活中的父子关系才使用继承。
相关的设计模式有：Bridge、Composite、Decorator、Observer、Strategy等。
3、将可变的部分和不可变的部分分离"将可变的部分和不可变的部分分离"是面向对象设计的第三个原则。
如果使用继承的复用技术，我们可以在抽象基类中定义好不可变的部分，而由其子类去具体实现可变的部分，不可变的部分不需要重复定义，而且便于维护。
如果使用对象组合的复用技术，我们可以定义好不可变的部分，而可变的部分可以由不同的组件实现，根据需要，在运行时动态配置。
这样，我们就有更多的时间关注可变的部分。
对于对象组合技术而言，每个组件只完成相对较小的功能，相互之间耦合比较松散，复用率较高，通过组合，就能获得新的功能。
4、减少方法的长度通常，我们的方法应该只有尽量少的几行，太长的方法会难以理解，而且，如果方法太长，则应该重新设计。
对此，可以总结为以下原则：三十秒原则：如果另一个程序员无法在三十秒之内了解你的函数做了什么（What），如何做(How)以及为什么要这样做(Why)，那就说明你的代码是难以维护的，必须得到提高；一屏原则：如果一个函数的代码长度超过一个屏幕，那么或许这个函数太长了，应该拆分成更小的子函数；一行代码尽量简短，并且保证一行代码只做一件事那种看似技巧性的冗长代码只会增加代码维护的难度。
5、消除case / if语句要尽量避免在代码中出现判断语句，来测试一个对象是否某个特定类的实例。
通常，如果你需要这么做，那么，重新设计可能会有所帮助。
我在工作中遇到这样的一个问题：我们在使用JAVA做XML解析时，对每个标签映射了一个JAVA类，采用SAX（简单的XML接口API：Simple API for XML）模型。
结果，代码中反复出现了大量的判断语句，来测试当前的标签类型。
为此，我们重新设计了DTD（文档类型定义：Document Type Definition），为每个标签增加了一个固定的属性：classname，而且重新设计了每个标签映射的JAVA类的接口，统一了每个对象的操作：addElement(Element aElement); //增加子元素addAttribute(String attName, String attValue); //增加属性；则彻底消除了所有的测试当前的标签类型的判断语句。
每个对象通过Class.forName(aElement.attributes.getAttribute("classname")).newInstence(); 动态创建，6、类层次的最高层应该是抽象类。
在许多情况下，提供一个抽象基类有利做特性化扩展。
由于在抽象基类中，大部分的功能和行为已经定义好，使我们更容易理解接口设计者的意图是什么。
由于JAVA不允许"多继承"，从一个抽象基类继承，就无法再从其它基类继承了。
所以，提供一个抽象接口(interface)是个好主意，一个类可以实现多个接口，从而模拟实现了"多继承"，为类的设计提供了更大的灵活性。
7、尽量减少对变量的直接访问。
对数据的封装原则应该规范化，不要把一个类的属性暴露给其它类，而是应该通过访问方法去保护他们，这有利于避免产生波纹效应。
如果某个属性的名字改变，你只需要修改它的访问方法，而不是修改所有相关的代码。
8、拆分过大的类。
如果一个类有太多的方法（超过50个），那么它可能要做的工作太多，我们应该试着将它的功能拆分到不同的类中。
9、作用截然不同的对象应该拆分。
在构建的过程中，你有时会遇到这样的问题：对同样的数据，有不同的视图。
某些属性描述的是数据结构怎样生成，而某些属性描述的是数据结构本身。
最好将这两个视图拆分到不同的类中，从类名上就可以区分出不同视图的作用。
类的域、方法也应该有同样的考虑！如LinkedList和ListNode◆SRP，单一职责原则，一个类应该有且只有一个改变的理由。
◆OCP，开放封闭原则，一个类对扩展开放，而对修改闭合。
◆LSP，替换原则，所有用基类的地方都可以用派生类来替换。
◆DIP，依赖倒置原则，依赖于抽象而不是实现。
◆ISP，接口隔离原则，客户只要关注它们所需的接口。
接口尽可能单一，最小化，不要视图抽象一个包含很多功能的接口。
六十一条面向对象分析设计的经验原则你不必严格遵守这些原则，违背它们也不会被处以宗教刑罚。
但你应当把这些原则看成警铃，若违背了其中的一条，那么警铃就会响起。
(1)所有数据都应该隐藏在所在的类的内部。
(2)类的使用者必须依赖类的共有接口，但类不能依赖它的使用者。
(3)尽量减少类的协议中的消息。
(4)实现所有类都理解的最基本公有接口。
如类对象toString而不应该自定义其他接口(5)不要把实现细节放到类的公有接口中。
公有函数是对外接口，具体实现应该尽量用私有函数做。
(6)不要以用户无法使用或不感兴趣的东西扰乱类的公有接口。
(7)类之间应该零耦合，或者只有导出耦合关系。
也即，一个类要么同另一个类毫无关系，要么只使用另一个类的公有接口中的操作。
(8)一个类应该只表示一个关键抽象。
（Java不允许多重继承，解决了这个问题）包中的所有类对于同一类性质的变化应该是共同封闭的。
一个变化若对一个包影响，则将对包中的所有类产生影响，而对其他的包不造成任何影响.(9)把相关的数据和行为集中放置。
设计者应当留意那些通过get之类操作从别的对象中获取数据的对象。
这种类型的行为暗示着这条经验原则被违反了。
(10)把不相关的信息放在另一个类中(也即：互不沟通的行为)朝着稳定的方向进行依赖.(11)确保你为之建模的抽象概念是类，而不只是对象扮演的角色。
(12)在水平方向上尽可能统一地分布系统功能，也即：按照设计，顶层类应当统一地共享工作。
(13)在你的系统中不要创建全能类/对象。
对名字包含Driver、Manager、System、Susystem 的类要特别多加小心。
规划一个接口而不是实现一个接口。
类对象实现的功能要单一。
(14)对公共接口中定义了大量访问方法的类多加小心。
大量访问方法意味着相关数据和行为没有集中存放。
(15)对包含太多互不沟通的行为的类多加小心。
(16)在由同用户界面交互的面向对象模型构成的应用程序中，模型不应该依赖于界面，界面则应当依赖于模型。
(17)尽可能地按照现实世界建模(我们常常为了遵守系统功能分布原则、避免全能类原则以及集中放置相关数据和行为的原则而违背这条原则) 。
(18)从你的设计中去除不需要的类。
(19)去除系统外的类。
系统外的类的特点是，抽象地看它们只往系统领域发送消息但并不接受系统领域内其他类发出的消息。
(20)不要把操作变成类。
质疑任何名字是动词或者派生自动词的类，特别是只有一个有意义行为的类。
考虑一下那个有意义的行为是否应当迁移到已经存在或者尚未发现的某个类中。
(21)我们在创建应用程序的分析模型时常常引入代理类。
在设计阶段，我们常会发现很多代理没有用的，应当去除。
(22)尽量减少类的协作者的数量。
一个类用到的其他类的数目应当尽量少。
(23)尽量减少类和协作者之间传递的消息的数量。
(24)尽量减少类和协作者之间的协作量，也即：减少类和协作者之间传递的不同消息的数量。