6.2 类模型

2019独角兽企业重金招聘Python工程师标准>>>

【引子】

【师傅领进门，修行在个人】

    “类模型”是整个面向对象设计模型的核心，是面向对象设计阶段的主要输出，也是设计师们最能够发挥自己才能的地方。

    虽然“类模型”如此重要，但面向对象设计技术经过几十年的发展后，目前已经形成了很成熟的一套体系，因此真正在进行“类模型”设计的时候，其实难度并不高，这也是多亏了众多前辈们的无私贡献，才能使得我们这些芸芸众生也能轻松掌握这些原本带有艺术色彩的技能。

    不过话又说回来了，入门容易精通难，“类模型”的设计也是如此，虽然有前辈们各种各样的思想结晶指导着我们，但毕竟如何理解、如何应用这些思想结晶，还是要看个人的领悟力和把握力。就像同样的《葵花宝典》，岳不群看了创立了气宗，蔡子峰看了创立了剑宗，渡元禅师听了后悟出了辟邪剑法，东方不败看了竟然练出了绣花针绝技！所以接下来的内容，也只是“师父领进门，修行在个人”，如果希望做出优秀的设计，更多还是依靠个人的领悟和实践！

【设计的魔法崇拜】

    面向对象类的设计很多时候都蒙上了一层神秘的面纱。一个常见的场景是：“设计师”拿到需求后，经过一段时间的设计，感觉就像变戏法一样，然后就拿出了一个类模型。普通的开发人员看到这样的类模型，很难想象如何从需求才能够得到了这些类，由于大部分公司的设计人员确实也都是公司里面的牛人，因此大家就自然而然地认为这是水平和创造力的表现，心底不由得产生由衷的赞叹：“牛逼啊！”

    我称这种现象为设计的“魔法崇拜”，具体表现就是认为设计是一种魔法，做设计的人是魔法师，只有牛逼的人才能够做设计。

    但这种认识并不准确，就像我们前面提到的，面向对象领域已经发展了几十年，各种思想、理论都已经基本成熟，绝大部分人在做设计的时候，都不可能有什么天才的创新或者天才的灵感，而只是这些已经成熟的思想和理论的应用而已。

    之所以现在还会出现这种现象，主要原因还是在于各种思想、理论、方法都是针对具体问题的分析或者总结，但并没有谁明确的将这些东东形成一套完整的面向对象设计体系。

    可能很多人都有这种感觉：面向对象我也懂，设计模式我也知道，设计原则我也明白，但真的要进行设计的时候，就不知道如何下手了，比如说：

• 对象从哪里来？
• 什么时候用设计模式？
• 如何判断设计是否正确？
• 什么样的设计才是优秀的设计？
• 。。。。。。。。。。。

    正因为存在这样的原因，我们自然会对那些能够设计出完整的类模型的设计师们刮目相看了。

    其实面向对象设计并不是什么高深的技术，也不需要天才的创新，更不需要变魔法，而是有章可循的，只要我们按照一定的步骤，一步一个脚印，不断精益求精，就能够完成面向对象的设计。

    但正如前面提到的一样，面向对象设计更多的时候是一门艺术。虽然我们按照一定的步骤能够完成面向对象的设计，但在这些步骤实施的过程中，如何应用相关技术，如何做出设计选择等，更多时候是带有艺术色彩的。就像很多人都会弹吉他，但真正的吉他大师弹出来的感觉，肯定和一个普通人弹的不一样。

    接下来就为大家展示面向对象设计的具体步骤。

 

6.2.1 第一步（照猫画虎）：领域类映射

    进行面向对象类设计时，首先要解决的一个问题是：类从哪里来 ？

    有的人可能会认为，要发挥想象力、创造力。。。。。等各种“力”——这种方法的主要问题是：我们不是在进行纯粹的艺术创造，而是要最终满足客户需求，而不能天马行空。

    有的人可能会想到，参考其它的系统吧，把类似系统拿过来改吧改吧 ——这种方法的主要问题是：如果没有其它类似系统给你参考呢 ？
    还有的人干脆就说：拍脑袋吧，凭感觉吧 —— 这种方法的主要问题是：猴子能敲出莎士比亚全集么 ？

    看起来以上方法都不太可行，那究竟如何才能从哪里找到我们需要的类呢？

    相信绝大部分认真看书的同学都会灵光一闪：领域模型。
    我们将上一章中的领域模型图拿出来，重新再看一下：

    相信不用我多说，绝大部分同学一眼就能看出：哇塞，这不就是类么？

    确实是这样的，领域模型中的“领域类”，是设计模型中“软件类”最好的来源。通过“领域类”来启发我们设计最初的“软件类”，具有如下几个明显的优点：

• 软件类来自领域类，领域类来自用例，用例来自客户，这样一环扣一环，软件类的正确性得到了保证，不用担心拍脑袋带来的问题；
• 领域类到软件类的转换非常简单，不需要天才的创新，或者丰富的想象力，只要掌握基本的面向对象的知识就能完成，菜鸟也能做设计；
• 不需要参考其它系统，不用担心没有参照物时无法设计的问题；

    从领域类