大话设计模式笔记 - 简单工厂模式
总的来说,简单工厂模式就是对封装,继承,多态的基本实现。是面向对象的基本思路。
我在最开始写程序的时候,业务逻辑和界面一股脑的堆在一起。根本没有任何设计模式。
每次业务修改的时候,不是改出新的bug,就是对已有程序做大手术。加了很多班,走了很多弯路。
这个章节就分析了为什么会造成这种情况的原因。
1. 面向对象编程
我们在遇到问题的时候,直觉地会用计算机能够理解的逻辑来表述我们的求解过程。
比如说,我要处理一个加减法,一共要分几步?
1.输入第一个数
2.输入运算逻辑
3.输入第二个数
4.等待输出结果
这么做并没有错,但这样却只能满足当下的需求,程序不易维护、扩展和复用。
如果有新的运算逻辑加入?我们要怎么修改程序?
原来所有的算法逻辑都在一个方法中,我们是再加一个在其中吗?
这么写的话很容易就会造成bug和动大手术,这就是上面总加班的主要原因。
我们应该使用面向对象的思维来分析和设计软件。通过封装,继承,多态。使业务逻辑和产品逻辑解耦。
1.1 封装
首先我们对业务逻辑和界面逻辑封装。这样,如果我们的程序需要移植到其他平台上去的话,业务逻辑可以不用动。我们需要重新编写的只是页面逻辑。(若二者语言是相同的话)
1.2 松耦合和紧耦合
如果我们所有的算法都在一个方法当中,我们修改或者添加一个算法,那么其他的算法很可能在我们不知情的情况下发生了变动。(这就看自测和测试人员能否发现了)若发现不了,很可能产生严重的bug。
所以,我们需要将所有的算法进行松耦合。将他们分别定义。
但是如果我们将他们分别提出一个单独的方法,这样只是在一定程度上解耦了,我们还可以更进一步。
1.3 继承
定义一个基类Operation,让所有的算法都继承这个类。
这样,所有算法的具体实现都在自己的类当中,根本不会相互影响。
若我们重新定义一个新的算法,我们可以让该算法继承Operation类,之后把判断逻辑添加到工厂当中。
那我们怎么把定义好的这些算法类联系到我们的逻辑当中呢?这就用到了多态。
1.4 多态
我们新建一个工厂类,在该类当中对用户的操作进行判断,eg:使用switch 来判断用户具体的操作,根据这个操作,给出对应的Operation 实现类。返回该类给我们的业务逻辑当中就可以了。
这就是简单工厂模式的实现思路,一个从封装,到继承,再到多态循序渐进的过程。
2 UML图
大家都见过UML图,基础的我就不说了,这里记录类与类,类与接口之间的关系以及一些思考。
1. 类与类之间的关系使用实线和空心三角表示,表示*继承*。
2. 类与接口之间是通过虚线和空心三角表示。表示*实现* 他和第一条的区别就是实线和虚线的区别
3. 当一个类需要知道另一个类时,表示 *关联关系* 。使用实线箭头表示。
4. A对象包含B,但B并不是A的一部分。这表示 *弱拥有* 。用空心棱形和箭头表示 eg: 雁群 与 大雁之间的关系
5. 和4相反,A对象包含B,且B是A的一部分,表示 *拥有*。 用实心棱形和箭头表示。 eg: 翅膀和鸟
6. *依赖关系*,使用虚线箭头。 eg: 鸟 和空气、水 之间的关系
我们在构建一个类的时候,要思考这个类和其他类之间的关系,
只有这样才能构建出更好更稳定的系统。
SUM
编程时一门技术,更加是一门艺术。
编程也不是一蹴而就的,需要反复思考和琢磨。
共勉。
网友评论