File tree 3 files changed +34
-1
lines changed
3 files changed +34
-1
lines changed Original file line number Diff line number Diff line change 44
55假设你想写一个赛车游戏。你需要对某种汽车建模，在本练习假设中只有一种类型的汽车。该车的每个实例都需要多个属性，例如发动机的当前功率输出、当前燃油使用量、轮胎压力、驾驶灯是否打开、挡风玻璃雨刮器是否启动等。游戏应该允许玩家配置不同的引擎、不同的轮胎、定制的驾驶灯和挡风玻璃雨刷等。你会如何对这样一辆车进行建模，为什么？
66
7+ 车并不是一个引擎，所以应该采用从属包含关系，即：
8+
9+ ``` txt
10+ |-车
11+ |--引擎
12+ |---输出
13+ |---燃油使用
14+ |--轮胎
15+ |-等等
16+ ```
17+
718## 5-2
819
920继续练习 5-1 中的赛车游戏，你当然希望能够支持人工驾驶汽车，但也希望包含对人工智能(AI)驱动汽车的支持。你将如何在游戏中对此进行建模？
1021
22+ 将输入与车辆部件剥离开，人工驾驶和 AI 驾驶由输入方式决定（AI可能使用与人工不同的输出-输入反馈方式）。
23+
1124## 5-3
1225
1326假设一个人力资源(HR)应用程序的一部分具有以下 3 个类。
1629- Person：关注姓名和地址
1730- Manager：关注团队中有哪些雇员
1831
19- 
32+ ![ 图5-3] ( 图5-3.png )
2033
2134你认为上图中的内图中怎么样？你能对它进行一些改动吗？该图没有显示不同类的任何属性或行为，因为这是练习 5-4 的主题。
2235
36+ 不太好，应该把Person改为Employee下级，避免姓名、地址一致而ID不同。
37+
2338## 5-4
2439
2540从练习 5-3 的最终类图开始，在类图中添加一些行为和属性。最后，对经理管理员工团队这一事实进行建模。
41+
42+ 略。
Original file line number Diff line number Diff line change 44
55使普通情况变得容易并使不太可能的情况成为可能意味着什么？
66
7+ 意味着接口应该有一个简单的学习曲线，应该能做到大多数程序员想要做的事情，也应允许更高级且较为少见的使用方式，并且需要将为了实现罕见情况的导致的复杂性与仅实现常见情况的简单性进行权衡。
8+
79## 6-2
810
911设计可重用的代码的第一策略是什么？
1012
13+ 抽象，即接口与实现分离。
14+
1115## 6-3
1216
1317假设你正在编写一个需要处理人员信息的应用程序。应用程序的一部分需要保留一份客户列表，例如包含最近的订单、会员卡号等数据的列表。应用程序的另一部分需要跟踪公司员工的 ID、职位等。因此，设计了一个名为 Person 的类，其中包含他们的姓名、电话号码、地址、最近订单列表、会员卡号、薪水、员工 ID、职位（如工程师、高级工程师等）。你觉得这样的类怎么样？你能够如何改进它？
1418
19+ 不太好，员工信息与客户列表耦合了，应该设置一个CustormerInformation类，一个CustormerOrder类，由Person类包含这两个类。
20+
1521## 6-4
1622
1723不回看之前的内容，解释 SOLID的含义。
24+
25+ S: SRP (Single Responsibility Principle，单一责任原则)，单个组件应当具有单独、明确定义的责任，不应当与无关的功能组合在一起
26+
27+ O: OCP (Open/Closed Priciple，开放/关闭原则)，一个类对扩展应当是“开放的”（允许派生新类），但对修改是“关闭的”。
28+
29+ L: LSP (Liskov Substitution Principle，里氏替换原则)，对于一个对象而言，应当能用该对象的子类型替换该对象的实例。
30+
31+ I: ISP (Interface Segregation Principle，接口隔离原则)，接口应当简单清楚。不要使用过于宽泛的通用接口，最好使用多个较小的、明确定义的、责任单一的接口。
32+
33+ D: DIP (Dependency Inversion Priciple，依赖倒置原则)，使用接口倒置依赖关系。
You can’t perform that action at this time.
0 commit comments