摘要: 对象的初始化Fraction *myFract=[[Fraction alloc] init];//初始化对象[myFract setTo:1 over:3];//设置初始值初始化对象和设置初始值的过程通常可以合并到一个方法中。myArray=[[NSArray alloc] initWithArr... 阅读全文
posted @ 2015-07-23 17:12 Charles_Lv 阅读(253) 评论(0) 推荐(0) 编辑
摘要: 含义:1、高层模块不应该依赖底层模块,两者都应该依赖其抽象。2、抽象不应该依赖细节。3、细节应该依赖抽象。底层模块:不可分割的原子逻辑。高层模块: 原子逻辑的再组装。抽象:接口或者抽象类,两者都不能直接被实例化。细节:实现类,实现接口或者继承抽象类而产生的类。可以直接被实例化。表现:1、模块间的依赖通过抽象发生,实现类之间不发生直接的依赖关系,其依赖关系是通过接口或抽象类产生的。2、接口或抽象类不依赖实现类。3、实现类依赖接口或抽象类。优点:减少类间的耦合性,提高系统的稳定性,降低并行开发引起的风险,提高代码的可读性和可维护性。依赖传递的三种写法:1、构造函数注入。2、Setter注入。3、接 阅读全文
posted @ 2014-04-11 23:13 Charles_Lv 阅读(517) 评论(0) 推荐(0) 编辑
摘要: 继承的优点:1、代码共享,减少创建类的工作量,每个子类都拥有父类的方法和属性。2、提高代码的重用性。3、子类可以形似父类,但又异于父类。4、提高代码的可扩展性,实现父类的方法就可以“为所欲为”。君不见很多开源框架扩展接口都是通过继承父类来完成的。5、提高产品或项目的开放性。继承的缺点:1、继承是侵入性的,只要继承就必须拥有父类的所有属性和方法。2、降低代码的灵活性,子类必须拥有父类的属性和方法,让子类自由的世界中多了些约束。3、增强了耦合度,当父类的常量、变量和方法被修改时,必须要考虑子类的修改,而且在缺乏规范的环境下,这种修改可能带来非常糟糕的结果——大片代码需要重构。让继承的利最大化于弊的 阅读全文
posted @ 2014-04-11 23:06 Charles_Lv 阅读(400) 评论(0) 推荐(0) 编辑
摘要: 定义:There should nerver be more then one reason for a class to change。优点:1、类的复杂性降低,实现什么职责都有清晰明确的定义。2、复杂性降低,可读性高,可维护性高。3、变更引起的风险降低。注意点:1、单一职责最难划分的就是职责。2、单一职责原则提出了一个编写程序的标准,用职责和变化原因来衡量接口或类设计的是否优良,但是职责和变化原因都是不可度量的,因项目而异,因环境而异。3、接口一定要做到单一职责,类的设计尽量做到只有一个原因引起变化。 阅读全文
posted @ 2014-04-08 17:33 Charles_Lv 阅读(241) 评论(0) 推荐(0) 编辑
摘要: 1、变更才显真功夫。业务需求变更永无休止,技术前进就永无止境。在发生变更时才能发觉我们的设计或程序是否是松耦合。2、稳定性较高的设计,在周围环境频繁变化的时候,也能做到“我自岿然不动”。3、接口负责定义pubilc属性和方法,并且声明与其他对象的依赖关系,抽象类负责公共构造部分的实现,实现类准确的实现业务逻辑,同时在适当的时候对父类进行细化。4、信息抽取成BO(Bussiness Object,业务对象),行为抽取成Biz(Bussiness Logic,业务逻辑)。 阅读全文
posted @ 2014-04-08 15:36 Charles_Lv 阅读(129) 评论(0) 推荐(0) 编辑
摘要: 6大设计原则1、单一职责原则2、里氏替换原则3、依赖倒置原则4、接口隔离原则5、迪米特原则6、开闭原则23种设计模式1、单例模式2、工厂方法模式3、抽象工厂模式4、模版方法模式5、建造者模式6、代理模式7、原型模式8、中介者模式9、命令模式10、责任链模式11、装饰模式12、策略模式13、适配器模式14、迭代器模式15、组合模式16、观察者模式17、门面模式18、备忘录模式19、访问者模式20、状态模式21、解释器模式22、亨元模式23、桥梁模式 阅读全文
posted @ 2014-04-08 15:31 Charles_Lv 阅读(115) 评论(0) 推荐(0) 编辑