Java设计模式6大原则

Posted 吉尧于

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Java设计模式6大原则相关的知识,希望对你有一定的参考价值。

目录

单一职责原则

开放封闭原则

里式替换原则

依赖倒置原则 

迪米特原则

接口隔离原则

 

设计模式的6大原则,单一职责原则,开放封闭原则,里式替换原则,依赖导致原则,迪米特原则和接口隔离原则。

单一职责原则
  就一个类而言,应该仅有一个引起它变化的原因

通俗的讲就是我们不要让一个承担过多的职责,如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。

这种耦合会导致脆弱的设计,当变化发生时,设计会遭受到破坏。

比如我们会看到一些 android 开发者在写 Activity 中 写Bean 文件,网络数据处理,如果有列表的话,Adapter也写在 Activity中。至于这么做的原因,除了简单粗暴,好找也没什么理由了,那么把其拆分到其他类岂不是更好找?如果Activity过于臃肿,行数过多,显然不是什么好事。

如果我们要修改Bean 文件,网络处理和 Adapter 都需要上这个Activity 来修改,就会导致引起该 Activity 变化的原因太多,我们在版本维护时也比较头痛。这也就严重违背了定义: 就一个类而言,应该仅有一个引起它变化的原因。

单一职责的划分界限不是很清晰,很多时候就要靠个人经验来界定,因此它是一个饱受争议却又极其重要的原则

开放封闭原则
 类,模块,函数等应该是可以扩展的,但是不可以修改

开放封闭有两个含义:一个是对于扩展是开放,另一个是对于修改是封闭的。

对于开发者莱索,需求肯定是变化的,但是有新需求,我们就要把类重新改一遍,这显然是令人头痛的,所以我们设计程序时,面对需求的改变要尽可能得保证相对稳定,尽量通过扩展的方式来实现变化,而不是通过修改原有的代码来实现。

假设我们要实现一个列表,一开始只有查询的功能,后来产品又要新增 添加 功能,过几天又要增加 删除 功能。大多数人的做法是写一个方法,然后通过传入不同的值控制方法实现不同的功能。但是如果又要新增功能,我们还得修改方法。用开发封闭原则解决就是增加一个抽象的功能类,让添加,删除和查询作为这个抽象功能类的子类。这样如果我们再新增功能,你就会发现自己无须修改原有的类,只需要添加一个功能类的子类实现功能类的方法就可以了

示例Demo

//定义了一个抽象动物类,有一个方法
public abstract class AniMal {
abstract void ObjectX();
}


//子类猫实现抽象方法
class Cat extends AniMal {

@Override
void ObjectX() {
System.out.println();
}
}

//子类狗实现抽象方法
class Dog extends AniMal {

@Override
void ObjectX() {
System.out.println();
}
}
 

里式替换原则
所有引用基类(父类)的地方必须能透明的使用其子类的对象

在软件中将一个基类对象替换成其子类对象,程序将不会产生任何错误和异常,反过来则不成立,如果一个软件实体使用的是一个子类对象的话,那么它不一定能够使用子类对象。里式替换原则是实现开放封闭原则的重要方式之一。由于使用基类对象的地方都可以使用子类对象, 因此在程序中尽量使用基类类型来对对象进行定义,而在运行时在确定其子类类型,用子类对象来替换父类对象。在使用里式替换原则是需要注意以下几个问题:

子类的所有方法必须在父类中声明,或子类必须实现父类中声明的所有方法。根据里式替换原则,为了保证系统的扩展性,在程序中通常使用父类来定义。如果一个方法只存于子类中,在父类中不提供相应的声明,则无法在以父类定义的对象中使用该方法。

我们运用里式替换原则时,尽量把父类设计为抽象类或接口,让子类继承父类或实现父接口,并实现在父类中声明的方法、运行时,子类实例替换父类实例,我们可以很方便的扩展系统功能,同时无序修改原有子类的代码;增加新的功能可以通过增加一个新的子类来实现。里式替换原则是开放封闭原则的具体实现手段之一。

在java语言中,在编译阶段,java编译器会检查一个程序是否符合里式替换原则。这是一个与实现无关,纯语法意义上的检查,但Java编译器的检查是有局限性的

Demo

// color 颜色
// flavour 气味
// 苹果类
class Apple{
void Color(){
System.out.println("红色");
}
void Flavour(){
System.out.println("香");
}
}

//Pack -水果包装类
//describe -水果描述
//getMessage -返回具体信息
class Pack{
private Apple apple;

void setApple(Apple apple) {
this.apple = apple;
}

void getMessage(){
apple.Color();
apple.Flavour();
}
}

//buyer 买家-/具体场景
class Buyer{
public static void main(String[] args) {
Pack pack=new Pack();
pack.setApple(new Apple());
pack.getMessage();
}
}
如果我们此时要再加入一个水果类,那么是不是要更改 Pack包装类,再添加一个类对象,然后调用的时候将其传入进来。

如果我有5 6个类呢,那我这个包装类岂不是要很麻烦?

 

现在我们对这个Demo进行修改

abstract class Frits {
abstract void Color();
abstract void Flavour();
}

// color 颜色
// flavour 气味
// 苹果类
class Apple extends Frits {
public void Color() {
System.out.println("红色");
}

public void Flavour() {
System.out.println("甜");
}
}

//Banana 香蕉类
//Stroe 特有储藏方法
class Banana extends Frits {
//特有的方法
public void Store(){
System.out.println("储藏须知");
}

@Override
public void Color() {
System.out.println("黄色");
}

@Override
public void Flavour() {
System.out.println("香甜");
Store();
}
}

//Pack -水果包装类
//describe -水果描述
//getMessage -返回具体信息
class Pack {
private Frits frits;

public void setFrits(Frits frits) {
this.frits = frits;
}

void getMessage() {
frits.Color();
frits.Flavour();
}
}


//buyer 买家-/具体场景
class Buyer {
public static void main(String[] args) {
Pack pack = new Pack();

pack.setFrits(new Apple());
pack.getMessage();
pack.setFrits(new Banana());
pack.getMessage();
}
}
   里式替换原则通俗来说,子类可以扩展父类的功能,但不能改变父类原有的功能:

1.子类可以实现父类的抽象,但是不能覆盖父类的非抽象方法

2.子类中可以增加自己特有的方法。

3.当子类的方法重载父类的方法时,方法的前置条件要比父类方法的输入更宽松。

4.当子类的方法实现父类的抽象方法时,方法的后置条件要比父类更严格。

 

依赖倒置原则
高层模块(调用端)不应该依赖底层模块,两者都应该依赖于抽象。抽象不应该依赖于细节(实现类),细节应该依赖于抽象。

在Java中,抽象指接口或者抽象类,两者都是不能直接被实例化;细节就是实现类,实现接口或者继承抽象类而产生的就是细节,也就是可以加上一个关键字 new 产生的对象。高层模块就是调用端,低层模块就是具体实现类。 依赖倒置原则在 java 中的表现就是,模块间的依赖通过抽象发生,实现类之间不发生直接依赖关系,其依赖关系就是通过接口或者抽象类产生的。如果类与类直接依赖细节,那么就会直接耦合。如此一来,就会同时修改依赖者代码,这样限制了可扩展性。

class Cat {
void Cry() {
System.out.println("喵喵");
}
}

class Dog {
void Cry() {
System.out.println("旺旺");
}
}


class Animal {
void Cry(Cat cat, Dog dog) {
cat.Cry();
dog.Cry();
}
}

class Test{
public static void main(String[] args) {
new Animal().Cry(new Cat(),new Dog());
}
}
上面这个代码看起来没什么问题,可是如果我们还有别的动物子类时,就又要去更改 Animal类,将其对象作为参数传入Cry方法。而依赖倒置原则 模块间的依赖通过抽象发生,实现类之间不发生直接的依赖关系。而我们上面这个Demo已经违背了这个原则,下面我们对它进行修改。

interface Dongwu{
void Cry();
}

class Cat implements Dongwu{
public void Cry() {
System.out.println("喵喵");
}
}

class Dog implements Dongwu{
public void Cry() {
System.out.println("旺旺");
}
}


class Animal {
Dongwu dongwu;

public void setDongwu(Dongwu dongwu) {
this.dongwu = dongwu;
}

void Cry() {
dongwu.Cry();
}
}

class Test{
public static void main(String[] args) {
Animal animal=new Animal();

animal.setDongwu(new Dog());
animal.Cry();
animal.setDongwu(new Cat());
animal.Cry();
}
}
我们增加了一个接口,里面有一个动物的叫声方法,然后让动物类们实现这个接口,然后通过set方法传递依赖对象,这样,如果我们再新增别的动物类,只需要实现相应的接口,而无需再更改我们的管理类 Animal。

 
迪米特原则
一个软件实体应当少的与其他实体发生相互作用。

这也被称最好知识原则。如果一个系统符合迪米特原则,那么当其中某一个模块发生修改时,就会尽量少的影响其他模块。迪米特原则要求我们在设计系统是,应该尽量减少对象之间的交互。如果两个对象之间不必彼此直接通向,那么这两个对象就不应当发生任何直接的相互作用。如果其中的一个对象需要调用另一个对象的某一个方法,则可以通过第三者转发这个调用。简言之,就是通过引入一个合理的第三者来降低现有对象之间的耦合度。在将迪米特原则运用到系统设计中时,要注意以下几点:

在类的划分上,应当尽量创建松耦合的类。类之间的耦合越低,就越有利于复用。一个处在松耦合中的类一旦被修改,则不会对关联的类造成太大波及。

在类的结构上,每一个类都应当尽量降低其成员变量和成员函数的访问权限。

在对其他类的引用上,一个对象对其他对象的引用应当降到最低。

 举个例子

就像租房子一样,我叫老王,准备租房子,然后找中介,中介和房东谈价格,我们和中介谈价格,如果我们想自己和房东联系,这种事情肯定是要通过中介介绍了,或者别的途径。

Demo如下

//租房者:老王类
//inform 通知方法
class LaoWang {
private Zhongjie zhongjie;

public Zhongjie getZhongjie(){
return zhongjie;
}

public void setZhongjie(Zhongjie zhongjie) {
this.zhongjie = zhongjie;
}
public void inform(){
zhongjie.inform();
}
}

//中介类
//inform 通知方法
//setLandlord 接收房东消息
class Zhongjie{
public void inform(){
System.out.println("通知房东");
}
public void getLanged(){
new Landlord().inform();
}
}

//房东类
//inform 通知方法
class Landlord{
public void inform(){
System.out.println("收到,可以租");
}
}

class Renting{
public static void main(String[] args) {
LaoWang laoWang=new LaoWang();
//老王通知中介
laoWang.inform();
//传入房东对象
laoWang.setZhongjie(new Zhongjie());
//由中介去通知房东
laoWang.getZhongjie().inform();
//接收房东消息
laoWang.getZhongjie().getLanged();
}

这样,老王和房东之间就没有任何联系,避免了耦合度过高。

我们还可以将上面的Demo再次更改,相当和依赖倒转原则结合。因为一般租房会看好多房子,所以房东也各不相同,这时候就可以将房东抽成一个抽象类,具体的房东实现房东抽象方法即可,这样的方式,和老王通信的就是房东的抽象父类,和具体房东没有关系。

public abstract class Lease {
abstract void inform();
}

//租房者:老王类
//inform 通知方法
class LaoWang {
private Zhongjie zhongjie;
private Lease lease;

public void setLease(Lease lease) {
this.lease = lease;
}

public void setZhongjie(Zhongjie zhongjie) {
this.zhongjie = zhongjie;
}

public void inform() {
zhongjie.inform();
lease.inform();
}
}

//中介类
//inform 通知方法
class Zhongjie {
public void inform() {
System.out.println("通知房东");
}
}

//Landlord_X 房东X
//inform 通知方法
class Landlord_X extends Lease {
public void inform() {
System.out.println("收到,可以租");
}
}

class Renting{
public static void main(String[] args) {
LaoWang laoWang=new LaoWang();
laoWang.setLease(new Landlord_X());
laoWang.setZhongjie(new Zhongjie());
laoWang.inform();
}
}
 

 

接口隔离原则
一个类对另一个类的依赖应该建立在最小的接口上

建立单一接口,不要建立庞大臃肿的接口:尽量细化接口,接口中的方法尽量少。也就是说,我们要为各个类建立专用的接口,而不要试图建立一个一个很庞大的接口供所有依赖他的类调用。采取接口隔离原则对接口进行约束时,要注意以下几点:

接口尽量小,但是要有限度。对接口进行细化可以提高程序设计的灵活性;但是如果过小,则会造成接口数量过多,使设计复杂化。所以,一定要适度。

为依赖接口的类定制服务,只暴露给调用的类他需要的方法,他不需要的方法则隐藏起来,只有专注的为一个模块提供定制服务,才能建立最小的依赖关系。

为提高内聚,减少对外交互。接口方法尽量少用public 修饰。接口是对外的承诺,承诺越少对系统的开发越有利,变更的风险也越少。

 Demo

//color 颜色
//taste 口感
//hardness 硬度
// small气味
interface Frits {
void color();
void taste();
void hardness();
void small();
}
class apple implements Frits{

@Override
public void color() {

}

@Override
public void taste() {

}

@Override
public void hardness() {

}

@Override
public void small() {

}
}
定义了一个水果接口,里面有水果的各项方法,如果我们还有别的方法,那么这个接口必然会受到多次修改。所以我们可以对其进行分隔,比如外观为一类,内在为一类,结果如下 

//Facade 外观
interface Facade {
void color();
void hardness();
}
//Inherent 内在
interface Inherent {
void taste();
void small();
}
class banana implements Facade,Inherent{
@Override
public void taste() {

}

@Override
public void small() {

}

@Override
public void color() {

}

@Override
public void hardness() {

}
}
接口是我们设计时对外提供的契约,通过分散定义多个 接口,可以预防未来变更的扩散,提高系统的灵活性和可维护性。

以上是关于Java设计模式6大原则的主要内容,如果未能解决你的问题,请参考以下文章

10张图说清设计模式6大原则

设计模式6大原则

设计模式 - 6大原则

设计模式6大原则

设计模式6大原则

6大原则java