关于java:中高级面试常驻题简单说下Java面向对象设计的六大原则

5次阅读

共计 3869 个字符,预计需要花费 10 分钟才能阅读完成。

这篇文章次要讲的是面向对象设计中,咱们应该遵循的六大准则。只有把握了这些准则,咱们能力更好的了解设计模式。咱们接下来要介绍以下 6 个内容。

  • 繁多职责准则——SRP
  • 开闭准则——OCP
  • 里式替换准则——LSP
  • 依赖倒置准则——DIP
  • 接口隔离准则——ISP
  • 迪米特准则——LOD

繁多职责准则

繁多职责准则的定义是就一个类而言,应该仅有一个引起他变动的起因。也就是说一个类应该只负责一件事件。如果一个类负责了办法 M1, 办法 M2 两个不同的事件,当 M1 办法发生变化的时候,咱们须要批改这个类的 M1 办法,然而这个时候就有可能导致 M2 办法不能工作。这个不是咱们期待的,然而因为这种设计却很有可能产生。所以这个时候,咱们须要把 M1 办法,M2 办法独自拆散成两个类。让每个类只分心解决本人的办法。

繁多职责准则的益处如下:

能够升高类的复杂度,一个类只负责一项职责,这样逻辑也简略很多 进步类的可读性,和零碎的维护性,因为不会有其余奇怪的办法来烦扰咱们了解这个类的含意 当发生变化的时候,能将变动的影响降到最小,因为只会在这个类中做出批改。

开闭准则

开闭准则和繁多职责准则一样,是十分根底而且个别是常识的准则。开闭准则的定义是软件中的对象 (类,模块,函数等) 应该对于扩大是凋谢的,然而对于批改是敞开的。

当需要产生扭转的时候,咱们须要对代码进行批改,这个时候咱们应该尽量去扩大原来的代码,而不是去批改原来的代码,因为这样可能会引起更多的问题。

这个准则和繁多职责准则一样,是一个大家都这样去认为然而又没规定具体该如何去做的一种准则。

开闭准则咱们能够用一种形式来确保他,咱们用形象去构建框架,用实现扩大细节。这样当产生批改的时候,咱们就间接用形象了派生一个具体类去实现批改。

里氏替换准则

里氏替换准则是一个十分有用的一个概念。他的定义

如果对每一个类型为 T1 的对象 o1, 都有类型为 T2 的对象 o2, 使得以 T1 定义的所有程序 P 在所有对象 o1 都替换成 o2 的时候,程序 P 的行为都没有发生变化,那么类型 T2 是类型 T1 的子类型。

这样说有点简单,其实有一个简略的定义

所有援用基类的中央必须可能通明地应用其子类的对象。

里氏替换准则艰深的去讲就是:子类能够去扩大父类的性能,然而不能扭转父类原有的性能。他蕴含以下几层意思:

  • 子类能够实现父类的形象办法,然而不能笼罩父类的非形象办法。
  • 子类能够减少本人独有的办法。
  • 当子类的办法重载父类的办法时候,办法的形参要比父类的办法的输出参数更加宽松。
  • 当子类的办法实现父类的形象办法时,办法的返回值要比父类更严格。

里氏替换准则之所以这样要求是因为继承有很多毛病,他尽管是复用代码的一种办法,但同时继承在肯定水平上违反了封装。父类的属性和办法对子类都是通明的,子类能够随便批改父类的成员。这也导致了,如果需要变更,子类对父类的办法进行一些复写的时候,其余的子类无奈失常工作。所以里氏替换法令被提出来。

确保程序遵循里氏替换准则能够要求咱们的程序建设形象,通过形象去建设标准,而后用实现去扩大细节,这个是不是很耳熟,对,里氏替换准则和开闭准则往往是相互依存的。

依赖倒置准则

依赖倒置准则指的是一种非凡的解耦形式,使得高层次的模块不应该依赖于低层次的模块的实现细节的目标,依赖模块被颠倒了。这也是一个让人难懂的定义,他能够简略来说就是

高层模块不应该依赖底层模块,两者都应该依赖其形象 形象不应该依赖细节 细节应该依赖形象

在 Java 中形象指的是接口或者抽象类,两者皆不能实例化。而细节就是实现类,也就是实现了接口或者继承了抽象类的类。他是能够被实例化的。高层模块指的是调用端,底层模块是具体的实现类。在 Java 中,依赖倒置准则是指模块间的依赖是通过形象来产生的,实现类之间不产生间接的依赖关系,其依赖关系是通过接口是来实现的。这就是俗称的面向接口编程。

咱们上面有一个例子来讲述这个问题。这个例子是工人用锤子来修理货色。咱们的代码如下:

public class Hammer {public String function(){return "用锤子修理货色";}
}

public class Worker {public void fix(Hammer hammer){System.out.println("工人" + hammer.function());
    }


    public static void main(String[] args) {new Worker().fix(new Hammer());
    }
}

这个是一个很简略的例子,然而如果咱们要新减少一个性能,工人用 螺丝刀来修理货色,在这个类,咱们发现是很难做的。因为咱们 Worker 类依赖于一个具体的实现类 Hammer。所以咱们用到面向接口编程的思维,改成如下的代码:

public interface Tools {public String function();
}

而后咱们的 Worker 是通过这个接口来于其余细节类进行依赖。代码如下:

public class Worker {public void fix(Tools tool){System.out.println("工人" + tool.function());
    }


    public static void main(String[] args) {new Worker().fix(new Hammer());
        new Worker().fix(new Screwdriver());

    }
}

咱们的 Hammer 类与 Screwdriver 类实现这个接口

public class Hammer implements Tools{public String function(){return "用锤子修理货色";}
}

public class Screwdriver implements Tools{
    @Override
    public String function() {return "用螺丝刀修理货色";}
}

这样,通过面向接口编程,咱们的代码就有了很高的扩展性,升高了代码之间的耦合度,进步了零碎的稳定性。

接口隔离准则

接口隔离准则的定义是

客户端不应该依赖他不须要的接口

换一种说法就是类间的依赖关系应该建设在最小的接口上。这样说如同更难懂。咱们通过一个例子来阐明。咱们晓得在 Java 中一个具体类实现了一个接口,那必然就要实现接口中的所有办法。如果咱们有一个类 A 和类 B 通过接口 I 来依赖,类 B 是对类 A 依赖的实现,这个接口 I 有 5 个办法。然而类 A 与类 B 只通过办法 1,2,3 依赖,而后类 C 与类 D 通过接口 I 来依赖,类 D 是对类 C 依赖的实现然而他们却是通过办法 1,4,5 依赖。那么是必在实现接口的时候,类 B 就要有实现他不须要的办法 4 和办法 5 而类 D 就要实现他不须要的办法 2,和办法 3。这几乎就是一个劫难的设计。

所以咱们须要对接口进行拆分,就是把接口分成满足依赖关系的最小接口,类 B 与类 D 不须要去实现与他们无关接口办法。比方在这个例子中,咱们能够把接口拆成 3 个,第一个是仅仅由办法 1 的接口,第二个接口是蕴含 2,3 办法的,第三个接口是蕴含 4,5 办法的。这样,咱们的设计就满足了接口隔离准则。

以上这些设计思维用英文的第一个字母能够组成 SOLID,满足这个 5 个准则的程序也被称为满足了 SOLID 准则。

迪米特准则

迪米特准则也被称为最小常识准则,他的定义

一个对象应该对其余对象放弃最小的理解。

因为类与类之间的关系越亲密,耦合度越大,当一个类产生扭转时,对另一个类的影响也越大,所以这也是咱们提倡的软件编程的总的准则:低耦合,高内聚。迪米特法令还有一个更简略的定义

只与间接的敌人通信。首先来解释一下什么是间接的敌人:每个对象都会与其余对象有耦合关系,只有两个对象之间有耦合关系,咱们就说这两个对象之间是敌人关系。耦合的形式很多,依赖、关联、组合、聚合等。其中,咱们称呈现成员变量、办法参数、办法返回值中的类为间接的敌人,而呈现在局部变量中的类则不是间接的敌人。也就是说,生疏的类最好不要作为局部变量的模式呈现在类的外部。

这里咱们能够用一个现实生活中的例子来解说一下。比方咱们须要一张 CD, 咱们可能去音像店去问老板有没有咱们须要的那张 CD,老板说当初没有,等有的时候你们来拿就行了。在这里咱们不须要关怀老板是从哪里,怎么取得的那张 CD,咱们只和老板(间接敌人)沟通,至于老板从他的敌人那里通过何种条件失去的 CD,咱们不关怀,咱们不和老板的敌人(陌生人)进行通信,这个就是迪米特的一个利用。说白了,就是一种中介的形式。咱们通过老板这个中介来和真正提供 CD 的人产生分割。

总结

到这里,面向对象的六大准则,就写完了。咱们看进去,这些准则其实都是应答一直扭转的需要。每当需要变动的时候,咱们利用这些准则来使咱们的代码改变量最小,而且所造成的影响也是最小的。

然而咱们在看这些准则的时候,咱们会发现很多准则并没有提供一种公式化的论断,而即便提供了公式化的论断的准则也只是倡议去这样做。这是因为,这些设计准则原本就是从很多理论的代码中提取进去的,他是一个教训化的论断。怎么去用它,用好他,就要依附设计者的教训。

否则一味者去应用设计准则可能会使代码呈现适度设计的状况。大多数的准则都是通过提取出形象和接口来实现,如果产生适度的设计,就会呈现很多抽象类和接口,减少了零碎的复杂度。让原本很小的我的项目变得很宏大,当然这也是 Java 的个性(任何的小我的项目都会做成中型的我的项目)。

写在最初

欢送大家关注我的公众号【惊涛骇浪如码】,海量 Java 相干文章,学习材料都会在外面更新,整顿的材料也会放在外面。

感觉写的还不错的就点个赞,加个关注呗!点关注,不迷路,继续更新!!!

正文完
 0