美文网首页《理论篇》
《编程设计模式----理论篇》

《编程设计模式----理论篇》

作者: 不够果断是种癌 | 来源:发表于2019-06-27 10:49 被阅读0次

    说明本文仅供自我学习,为学习笔记参考书籍《大话设计模式》。

    设计模式不是为了专门刻意去用,而是我用了这个设计模式能给我带来什么好处与坏处,还有没有比这个设计模式更适合的。最终的目的是为我们带来好处。

    -----------------------工厂模式

    简单工厂模式,又叫做静态工厂方法模式。简单的工厂模式由一个工厂对象决定出哪一种产品类的实例。

    工厂方法模式,在工厂方法模式中,核心的工厂类不再负责所有产品的创建,而是将具体的创建的工作交给子类去做。该核心类成为一个抽象工厂角色,仅负责给出具体工厂子类必须实现的接口,而不接受哪一个产品类应该被实例化这种细节。

    抽象工厂模式是所有形态的工厂模式中最为抽象和最具一般性的一种形态。抽象工厂模式是指当有多个抽象角色时,使用的一种工厂模式。抽象工厂模式可以向客户端提供一个接口,使客户端在不必指定产品的具体的情况下,创建多个产品族中的产品对象。根据里氏替换原则,任何接受父类型的地方,都应当能够接受子类型。因此,实际上系统所需要的,仅仅是类型与这些抽象产品角色相同的一些实例,而不是这些抽象产品的实例。换言之,也就是这些抽象产品的具体子类的实例。工厂类负责创建抽象产品的具体子类的实例。为创建一组相关或相互依赖的对象提供一个接口,而且无需指定他们的具体类。

    工厂模式的运用在iOS中,table创建加载不同类型的cell的时候。

    这样写太麻烦了----------------------------下面还是简短点----------------------------------------

    ------------------------策略模式

    它定义了算法家族,分别封装起来,让他们之间可以互相替换,此模式替换算法不会影响到原来的客户。

    -----------------------单一职责原则

    就一个类而言,应该仅有一个影响它变化的原因。

    -----------------------开放,封闭原则

    是说软件实体(类,模块,函数等等)应该可以扩展,但是不可以修改。但是不应该过度抽象扩展。

    ------------------------依赖到转原则

    高层模块不应该依赖低层模块。两个都应该依赖抽象。

    抽象不应该依赖细节,细节应该依赖抽象。

    ------------------------里氏代换原则

    子类型必须能够替换他们的父类型。

    ------------------------装饰模式

    动态地给一个对象添加一些额外的职责,就增加功能来说。

    -------------------------代理模式

    为其他对象提供一种代理以控制这个对象的访问。

    -------------------------原型模式

    用原型实例指定创建对象的种类,并且通过拷贝这些原型创建新的对象。

    -------------------------浅复制

    被复制对象的所有变量都含有对原来的对象相同的值,而所有的对其他对象的引用仍然指向原来的对象。

    -------------------------深复制

    深复制把引用的对象的变量指向复制过的新的对象,而不是原来被引用的对象。

    ------------------------模版方法模式

    定义一个操作中的算法的骨架,而将延迟到子类中。模版方法使得子类不改变一个算法的结构,即可重定义该算法的某些的特定步骤。

    -------------------------迪米特法则

    如果2个类不必彼此通信,那么2个类就不应当发生直接的相互作用。如果一个类需要另一个类的某个方法可以由第三者转发这个调用。

    -------------------------外观模式

    为子系统中的一组接口提供一个一致的界面。此模式定义了一个高层的接口,这个接口使得这一子系统更容易使用。

    -------------------------构建者模式

    将一个复杂的对象的构建与它的表示分离,使得同样的构建过程可以创建不同的来表示。建造者模式是当创建复杂对象的算法应该独立于该对象的组成部分以及他们的装配方式适用的模式。

    -------------------------观察者模式

    定义了一种一对多的依赖关系,让多个观察者同时监听某一个主题对象。这个主题发生变化时会通知某一个观察者,使他们能够自助更新自己。

    --------------------------状态模式

    当一个对象的内在状态改变时允许改变其行为,这个对象看起来像是改变了其类。状态模式主要解决的是控制一个对象状态转换的条件表达式过于复杂时的情况。把状态的判断逻辑移到表示不同的状态的一系列类当中,可以把复杂的逻辑简单化。

    --------------------------适配器模式

    将一个类的接口转换为客户希望的另一个接口。适配器模式使得原本由于接口不兼容而不能一起工作的那些类一起工作。

    --------------------------备忘录模式

    在不破坏封装性的前提下,捕获一个对象的内部状态,并在对象之外保存这个状态,这样以后可以直接将对象恢复先保存的状态。

    --------------------------组合模式

    将对象组合成树形结构以表示“部分-整体”的层次结构。组合模式使得用户对单个对象和组合对象的使用的一致性。

    --------------------------迭代器模式

    提供一种方法顺序访问一个聚合对象中的各个元素,而又不暴露出该对象的内部表示。

    --------------------------单例模式

    保证一个类仅有一个实例,并提供一个访问它的全局访问点。

    --------------------------合成/聚合复用原则

    尽量使用合成/聚合。尽量不要使用类继承。

    聚合表示一种弱的“拥有”关系,体现的是A对象可以包含B对象,但是B对象不是A对象的一部分;合成则是一种强的“拥有”关系,体现了严格的部分和整体的关系,部分和整体的生命周期是一样。举个比方大雁又2个翅膀,翅膀与大雁是部分与整体的关系,并且他们的生命周期都是相同的,于是翅膀和大雁就是合成关系。而大雁是群居动物,所以每只大雁都是属于一个雁群,一个雁群可以有多知大雁,所以大雁和雁群是聚合关系。

    -----------------------桥接模式

    将抽象部分与它的实现部分分离。是他们都可以独立的变化。

    -----------------------命令模式

    将一个请求封装为一个对象,从而使用你可以用不同的请求对客户进行参数化;对请求排队或几率请求日志,以及支持可撤销操作。

    -----------------------职责链模式

    使多个对象都有机会处理请求,从而避免请求对发送者和接收者之间的耦合关系。将这个对象连成一条链,并沿着这条链传递该请求,直到有一个对象处理它为止。

    ------------------------中介者模式

    用一个中介对象来封装一些列的对象交互,中介者使各对象不需要显示的相互引用,从而使其耦合松散,而且可以独立的改变它们之间的交互。

    ------------------------享元模式

    运用共享技术有效地支持大量颗粒度的对象。

    享元模式可以避免大量非常相似类的开销。在程序设计中,有时需要生成大量细颗粒度的类实例来表示数据。如果能发现这些实例除了几个参数外基本都是相同的,有时就能够大幅度的减少需要实例化的类的数量。如果能把那些参数移到类实例的外面,在方法调用时将它们传递进来。就可以共享大幅度的减少实例的数目。

    ----------------------解释器模式

    给定一个语言,定义它的文法的一种表示,并定义一个解释器,这个解释器使用该表示解释语言中的句子。如果一种特定的问题发生的频率足够高,那么kennel就值得将该问题的哥哥实例表述为一个简单语言中的句子。这样就可以构造一个解释器,该解释器通过解释这些句子来解决该问题。

    ------------------------------------访问者模式

    表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。

    相关文章

      网友评论

        本文标题:《编程设计模式----理论篇》

        本文链接:https://www.haomeiwen.com/subject/bxdccctx.html