读<Android大话设计模式>

发布时间:2017-1-16 18:42:22 编辑:www.fx114.net 分享查询网我要评论
本篇文章主要介绍了"读<Android大话设计模式>",主要涉及到读<Android大话设计模式>方面的内容,对于读<Android大话设计模式>感兴趣的同学可以参考一下。

   设计模式提高代码复用性,对框架性代码把握更强,直观的把握代码脉络和走势。设计模式,亦框架,把握框架,再填充实现,即完成设计。 全书很薄,思路却很清晰,因为之前读Android的Binder不太明朗,后才知此为Proxy代理模式,构造性很强。并没有《设计模式那点事》深入,但写到的一些遵循规则还是很有借鉴的,写下来以便后来查阅。 一.针对接口编程,不要针对实现编程。 二.单一职责原则  MVC 三.开放封闭原则:对实现封闭,对接口开放 已有应用简介:  开放封闭原则是所有面向对象原则的核心。 软件的分析、设计、编码、维护等生命周期的各个阶段总是力求做到对修改关闭、对扩展开放。 著名的巴巴运动网生命周期的各个阶段就遵循了开放封闭原则。它把基本的 CRUD 操作做成了一个接口,同时采用了 JDK  5 引入的泛型技术,这样就可以保证以后做基本的添删改查操作时只需要实现该类即可。但由于引入了泛型技术,同时 在后台提供了对接口的抽象实现,你甚至不用写一行代码,就可以自如的操作数据库。如果以后又需要扩展的地方,只 需要扩展继承扩展自己的特有的操作即可,大大提高了生产效率。 四.里氏代换原则 定义:        里氏代换原则(Liskov Substitution Principle)是指:一个软件实体如果使用的是基类的话,那么也一定适用于其子 类,而且它根本觉察不错使用的是基类对象还是子类对象;反过来的代换这是不成立的,即:如果一个软件实体使用一 个类的子类对象,那么它不能够适用于基类对象。 法海要做的就是不管你是什么妖魔,只要是妖魔我就要把你收服,以防再次出来危害人间。他并不用区分你是蛇妖 还是狐妖,更不用管你蛇妖中的青蛇还是白色。 凡是对妖魔这个基类适用的  白蛇、青蛇就全部适用。 五.迪米特法则 定义:  迪米特法则(Law of Demeter,简写 LoD )又叫做最少知识原则(LeastKnowledge Principle  简写 LKP),也就是说, 一个对象应当对其他对象尽可能少的了解,不和陌生人说话。 迪米特法则的目的在于降低类与类之间的耦合。由于每个类尽量减少对其他类的依赖,因此,很容易使得系统的功能模 块功能独立,是的相互间存在尽可能少的依赖关系。 在运用迪米特法则到系统的设计中时,要注意以下几点: 第一:在类的划分上,应当创建弱耦合的类,类与类之间的耦合越弱,就越有利于实现可复用的目标。 第二:在类的结构设计上,每个类都应该降低成员的访问权限。  第三:在类的设计上,只要有可能,一个类应当设计成不变的类。 第四:在对其他类的应用上,一个对象对其他类的对象的应用应该降到最低。 第五:尽量限制局部变量的有效范围。 但是过度使用迪米特法则,也会造成系统的不同模块之间的通信效率降低,使系统的不同模块之间不容易协调等缺点。 同时,因为迪米特法则要求类与类之间尽量不直接通信,如果类之间需要通信就通过第三方转发的方式,这就直接导致 了系统中存在大量的中介类,这些类存在的唯一原因是为了传递类与类之间的相互调用关系,这就毫无疑问的增加了系 统的复杂度。解决这个问题的方式是:使用依赖倒转原则(通俗的讲就是要针对接口编程,不要针对具体编程),这要 就可以是调用方和被调用方之间有了一个抽象层,被调用方在遵循抽象层的前提下就可以自由的变化,此时抽象层成了 调用方的朋友。 如下图所示: 故事分析: 温馨提示:  迪米特法则是一种面向对象系统设计风格的一种法则,尤其适合做大型复杂系统设计指导原则。但是也会造成系统的不 同模块之间的通信效率降低,使系统的不同模块之间不容易协调等缺点。同时,因为迪米特法则要求类与类之间尽量不 直接通信,如果类之间需要通信就通过第三方转发的方式,这就直接导致了系统中存在大量的中介类,这些类存在的唯 一原因是为了传递类与类之间的相互调用关系,这就毫无疑问的增加了系统的复杂度。解决这个问题的方式是:使用依 赖倒转原则(通俗的讲就是要针对接口编程,不要针对具体编程),这要就可以是调用方和被调用方之间有了一个抽象 层,被调用方在遵循抽象层的前提下就可以自由的变化,此时抽象层成了调用方的朋友。 六.合成聚合复用原则  合成复用原则跟简洁的表述是:要尽量使用合成和聚合,尽量不要使用继承。 聚合(Aggregation)是关联关系的一种,用来表示一种整体和部分的拥有关系。整体持有对部分的引用,可以调用部 分的能够被访问的方法和属性等,当然这种访问往往是对接口和抽象类的访问。作为部分可以可以同时被多个新的对象 引用,同时为多个新的对象提供服务。 合成(Composition)也是关联关系的一种,但合成是一种比聚合强得多的一种关联关系。在合成关系里面,部分和整 体的生命周期是一样的。作为整体的新对象完全拥有对作为部分的支配权,包括负责和支配部分的创建和销毁等,即要 负责作为部分的内存的分配和内存释放等。从这里也可以看出来,一个合成关系中的成员对象是不能喝另外的一个合成 关系共享的。 为何“要尽量使用合成和聚合,尽量不要使用继承”呢?这是因为:第一,继承复用破坏包装,它把超类的实现细节直接 暴露给了子类,这违背了信息隐藏的原则;第二:如果超类发生了改变,那么子类也要发生相应的改变,这就直接导致 了类与类之间的高耦合,不利于类的扩展、复用、维护等,也带来了系统僵硬和脆弱的设计。而是用合成和聚合的时候 新对象和已有对象的交互往往是通过接口或者抽象类进行的,就可以很好的避免上面的不足,而且这也可以让每一个新 的类专注于实现自己的任务,符合单一职责原则. 七.工厂模式 简单工厂模式解释: 简单工厂模式(Simple Factory Pattern)属于类的创新型模式,又叫静态工厂方法模式(Static FactoryMethod  Pattern),是通过专门定义一个类来负责创建其他类的实例,被创建的实例通常都具有共同的父类。 九.单例模式 单例模式解释: GoF 对单例模式(Singleton Pattern)的定义是:保证一个类、只有一个实例存在,同时提供能对该实例加以访问 的全局访问方法。 单例模式是一种对象创建型模式,使用单例模式,可以保证为一个类只生成唯一的实例对象。也就是说,在整个程 序空间中,该类只存在一个实例对象。 单例模式的要点有三个;一是某个类只能有一个实例;二是它必须自行创建这个实例;三是它必须自行向整个系统 提供这个实例。 十.原型模式 原型模式解释: 原型模式(Prototype Pattern)是一种对象创建型模式,它采取复制原型对象的方法来创建对象的实例。使用 Prototype 模式创建的实例,具有与原型一样的初始化数据 原型模式使用场景分析及代码实现: 在上面的使用场景中,因为 GG 打字太慢经常被女朋友怪罪,所以有了拷贝网上肉麻情话的和主要聊天话题内容的 办法。这样,以后 GG 每次和 MM 聊天的时候只需要把原话拷贝出来,加以适当修改就行,省时省力,而且效果绝佳^_^, 这就是设计模式的原型模式的使用的好处 O(∩_∩)O~ UML 模型图如下所示: 原型对象一般在适用于一下场景: 在创建对象的时候,我们不仅希望被创建的对象继承其类的基本机构,而且还希望继承原型对象的数据。 希望对目标对象的修改不影响既有的原型对象(深度克隆的时候可以完全互不影响)。

上一篇:Oracle_函数_03
下一篇:利用Nutch和IKanalyzer构造中文分…

相关文章

相关评论