精华内容
下载资源
问答
  • java六大设计原则 个人见解层次分明
  • JAVA六大设计原则 和 23种设计模式

    千次阅读 2019-04-02 21:22:17
    相关书籍:《大话设计...JAVA六大设计原则 JAVA设计模式提供六个基本原则,分别是: 开闭原则(OCP) - The Open-Closed Principle 单一职责原则(SRP) - Single Responsibility Principle 里氏替换原则(LSP) - Lisko...

    相关书籍:《大话设计模式》、《Java设计模式》、《设计模式之禅》、《研磨设计模式》、《Head First 设计模式》

    JAVA六大设计原则

    JAVA设计模式提供六个基本原则,分别是:

    1. 开闭原则(OCP) - The Open-Closed Principle
    2. 单一职责原则(SRP) - Single Responsibility Principle
    3. 里氏替换原则(LSP) - Liskov Substitution Principle
    4. 依赖倒置原则(DIP) - Dependency Inversion Principle
    5. 接口隔离原则(ISP) - Interface Segregation Principle
    6. 迪米特法则(DP) - Demeter Principle

    开闭原则

    对扩展开放,对修改关闭。
    开闭原则宗旨是在已有系统基础上进行开发,不要对正常运行的代码进行修改操作。需要扩展需求时,通过添加新类或者新代码来实现,对已有代码做到最少修改,甚至是零修改。

    单一职责原则

    接口或类只提供一种业务实现。
    单一职责原则宗旨是每个接口、类的功能,只能用来做专门的事,强调系统内业务职责唯一,避免职责扩散,做到业务统一管理。

    里氏替换原则

    使用父类的地方可以用子类来替换。
    里氏替换原则宗旨是子类尽量不要重写父类或者接口中已经实现的方法,即子类和父类逻辑保持一致性。

    依赖倒置原则

    面向抽象编程,即通过接口或者抽象类提供依赖关系。
    依赖倒置原则宗旨是指各个业务模块之间依赖关系,通过约定的接口或者抽象类来实现,不涉及具体的实现细节,细节交给具体的实现类来完成。
    JAVA实现依赖倒置的方式有三种:

    • 构造方法
    • setter方法
    • 接口注入

    接口隔离原则

    接口中的方法和属性都是实现类所需要,没有额外无用信息。
    接口隔离原则宗旨是接口的完美复用,接口的内容对于实现来说无冗余代码。

    迪米特原则

    迪米特原则又叫最少知道原则,核心思想是低耦合,高内聚。
    迪米特原则宗旨是弱化代码(通常指类)之间的依赖关系。

    总结

    六大设计原则是代码设计的基本原则。设计原则规范了开发人员如何去设计和实现代码,来提高程序的规范性、可读性、扩展性和维护性。

    JAVA23种设计模式

    三个类型:创建型、结构型和行为型
    在这里插入图片描述

    创建型有:

    一、Singleton,单例模式:保证一个类只有一个实例,并提供一个访问它的全局访问点

    二、Abstract Factory,抽象工厂:提供一个创建一系列相关或相互依赖对象的接口,而无须指定它们的具体类。
    三、Factory Method,工厂方法:定义一个用于创建对象的接口,让子类决定实例化哪一个类,Factory Method使一个类的实例化延迟到了子类。

    四、Builder,建造模式:将一个复杂对象的构建与他的表示相分离,使得同样的构建过程可以创建不同的表示。

    五、Prototype,原型模式:用原型实例指定创建对象的种类,并且通过拷贝这些原型来创建新的对象。

    行为型有:

    六、Iterator,迭代器模式:提供一个方法顺序访问一个聚合对象的各个元素,而又不需要暴露该对象的内部表示。

    七、Observer,观察者模式:定义对象间一对多的依赖关系,当一个对象的状态发生改变时,所有依赖于它的对象都得到通知自动更新。

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

    九、Command,命令模式:将一个请求封装为一个对象,从而使你可以用不同的请求对客户进行参数化,对请求排队和记录请求日志,以及支持可撤销的操作。

    十、State,状态模式:允许对象在其内部状态改变时改变他的行为。对象看起来似乎改变了他的类。

    十一、Strategy,策略模式:定义一系列的算法,把他们一个个封装起来,并使他们可以互相替换,本模式使得算法可以独立于使用它们的客户。

    十二、China of Responsibility,职责链模式:使多个对象都有机会处理请求,从而避免请求的送发者和接收者之间的耦合关系

    十三、Mediator,中介者模式:用一个中介对象封装一些列的对象交互。

    十四、Visitor,访问者模式:表示一个作用于某对象结构中的各元素的操作,它使你可以在不改变各元素类的前提下定义作用于这个元素的新操作。

    十五、Interpreter,解释器模式:给定一个语言,定义他的文法的一个表示,并定义一个解释器,这个解释器使用该表示来解释语言中的句子。

    十六、Memento,备忘录模式:在不破坏对象的前提下,捕获一个对象的内部状态,并在该对象之外保存这个状态。

    结构型有:

    十七、Composite,组合模式:将对象组合成树形结构以表示部分整体的关系,Composite使得用户对单个对象和组合对象的使用具有一致性。

    十八、Facade,外观模式:为子系统中的一组接口提供一致的界面,facade提供了一高层接口,这个接口使得子系统更容易使用。

    十九、Proxy,代理模式:为其他对象提供一种代理以控制对这个对象的访问

    二十、Adapter,适配器模式:将一类的接口转换成客户希望的另外一个接口,Adapter模式使得原本由于接口不兼容而不能一起工作那些类可以一起工作。

    二十一、Decrator,装饰模式:动态地给一个对象增加一些额外的职责,就增加的功能来说,Decorator模式相比生成子类更加灵活。

    二十二、Bridge,桥接模式:将抽象部分与它的实现部分相分离,使他们可以独立的变化。

    二十三、Flyweight,享元模式:运用共享技术有效地支持大量细粒度的对象。

    感谢

    简书:Android的设计模式-设计模式的六大原则
    segmentfault:设计类六大原则
    掘金:设计模式精简图册
    新浪博客:关于23种设计模式

    展开全文
  • 设计模式的六大原则
  • java设计六大原则

    千次阅读 2018-09-28 09:15:00
    类的设计原则 依赖倒置原则-Dependency Inversion Principle (DIP)  里氏替换原则-Liskov Substitution Principle (LSP)  接口分隔原则-Interface Segregation Principle (ISP)  单一职责原则-Single ...

     

    类的设计原则    

    1. 依赖倒置原则-Dependency Inversion Principle (DIP) 
    2. 里氏替换原则-Liskov Substitution Principle (LSP) 
    3. 接口分隔原则-Interface Segregation Principle (ISP) 
    4. 单一职责原则-Single Responsibility Principle (SRP) 
    5. 开闭原则-The Open-Closed Principle (OCP)

    一. Dependency Inversion Principle (DIP) - 依赖倒置原则

          依赖:在程序设计中,如果一个模块a使用或调用了另一个模块b,我们称模块a依赖模块b。

    高层模块与低层模块:往往在一个应用程序中,我们有一些低层次的类,这些类实现了一些基本的或初级的操作,我们称之为低层模块;另外有一些高层次的类,这些类封装了某些复杂的逻辑,并且依赖于低层次的类,这些类我们称之为高层模块。

    依赖倒置原则的2个重要方针:

    A. 高层模块不应该依赖于低层模块,二者都应该依赖于抽象
    B. 抽象不应该依赖于细节,细节应该依赖于抽象

     

    为什么叫做依赖倒置(Dependency Inversion)呢?

    面向对象程序设计相对于面向过程(结构化)程序设计而言,依赖关系被倒置了。因为传统的结构化程序设计中,高层模块总是依赖于低层模块。

    问题的提出:

    Robert C. Martin在原文中给出了“Bad Design”的定义:

    1. 系统很难改变,因为每个改变都会影响其他很多部分。
    2. 当你对某地方做一修改,系统的看似无关的其他部分都不工作了。
    3. 系统很难被另外一个应用重用,因为你很难将要重用的部分从系统中分离开来。

    导致“Bad Design”的很大原因是“高层模块”过分依赖“低层模块”。一个良好的设计应该是系统的每一部分都是可替换的。如果“高层模块”过分依赖“低层模块”,一方面一旦“低层模块”需要替换或者修改,“高层模块”将受到影响;另一方面,高层模块很难可以重用。
    比如,一个Copy模块,需要把来自Keyboard的输入复制到Print,即使对Keyboard和Print的封装已经做得非常好,但如果Copy模块里直接使用Keyboard与Print,Copy任很难被其他应用环境(比如需要输出到磁盘时)重用。

    问题的解决:

    为了解决上述问题,Robert C. Martin提出了OO设计的Dependency Inversion Principle (DIP) 原则。

        DIP给出了一个解决方案:在高层模块与低层模块之间,引入一个抽象接口层。
    High Level Classes(高层模块) --> Abstraction Layer(抽象接口层) --> Low Level Classes(低层模块)
    抽象接口是对低层模块的抽象,低层模块继承或实现该抽象接口。
    这样,高层模块不直接依赖低层模块,高层模块与低层模块都依赖抽象接口层。
    当然,抽象也不依赖低层模块的实现细节,低层模块依赖(继承或实现)抽象定义。

    Robert C. Martin给出的DIP方案的类的结构图:

    PolicyLayer-->MechanismInterface(abstract)--MechanismLayer-->UtilityInterface(abstract)--UtilityLayer
    类与类之间都通过Abstract Layer来组合关系。

     

    二. Liskov Substitution Principle (LSP) - 里氏替换原则

    所有引用基类的地方必须能透明地使用其子类的对象。也就是说,只有满足以下2个条件的OO设计才可被认为是满足了LSP原则:

    A  不应该在代码中出现if/else之类对子类类型进行判断的条件。以下代码就违反LSP定义。

     

    B  子类应当可以替换父类并出现在父类能够出现的任何地方,或者说如果我们把代码中使用基类的地方用它的子类所代替,代码还能正常工作。

    里氏替换原则LSP是使代码符合开闭原则的一个重要保证。同时LSP体现了:
    1) 类的继承原则:如果一个继承类的对象可能会在基类出现地方出现运行错误,则该子类不应该从该基类继承,或者说,应该重新设计它们之间的关系。
    2)动作正确性保证:从另一个侧面上保证了符合LSP设计原则的类的扩展不会给已有的系统引入新的错误。

    类的继承原则:
    Robert C. Martin举了Rectangle和Square的例子。这里沿用这个例子,但用Java语言对其加以重写,并忽略了某些细节只列出下面的精要部分来说明 里氏替换原则 对类的继承上的约束。

    这里Rectangle是基类,Square从Rectangle继承。这种继承关系有什么问题吗?

    假如已有的系统中存在以下既有的业务逻辑代码:

    则对应于扩展类Square,在调用既有业务逻辑时:

    会抛出一个RuntimeException异常。这显然违反了LSP原则。

    动作正确性保证:
    因为LSP对子类的约束,所以为已存在的类做扩展构造一个新的子类时,根据LSP的定义,不会给已有的系统引入新的错误。

    Design by Contract

             根据Bertrand Meyer提出的Design by Contract(DBC:基于合同的设计)概念的描述,对于类的一个方法,都有一个前提条件以及一个后续条件,前提条件说明方法接受什么样的参数数据等,只有前提条件得到满足时,这个方法才能被调用;同时后续条件用来说明这个方法完成时的状态,如果一个方法的执行会导致这个方法的后续条件不成立,那么此方法也不应该正常返回。
             现在把前提条件以及后续条件应用到继承子类中,子类方法应该满足:
    1)前提条件不强于基类.
    2)后续条件不弱于基类.
            换句话说,通过基类的接口调用一个对象时,用户只知道基类前提条件以及后续条件。因此继承类不得要求用户提供比基类方法要求的更强的前提条件,亦即,继承类方法必须接受任何基类方法能接受的任何条件(参数)。同样,继承类必须顺从基类的所有后续条件,亦即,继承类方法的行为和输出不得违反由基类建立起来的任何约束,不能让用户对继承类方法的输出感到困惑。这样,我们就有了基于合同的LSP,基于合同的LSP是LSP的一种强化。

           在很多情况下,在设计初期我们类之间的关系不是很明确,LSP则给了我们一个判断和设计类之间关系的基准:需不需要继承,以及怎样设计继承关系。

     

    三. Interface Segregation Principle (ISP) - 接口分隔原则

          不能强迫用户去依赖那些他们不使用的接口。换句话说,使用多个专门的接口比使用单一的总接口总要好。它包含了2层意思:
    1)接口的设计原则:接口的设计应该遵循最小接口原则,不要把用户不使用的方法塞进同一个接口里。
       如果一个接口的方法没有被使用到,则说明该接口过胖,应该将其分割成几个功能专一的接口。
    2)接口的依赖(继承)原则:如果一个接口a依赖(继承)另一个接口b,则接口a相当于继承了接口b的方法,那么继承了接口b后的接口a也应该遵循上述原则:不应该包含用户不使用的方法。   反之,则说明接口a被b给污染了,应该重新设计它们的关系。

          如果用户被迫依赖他们不使用的接口,当接口发生改变时,他们也不得不跟着改变。换而言之,一个用户依赖了未使用但被其他用户使用的接口,当其他用户修改该接口时,依赖该接口的所有用户都将受到影响。这显然违反了开闭原则,也不是我们所期望的。

    下面我们举例说明怎么设计接口或类之间的关系,使其不违反ISP原则。
    假如有一个Door,有lock,unlock功能,另外,可以在Door上安装一个Alarm而使其具有报警功能。用户可以选择一般的Door,也可以选择具有报警功能的Door。

    有以下几种设计方法:

    ISP原则的违反例:

    方法一:
    在Door接口里定义所有的方法。图:

    但这样一来,依赖Door接口的CommonDoor却不得不实现未使用的alarm()方法。违反了ISP原则。

    方法二:
    在Alarm接口定义alarm方法,在Door接口定义lock,unlock方法,Door接口继承Alarm接口。


    跟方法一一样,依赖Door接口的CommonDoor却不得不实现未使用的alarm()方法。违反了ISP原则。

    遵循ISP原则的例:


    方法三:通过多重继承实现

    Adapter设计模式的实现。
    第2)种方案更具有实用性。
    这种设计遵循了ISP设计原则。

    方法四:通过委托实现

    在Alarm接口定义alarm方法,在Door接口定义lock,unlock方法。接口之间无继承关系。CommonDoor实现Door接口,
    AlarmDoor有2种实现方案:
    1)同时实现Door和Alarm接口。
    2)继承CommonDoor,并实现Alarm接口。该方案是继承方式的

    小结

    Interface Segregation Principle (ISP)从对接口的使用上为我们对接口抽象的颗粒度建立了判断基准:在为系统设计接口的时候,使用多个专门的接口代替单一的胖接口。

     

    四. Single Responsibility Principle (SRP) - 单一职责原则

     

        永远不要让一个类存在多个改变的理由。换句话说,如果一个类需要改变,改变它的理由永远只有一个。如果存在多个改变它的理由,就需要重新设计该类。

    SRP(Single Responsibility Principle)原则的核心含意是:只能让一个类有且仅有一个职责。这也是单一职责原则的命名含义。

    为什么一个类不能有多于一个以上的职责呢?
    如果一个类具有一个以上的职责,那么就会有多个不同的原因引起该类变化,而这种变化将影响到该类不同职责的使用者(不同用户):
    1,一方面,如果一个职责使用了外部类库,则使用另外一个职责的用户却也不得不包含这个未被使用的外部类库。
    2,另一方面,某个用户由于某原因需要修改其中一个职责,另外一个职责的用户也将受到影响,他将不得不重新编译和配置。这违反了设计的开闭原则,也不是我们所期望的。

     

    职责的划分

    既然一个类不能有多个职责,那么怎么划分职责呢?
    Robert.C Martin给出了一个著名的定义:所谓一个类的一个职责是指引起该类变化的一个原因。如果你能想到一个类存在多个使其改变的原因,那么这个类就存在多个职责。

    Single Responsibility Principle (SRP)的原文里举了一个Modem的例子来说明怎么样进行职责的划分,这里我们也沿用这个例子来说明一下:

    SRP违反例:
    Modem.java

    咋一看,这是一个没有任何问题的接口设计。但事实上,这个接口包含了2个职责:第一个是连接管理(dial, hangup);另一个是数据通信(send, recv)。很多情况下,这2个职责没有任何共通的部分,它们因为不同的理由而改变,被不同部分的程序调用。
    所以它违反了SRP原则。

    下面的类图将它的2个不同职责分成2个不同的接口,这样至少可以让客户端应用程序使用具有单一职责的接口:

    让ModemImplementation实现这两个接口。我们注意到,ModemImplementation又组合了2个职责,这不是我们希望的,但有时这又是必须的。通常由于某些原因,迫使我们不得不绑定多个职责到一个类中,但我们至少可以通过接口的分割来分离应用程序关心的概念。
    事实上,这个例子一个更好的设计应该是这样的,如图:

    小结:

    Single Responsibility Principle (SRP)从职责(改变理由)的侧面上为我们对类(接口)的抽象的颗粒度建立了判断基准:在为系统设计类(接口)的时候应该保证它们的单一职责性。

     

    五. The Open-Closed Principle (OCP) - 开闭原则

    开闭原则(OCP:Open-Closed Principle)是指在进行面向对象设计(OOD:Object Oriented Design)中,设计类或其他程序单位时,应该遵循:
    - 对扩展开放(open)
    - 对修改关闭(closed)
     
    开闭原则是判断面向对象设计是否正确的最基本的原理之一。 根据开闭原则,在设计一个软件系统模块(类,方法)的时候,应该可以在不修改原有的模块(修改关闭)的基础上,能扩展其功能(扩展开放)。
    A  扩展开放:某模块的功能是可扩展的,则该模块是扩展开放的。软件系统的功能上的可扩展性要求模块是扩展开放的。
     B 修改关闭:某模块被其他模块调用,如果该模块的源代码不允许修改,则该模块修改关闭的。软件系统的功能上的稳定性,持续性要求是修改关闭的。

    这也是系统设计需要遵循开闭原则的原因:
    1)稳定性。开闭原则要求扩展功能不修改原来的代码,这可以让软件系统在变化中保持稳定。
    2)扩展性。开闭原则要求对扩展开放,通过扩展提供新的或改变原有的功能,让软件系统具有灵活的可扩展性。
    遵循开闭原则的系统设计,可以让软件系统可复用,并且易于维护。

    开闭原则的实现方法

    为了满足开闭原则的 对修改关闭(closed for modification) 原则以及扩展开放(open for extension) 原则,应该对软件系统中的不变的部分加以抽象,在面向对象的设计中,
    A 可以把这些不变的部分加以抽象成不变的接口,这些不变的接口可以应对未来的扩展;
    B 接口的最小功能设计原则。根据这个原则,原有的接口要么可以应对未来的扩展;不足的部分可以通过定义新的接口来实现;
    C 模块之间的调用通过抽象接口进行,这样即使实现层发生变化,也无需修改调用方的代码。

    接口可以被复用,但接口的实现却不一定能被复用。接口是稳定的,关闭的,但接口的实现是可变的,开放的。可以通过对接口的不同实现以及类的继承行为等为系统增加新的或改变系统原来的功能,实现软件系统的柔软扩展。

             简单地说,软件系统是否有良好的接口(抽象)设计是判断软件系统是否满足开闭原则的一种重要的判断基准。现在多把开闭原则等同于面向接口的软件设计。

     

    开闭原则的相对性

    软件系统的构建是一个需要不断重构的过程,在这个过程中,模块的功能抽象,模块与模块间的关系,都不会从一开始就非常清晰明了,所以构建100%满足开闭原则的软件系统是相当困难的,这就是开闭原则的相对性。但在设计过程中,通过对模块功能的抽象(接口定义),模块之间的关系的抽象(通过接口调用),抽象与实现的分离(面向接口的程序设计)等,可以尽量接近满足开闭原则。
     

     

    本文转自:https://blog.csdn.net/u014612273/article/details/25284913 ,博主也不是作者,仅供参考

    展开全文
  • Java设计六大原则

    万次阅读 2018-06-08 23:14:43
    为达到目的,需对系统进行抽象化设计(关键); UML举例: 3.里氏代换原则(LSP) 子类必须能够替换它们的基类型,基类与子类可互换,客户端没有察觉情况下; 低耦合; 很容易实现同一父类下的各个子类的互换,而...

    1.遵循单一职责原则


    一个类只专注于做一件事;
    高内聚,低耦合;

    2.开放-封闭原则


    对拓展开放,对修改关闭(尽可能不动原有代码进行拓展);
    高内聚,低耦合;
    为达到目的,需对系统进行抽象化设计(关键);
    UML举例:
    这里写图片描述

    3.里氏代换原则(LSP)


    子类必须能够替换它们的基类型,基类与子类可互换,客户端没有察觉情况下;
    低耦合;
    很容易实现同一父类下的各个子类的互换,而客户端可以毫不察觉;

    UML实例:
    这里写图片描述

    士兵只能使用WeaponGun,而无法使用ToyGun杀敌,如果使用ToyGun将会出错。这就是里氏替换原则。

    4.依赖倒置原则


    这个是开闭原则的基础,具体内容:面向接口编程,依赖于抽象而不依赖于具体。写代码时用到具体类时,不与具体类交互,而与具体类的上层接口交互。

    5.接口隔离原则(Interface Segregation Principle)


    使用多个专一功能的接口比使用一个总接口总要好,但不能过渡;
    一个接口不能过于臃肿;
    高内聚
    会使一个软件系统功能拓展时,修改的压力不会影响到别的对象那去;
    UML实例:
    这里写图片描述

    Model只要满足好身材这个条件,就有可能成为模特,漂亮女孩满足好身材和好。AngelaBaby即有好身材又好。

    6.迪米特法则(Law of Demeter)


    又叫最少知识原则;
    对象与对象之间应该使用尽可能少的方法来关联,避免千丝万缕的关系;
    低耦合;
    类知道其他类应尽量少;
    类可以访问其他类的方法或者属性也应尽量少;

    这里写图片描述

    如果Lily和Jack自己做hamburg那么就会与Vegetable、Meat、Bread产生千丝万缕关系。上图,则由KFC来做,这样Lily和Jack就只与Hamburg有关关联,与材料就没有关联了。


    展开全文
  • java程序设计六大原则

    千次阅读 2019-04-01 16:10:13
    六大设计原则 一、单一职责原则(single responsibility principle)简称SRP原则: 一个接口或者类只有一个原因引起变化,即一个接口或者类只有一个职责,负责一件事情。(此原则同样适用于方法) 好处: 1、复杂性...

    (2019年04月阅读《设计模式之禅》-秦小波,阅读后自己总结如下)

    六大设计原则
    一、单一职责原则(single responsibility principle)简称SRP原则:
    一个接口或者类只有一个原因引起变化,即一个接口或者类只有一个职责,负责一件事情。(此原则同样适用于方法)
    好处:
    1、复杂性降低;2、可读性提高;3、可维护性提高;4、变更风险降低

    二、里氏替换原则:父类能出现的地方子类就可以出现。
    定义解释:
    1、子类必须完全实现父类的方法;
    2、子类可以有自己的个性;
    3、覆盖或者实现父类的方法时,输入参数可以被放大;
    public class Father {
        public Collection doSomething(HashMap map) {
            System.out.println("父类被执行了");
            return map.values();
        }
    }

    public class Son extends Father {
        public Collection  doSomething(Map  map) {
            System.out.println("子类被执行了");
            return map.values();
        }    
    }
    public static void main(String[] args) {
        Father father = new Father();
        Son son = new Son();
        HashMap<Object,Object> map = new HashMap<>();
        
        father.doSomething(map);
        son.doSomething(map);
    }
    以上代码执行时,子类重载了父类的doSomething方法,并且放大输入参数Hashmap→Map,执行以后,出现相同的结果,
    均输出"父类被执行了",并没有歪曲父类的意图,不会引起业务逻辑混乱,符合里氏替换原则。
    4、覆写或者实现父类的方法时,输出结果可以被缩小;

    三、依赖倒置原则:
    1、高层不应该依赖底层,两者都应该依赖其抽象;
    2、抽象不应该依赖细节,细节应该依赖抽象;
    即模块间的依赖通过抽象发生,实现类之间不发生直接的依赖关系,其依赖关系是通过接口或者抽象类产生的。
    更加简单的定义就是"面向接口编程(OOD:Object-Oriented Design)"

    四、接口隔离原则
    定义解释:
    1、接口要尽量小
    2、接口要高内聚,高内聚就是尽量减少公布public方法
    3、接口要为个体提供定制服务,即只提供访问者需要的方法
    4、接口设计是有限度的
    通俗的讲,接口尽量细化,同时接口中的方法尽量少。
    说明:单一职责原则侧重于业务逻辑,即职责尽量少;而接口隔离原则侧重于接口中的方法尽量少。

    五、迪米特法则
    也称为最少知识原则:一个对象应该对其他对象有最少的了解。通俗的讲:一个类应该对自己需要耦合或者调用的类知道的越少越好

    六、开闭原则
    软件实体应该对扩展开放,对修改关闭。就是说应该通过扩展来实现变化,而不是通过修改已有的代码来实现变化。

    展开全文
  • JAVA设计模式】设计六大原则

    千次阅读 多人点赞 2018-12-28 09:02:18
    - 单一职责原则(SRP) 定义:就一个类而言,应该仅有一个引起它变化的原因。 从这句定义我们很难理解它的含义,通俗讲就是我们不要让一个类承担过多的职责。如果一个类承担的职责过多,就等于把这些职责耦合在一起...
  • 设计模式+六大原则pdf

    2019-04-23 21:40:42
    孙玉山主编的设计模式所有设计模式+体系结构题目案例源码
  • java开发六大基本原则

    万次阅读 多人点赞 2017-11-27 10:12:49
     关于设计模式的六大设计原则的资料网上很多,但是很多地方解释地都太过于笼统化,我也找了很多资料来看,发现CSDN上有几篇关于设计模式的六大原则讲述的比较通俗易懂,因此转载过来。  原作者博客链接:...
  • 1.单一职责原则: 不要存在多于一个导致类变更的原因 ...接口隔离原则告诉我们在设计接口的时候要精简单一;迪米特法则告诉我们要降低耦合。而开闭原则是总纲,他告诉我们要对扩展开放,对修改关闭。
  • java面向对象设计六大原则
  • Java设计模式的六大原则

    千次阅读 2018-03-20 13:59:09
    单一职责原则 单一职责原则是最简单的面向对象设计原则,它用于控制类的粒度大小。单一职责原则定义如下:单一职责原则(Single Responsibility Principle, SRP):一个类只负责一个功能领域中的相应职责,或者可以...
  • 六大设计原则

    千次阅读 2019-02-22 21:54:02
    六大设计原则 1.单一职责原则(Single Responsibility Principle) 定义:应该有且仅有一个原因引起类的变更。 单一职责原则的好处: 类的复杂性降低,实现什么职责都有清晰明确的定义 可读性提高,复杂性降低 可...
  • JAVA代码设计六大原则的理解

    千次阅读 2017-10-13 23:54:16
    JAVA代码设计六大原则的理解记得有一次去面试的时候,面试官问了我好几个问题,很尴尬,好几个都没能流利得回答上来。对其中有一个问题比较深刻,他当时是这样问我的:说下代码优化的6大原则,我当时一听,在脑子...
  • 分别就是Java设计模式六大原则和常用的23种设计模式了。本篇是对六大原则的整理。(最后一种是哈姆雷特)1.开闭原则(Open Close Principle)定义:一个软件实体如类、模块和函数应该对扩展开放,对修改关闭。 开放-...
  • Java设计模式6大原则

    千次阅读 2019-03-01 18:50:45
    设计模式的6大原则,单一职责原则,开放封闭原则,里式替换原则,依赖导致原则,迪米特原则和接口隔离原则
  • JAVA设计模式之六大设计原则

    千次阅读 2018-10-16 16:26:43
    在程序设计中,我们通常要遵循以下六大原则: 单一职责原则 官方定义: 就一个类(接口、结构体、方法等等)而言,有且仅有一个引起它变化的原因。 个人理解: 通俗的来讲做一件事就是专注做一件事,不可以...
  • 例如,容易实现协议的设计Java EJB中有、无状态SessionBean的两个例子 两个例子,无状态SessionBean可会话Bean必须实现SessionBean,获取系统属性,初始化JNDI,取得Home对象的引用,创建EJB对象,计算利息等;在...
  • java面向对象程序设计(七)基本原则
  • 详细介绍了设计模式六大原则,配有示例代码和图片,有开闭原则,单一职责原则,里氏替换原则,依赖倒置原则,接口隔离原则,迪米特法则等等。
  • 设计模式的六大原则

    万次阅读 多人点赞 2019-05-16 17:50:03
    一、单一职责原则(Single Responsibility Principle) 二.开闭原则(Open-Closed Principle, OCP) 三、里氏代换原则(Liskov Substitution Principle, LSP) 四、依赖倒置原则(Dependence Inversion Principle,...
  • Java设计模式——六大设计原则

    千次阅读 2016-12-04 03:39:27
    1.单一职责原则单一职责原则的定义是类的变更的原因应该只有一个,它提出用“职责”和“变化原因”来衡量接口或类设计得是否优良,但是这两个因素都是因项目而异因环境而异的,并没有一个量化的标准 单一职责原则使...
  • java设计模式之三大分类,六大原则

    千次阅读 2017-03-11 11:18:19
    一.设计模式定义(Design Patterns)... 毫无疑问,设计模式于己于他人于系统都是多赢的,设计模式使代码编制真正工程化,设计模式是软件工程的基石,如同大厦的一块块砖石一样。项目中合理的运用设计模式可以完美的解决
  • 点击上方“方志朋”,选择“置顶或者星标”你的关注意义重大!这是设计模式系列开篇的第一篇文章。也是我学习设计模式过程中的总结。这篇文章主要讲的是面向对象设计中,我们应该遵循...
  • Java设计模式-六大原则

    千次阅读 2017-04-09 08:46:56
    六大原则 1. 单一职责原则 Single Responsibility Principle SRP原则 分清职责,接口一定要做到单一职责,方法也要做到,类尽量做到 定义:单一职责原则指的是应该有且仅有一个原因引起类的变更。 2. 里氏...
  • Java面向对象设计六大原则

    千次阅读 2018-05-17 12:00:58
    这篇文章主要讲的是面向对象设计中,我们应该遵循的六大原则。只有掌握了这些原则,我们才能更好的理解设计模式。我们接下来要介绍以下6个内容。单一职责原则——SRP开闭原则——OCP里式替换原则——LSP依赖倒置原则...
  • Java开发设计——七大原则

    千次阅读 多人点赞 2021-02-21 10:20:47
    开闭原则是面向对象程序设计的终极目标,它使软件实体拥有一定的适应性和灵活性的同时具备稳定性和延续性。具体来说,其作用如下: ◆ 对软件测试的影响:软件遵守开闭原则的话,软件测试时只需要对扩展的代码进行...
  • java代码优化六大原则

    万次阅读 2017-05-29 20:35:29
    但是这个原则的界限划分的并不是那么清晰,很程度上要依赖于开发者的个人经验来定。对于单一职责界限的划分最大的问题就是类的职责是什么,如何划分类的职责。 单一职责原则在我们实际工作中随处
  • java开发设计六大基本原则

    千次阅读 2017-03-25 18:41:23
    为达到目的,需对系统进行抽象化设计(关键); UML举例: 3.里氏代换原则(LSP) 子类必须能够替换它们的基类型,基类与子类可互换,客户端没有察觉情况下; 低耦合; 很容易实现同一父类下的各个子类的互换,...
  • Java面试题大全(2020版)

    万次阅读 多人点赞 2019-11-26 11:59:06
    发现网上很多Java面试题都没有答案,所以花了很长时间搜集整理出来了这套Java面试题大全,希望对大家有帮助哈~ 本套Java面试题大全,全的不能再全,哈哈~ 一、Java 基础 1. JDK 和 JRE 有什么区别? JDK:Java ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 53,954
精华内容 21,581
关键字:

java的六大设计原则

java 订阅