随笔分类 - 设计模式
摘要：原先写类，到后面发现要扩展功能，发现类变的很庞大。。。。。。。今天终于有点感觉。。呵呵
阅读全文
摘要：依赖倒转原则：强内聚：像CPU一样，别的厂商木有办法造。因为看不见内部。松耦合：像CPU的针脚一样，主板厂商知道怎么造主板能用cpu依赖倒转原则：抽象不应该依赖结节，细节不应该依赖于抽象。说白了就是针对接口编程，而不是针对实现编程。依赖倒转原则：高层模块不应该依赖低层模块。两个都应该依赖抽象。抽象不应该依赖结节。细节应该依赖抽象。有些时候为了代码复用，一般会把常用的代码写成函数或类库。这样开发新项目时，直接用就行了。比如做项目时大多要访问数据库，所以我们就把访问数据库的代码写成了函数。每次做项目去调用这些函数。这有什么问题呢？我们要做新项目时，发现业务逻辑的高层模块都是一样的，但客户却希望使用
阅读全文
摘要：开放-封闭原则：软件实体（类，模块，函数等等）应该可以扩展，但是不可修改为适应不断变更的新需求，就及早的想办法应对发生更大改变的可能。最初编写代码时，假设变化不会发生。当变化发生时，我们就创建抽象来隔离以后发生的同类变化。比如：之前的加法程序，很快在一个client类中就能完成(http://www.cnblogs.com/zhangdongsheng/archive/2012/03/25/2417224.html)。此时变化还没有发生，如果我们再加一个减法功能，你发现，增加功能需要修改这个类。这就违背了今天的“开放-封闭”原则，于是你就考虑重构程序。增加一个抽象运算类，通过一些面向对象的手段
阅读全文
摘要：就一个类而言，应该仅有一个引起它变化的原因。我们在做编程的时候，很自然的会给一个类添加各种各样的功能，比如我们写一个窗体应用程序，一般都会生成Form1这样一个类，于是我们就把各种各样的功能，像商业运算法呀，像数据库访问啊，都写到类中，这就意味着，无论任何需求改变，我们都需要改变这个窗体类，这其实很糟高的，维护麻烦，复用不可能，也缺乏灵活性。单一职责原则（SRP） ，就一个类而言，应该只有一个引起它变化的原因。如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抵制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏。当然，
阅读全文
摘要：////////////////////////////////////////////////////////////////////////////CashCalculate.h#include <string>using std::string;/************************************************************************//* 请实现一个商场收银软件,包含正常收费,打折收费和返利收费三种具体策略 *//*****************************************************
阅读全文
摘要：1 简单工厂模式1.1 问题用任意一种面向对象语言实现一个计算器控制程序，要求输入两个数和运算符号，得到结果。1.2 知识点命名要规范，有意义可维护性、可复用性、可扩展性避免重复代码，重复代码用函数或宏等计算和显示分开模块划分要合理保证修改无关性（修改一个方面就不造成另一方面的损失）1.3 简单工厂模式1.3.1 说明简单工厂模式由一个工厂对象决定创建出哪一种产品的实例。简单工厂模式是工厂式家庭中最简单实用的模式，可以理解为是不同工厂模式的一个特殊实现。1.3.2 UML1.3.3 代码#ifndef OPERATOR_H_#define OPERATOR_H_//基类class Operat
阅读全文
