• 技术文章 >Java >Java基础

    设计模式的六大原则是什么

    青灯夜游青灯夜游2023-01-06 16:25:16原创142

    设计模式的六大原则:1、单一职责原则,其核心就是控制类的粒度大小、将对象解耦、提高其内聚性;2、开闭原则,可以通过“抽象约束、封装变化”来实现;3、里氏替换原则,主要阐述了有关继承的一些原则;4、依赖倒置原则,降低了客户与实现模块之间的耦合;5、接口隔离原则,是为了约束接口、降低类对接口的依赖性;6、迪米特法则,要求限制软件实体之间通信的宽度和深度。

    本教程操作环境:windows7系统、java8版、DELL G3电脑。

    对于设计模式,自己很早之前就看了好多本设计模式书籍,其中一些还看了好几遍,也一直希望自己能在编码的时候把这些设计模式用上去。可是,在日常的打码中,用的做多的就是单例,其次是观察者和建造者模式 ( builder ) 用得比较多,其他的基本很少用到。

    用不到的原因是还是不能够理解设计模式的思想,无法将这些设计模式和编码遇到的问题联系起来,从而用不到设计模式。

    其实设计模式的提出都是为了解决一个常见的问题而总结出来的办法。所以当你思考采用何种设计模式的时候,你应该先问问自己当前问题的是什么?根据问题去选取合适的设计模式。

    等你熟悉了设计模式的以后,你会发现部分设计模式之间存在包含关系,甚至很相像,但是不同的设计模式解决的问题是不一样的。

    当我们在设计一个模块的时候可以从以下几个角度去考虑:

    当然,本文并不是教你是如何使用设计模式。而是讲解设计模式的设计原则。设计模式在被设计出来的时候,也是遵循一些规则的。

    设计模式六大原则,具体如下:

    每一个设计原则旁边都有个括号,是用来解释,或者描述应用范围的。下面将详细介绍每一个原则。

    单一职责原则的定义(类、方法、接口)


    单一职责原则(Single Responsibility Principle,SRP)又称单一功能原则。这里的职责是指类变化的原因,单一职责原则规定一个类应该有且仅有一个引起它变化的原因,否则类应该被拆分(There should never be more than one reason for a class to change)。

    该原则提出对象不应该承担太多职责,如果一个对象承担了太多的职责,至少存在以下两个缺点:

    单一职责原则的优点

    单一职责原则的核心就是控制类的粒度大小、将对象解耦、提高其内聚性。如果遵循单一职责原则将有以下优点。

    单一职责原则的实现方法

    单一职责原则是最简单但又最难运用的原则,需要设计人员发现类的不同职责并将其分离,再封装到不同的类或模块中。而发现类的多重职责需要设计人员具有较强的分析设计能力和相关重构经验。

    示例

    public interface UserService {
        
        public void login(String username, String password);
        public void register(String email, String username, String password);
        public void logError(String msg);
        public void sendEmail(String email);
        
    }

    这段代码很显然存在很大的问题,UserService 既要负责用户的注册和登录,还要负责日志的记录和邮件的发送,并且后者的行为明显区别于前者。

    假设我要修改发送邮件的逻辑就得修改这个类,这时候 qa 还得回归登录注册逻辑,这样明显不合理。

    因此我们需要进行拆分,根据具体的职能可将其具体拆分如下:

    UserService:只负责登录注册

    public interface UserService {
    
        public void login(String username, String password);
        public void register(String email, String username, String password);
    
    }

    LogService :只负责日志

    public interface LogService {
        public void logError(String msg);
    
    }

    EmailService: 只负责发送邮件

    public interface EmailService {
        public void sendEmail(String email);
    
    }

    这时候,咱们再去回顾前面提到的优点,就能深深体会了。

    这里只是讲了接口,其实对类也一样,甚至方法也是一样的。

    对于类来说,根据类名,确保里面提供的方法都是属于这个类的。

    对于方法,不要把不相关的对象实例作为参数传进来。如果你发现某个方法依赖某个不相关的对象,那么这个方法的实现可能就存在问题。

    比如 android 中图片下载后显示到 imageView 中,我提供如下的方法:

    loadImage(String url, ImageView view) {
    // 下载图片,展示图片
    }

    对于 loadImage 这个方法,参数 url 是ok 的,但是参数 ImageView 却是不合理的。因为这里做了两个操作,下载图片,展示图片。应该将这个方法在进行拆分:

    // 下载图片 
    loadImage(String url) {
    
    }
    // 显示图片
    displayImage(String url, ImageView view) {
    
    // 调用 getBitmap (url)  获取图片
    // 获取图片后将其设置到 view 中。
    
    }
    
    // 根据 url 获取图片, 
    getBitmap(String url) {
    
    }

    这样整个逻辑就很清晰。后续需要修改下载逻辑,也不会影响到展示逻辑。当然其实还有个问题是,这两个方法要不要放在一个类里面?

    开闭原则


    开闭原则的实现方法:可以通过“抽象约束、封装变化”来实现开闭原则,即通过接口或者抽象类为软件实体定义一个相对稳定的抽象层,而将相同的可变因素封装在相同的具体实现类中。

    因为抽象灵活性好,适应性广,只要抽象的合理,可以基本保持软件架构的稳定。而软件中易变的细节可以从抽象派生来的实现类来进行扩展,当软件需要发生变化时,只需要根据需求重新派生一个实现类来扩展就可以了。

    示例

    // 矩形
    public class Rectangle {
    
        public double getWidth() {
            return width;
        }
        
        public double getHeight() {
            return height;
        }
    
    }

    需要计算矩形的面积

    // 面积计算器
    public class AreaCalculator {
    
        public double area(Rectangle shape){
            return shape.getWidth() * shape.getHeight();
        }
    }

    假设这时候,又多了一个圆形类

    // 圆形
    public class Circular {
    
        public double getRadius(){
            return radius;
        }
    }

    同样也需要计算他的面积,这时候就会变成下面这样子:

    public class AreaCalculator {
    
        public double area(Object shape){
            if(shape instanceof Rectangle) {
                Rectangle rectangle = (Rectangle) shape;
                return rectangle.getWidth() * rectangle.getHeight();
            } else if (shape instanceof Circular) {
                Circular circular = (Circular) shape;
                return circular.getRadius() * circular.getRadius() * Math.PI;
            } else {
                throw new RuntimeException("There is no such type.");
            }
        }
    }

    这么更改完成,完全没有问题。但是在真实的生产环境中,情况更为复杂,更改涉及的部分较多,那样就可能导致牵一发动全身。并且,以前编写的经过测试的一些功能需要重新测试,甚至导致某些功能不可用。

    改进版,把计算面积这个公有逻辑变成一个接口:

    public interface Shape {
    
        public double getArea();
    
    }
     
    public class Rectangle implements Shape{
    
        public double getWidth() {
            return width;
        }
    
        public double getHeight() {
            return height;
        }
    
        public double getArea() {
            return getWidth() * getHeight();
        }
        
    }

    这样,当需求变更,需要计算圆形面积的时候,我们只需创建一个圆形的类,并实现 Shape 接口即可:

    public class Circular implements Shape {
    
        public double getRadius(){
            return radius;
        }
    
        public double getArea() {
            return getRadius() * getRadius() * Math.PI;
        }
    }

    计算三角形面积、四边形面积... 的时候,我们只需让它们去实现 Shape 接口即可,无需修改源代码。

    里氏替换原则


    里氏替换原则主要阐述了有关继承的一些原则,也就是什么时候应该使用继承,什么时候不应该使用继承,以及其中蕴含的原理。里氏替换原是继承复用的基础,它反映了基类与子类之间的关系,是对开闭原则的补充,是对实现抽象化的具体步骤的规范。

    里氏替换原则的作用

    里氏替换原则的主要作用如下。

    里氏替换原则的实现方法(继承)

    里氏替换原则通俗来讲就是:子类可以扩展父类的功能,但不能改变父类原有的功能。也就是说:子类继承父类时,除添加新的方法完成新增功能外,尽量不要重写父类的方法。

    根据上述理解,对里氏替换原则的定义可以总结如下:

    通过重写父类的方法来完成新的功能写起来虽然简单,但是整个继承体系的可复用性会比较差,特别是运用多态比较频繁时,程序运行出错的概率会非常大。

    如果程序违背了里氏替换原则,则继承类的对象在基类出现的地方会出现运行错误。

    这时其修正方法是:取消原来的继承关系,重新设计它们之间的关系。

    关于里氏替换原则的例子,最有名的是“正方形不是长方形”。当然,生活中也有很多类似的例子,例如,企鹅、鸵鸟和几维鸟从生物学的角度来划分,它们属于鸟类;但从类的继承关系来看,由于它们不能继承“鸟”会飞的功能,所以它们不能定义成“鸟”的子类。同样,由于“气球鱼”不会游泳,所以不能定义成“鱼”的子类;“玩具炮”炸不了敌人,所以不能定义成“炮”的子类等。

    对于正方形和长方形最好的做法是再添加一个父类,他们同时继承自这个父类。

    依赖倒置(抽线细节)


    依赖倒置原则是实现开闭原则的重要途径之一,它降低了客户与实现模块之间的耦合。

    由于在软件设计中,细节具有多变性,而抽象层则相对稳定,因此以抽象为基础搭建起来的架构要比以细节为基础搭建起来的架构要稳定得多。这里的抽象指的是接口或者抽象类,而细节是指具体的实现类。

    使用接口或者抽象类的目的是制定好规范和契约,而不去涉及任何具体的操作,把展现细节的任务交给它们的实现类去完成。

    依赖、倒置原则的作用

    依赖倒置原则的主要作用如下。

    依赖倒置原则的实现方法

    依赖倒置原则的目的是通过要面向接口的编程来降低类间的耦合性,所以我们在实际编程中只要遵循以下4点,就能在项目中满足这个规则。

    依赖倒置原则在“顾客购物程序”中的应用。

    分析:本程序反映了 “顾客类”与“商店类”的关系。商店类中有 sell() 方法,顾客类通过该方法购物以下代码定义了顾客类通过韶关网店 ShaoguanShop 购物

    class Customer {
        public void shopping(ShaoguanShop shop) {
            //购物
            System.out.println(shop.sell());
        }
    }

    但是,这种设计存在缺点,如果该顾客想从另外一家商店(如婺源网店 WuyuanShop)购物,就要将该顾客的代码修改如下:

    class Customer {
        public void shopping(WuyuanShop shop) {
            //购物
            System.out.println(shop.sell());
        }
    }

    顾客每更换一家商店,都要修改一次代码,这明显违背了开闭原则。

    存在以上缺点的原因是:顾客类设计时同具体的商店类绑定了,这违背了依赖倒置原则。

    解决方法是:定义“婺源网店”和“韶关网店”的共同接口 Shop,顾客类面向该接口编程,其代码修改如下:

    class Customer {
        public void shopping(Shop shop) {
            //购物
            System.out.println(shop.sell());
        }
    }
    
    class Customer {
        public void shopping(Shop shop) {
            //购物
            System.out.println(shop.sell());
        }
    }

    这样,不管顾客类 Customer 访问什么商店,或者增加新的商店,都不需要修改原有代码了,其类如下图所示:


    顾客购物程序的类图
    程序代码如下:

    package principle;
    public class DIPtest
    {
        public static void main(String[] args)
        {
            Customer wang=new Customer();
            System.out.println("顾客购买以下商品:"); 
            wang.shopping(new ShaoguanShop()); 
            wang.shopping(new WuyuanShop());
        }
    }
    //商店
    interface Shop
    {
        public String sell(); //卖
    }
    //韶关网店
    class ShaoguanShop implements Shop
    {
        public String sell()
        {
            return "韶关土特产:香菇、木耳……"; 
        } 
    }
    //婺源网店
    class WuyuanShop implements Shop
    {
        public String sell()
        {
            return "婺源土特产:绿茶、酒糟鱼……"; 
        }
    } 
    //顾客
    class Customer
    {
        public void shopping(Shop shop)
        {
            //购物
            System.out.println(shop.sell()); 
        }
    }

    程序的运行结果如下:

    顾客购买以下商品:
    韶关土特产:香菇、木耳……
    婺源土特产:绿茶、酒糟鱼……

    接口隔离原则(接口)


    接口隔离原则(Interface Segregation Principle,ISP)要求程序员尽量将臃肿庞大的接口拆分成更小的和更具体的接口,让接口中只包含客户感兴趣的方法。

    2002 年罗伯特·C.马丁给“接口隔离原则”的定义是:客户端不应该被迫依赖于它不使用的方法(Clients should not be forced to depend on methods they do not use)。该原则还有另外一个定义:一个类对另一个类的依赖应该建立在最小的接口上(The dependency of one class to another one should depend on the smallest possible interface)。

    以上两个定义的含义是:要为各个类建立它们需要的专用接口,而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。

    接口隔离原则和单一职责都是为了提高类的内聚性、降低它们之间的耦合性,体现了封装的思想,但两者是不同的:

    接口隔离原则的优点

    接口隔离原则是为了约束接口、降低类对接口的依赖性,遵循接口隔离原则有以下 5 个优点。

    接口隔离原则的实现方法

    在具体应用接口隔离原则时,应该根据以下几个规则来衡量。

    对于接口隔离,大家还是可以参考单一职责提到的示例:

    public interface UserService {
        
        public void login(String username, String password);
        public void register(String email, String username, String password);
        public void logError(String msg);
        public void sendEmail(String email);
        
    }

    这时候,应该就能理解拆分的好处了。

    迪米特法则 (类与类之间的关系)


    迪米特法则(Law of Demeter,LoD)又叫作最少知识原则(Least Knowledge Principle,LKP),产生于 1987 年美国东北大学(Northeastern University)的一个名为迪米特(Demeter)的研究项目,由伊恩·荷兰(Ian Holland)提出,被 UML 创始者之一的布奇(Booch)普及,后来又因为在经典著作《程序员修炼之道》(The Pragmatic Programmer)提及而广为人知。

    迪米特法则的定义是:只与你的直接朋友交谈,不跟“陌生人”说话(Talk only to your immediate friends and not to strangers)。其含义是:如果两个软件实体无须直接通信,那么就不应当发生直接的相互调用,可以通过第三方转发该调用。其目的是降低类之间的耦合度,提高模块的相对独立性。

    迪米特法则中的“朋友”是指:当前对象本身、当前对象的成员对象、当前对象所创建的对象、当前对象的方法参数等,这些对象同当前对象存在关联、聚合或组合关系,可以直接访问这些对象的方法。

    迪米特法则的优点

    迪米特法则要求限制软件实体之间通信的宽度和深度,正确使用迪米特法则将有以下两个优点。

    但是,过度使用迪米特法则会使系统产生大量的中介类,从而增加系统的复杂性,使模块之间的通信效率降低。所以,在釆用迪米特法则时需要反复权衡,确保高内聚和低耦合的同时,保证系统的结构清晰。

    迪米特法则的实现方法

    从迪米特法则的定义和特点可知,它强调以下两点:

    所以,在运用迪米特法则时要注意以下 6 点。

    明星与经纪人的关系实例。

    分析:明星由于全身心投入艺术,所以许多日常事务由经纪人负责处理,如与粉丝的见面会,与媒体公司的业务洽淡等。这里的经纪人是明星的朋友,而粉丝和媒体公司是陌生人,所以适合使用迪米特法则,其类图如下图所示。


    明星与经纪人的关系图
    代码如下:

    package principle;
    public class LoDtest
    {
        public static void main(String[] args)
        {
            Agent agent=new Agent();
            agent.setStar(new Star("林心如"));
            agent.setFans(new Fans("粉丝韩丞"));
            agent.setCompany(new Company("中国传媒有限公司"));
            agent.meeting();
            agent.business();
        }
    }
    //经纪人
    class Agent
    {
        private Star myStar;
        private Fans myFans;
        private Company myCompany;
        public void setStar(Star myStar)
        {
            this.myStar=myStar;
        }
        public void setFans(Fans myFans)
        {
            this.myFans=myFans;
        }
        public void setCompany(Company myCompany)
        {
            this.myCompany=myCompany;
        }
        public void meeting()
        {
            System.out.println(myFans.getName()+"与明星"+myStar.getName()+"见面了。");
        }
        public void business()
        {
            System.out.println(myCompany.getName()+"与明星"+myStar.getName()+"洽淡业务。");
        }
    }
    //明星
    class Star
    {
        private String name;
        Star(String name)
        {
            this.name=name;
        }
        public String getName()
        {
            return name;
        }
    }
    //粉丝
    class Fans
    {
        private String name;
        Fans(String name)
        {
            this.name=name;
        }
        public String getName()
        {
            return name;
        }
    }
    //媒体公司
    class Company
    {
        private String name;
        Company(String name)
        {
            this.name=name;
        }
        public String getName()
        {
            return name;
        }
    }

    程序的运行结果如下:

    粉丝韩丞与明星林心如见面了。
    中国传媒有限公司与明星林心如洽淡业务。

    到此,设计模式的六大原则就讲完了。

    更多编程相关知识,请访问:编程教学!!

    以上就是设计模式的六大原则是什么的详细内容,更多请关注php中文网其它相关文章!

    声明:本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系admin@php.cn核实处理。
    专题推荐:设计模式
    上一篇:sdk是什么 下一篇:自己动手写 PHP MVC 框架(40节精讲/巨细/新人进阶必看)

    相关文章推荐

    • javascript中什么是设计模式• javascript中的设计模式有哪些• JavaScript经典讲解之设计模式(实例详解)• Java设计模式解析之适配器模式(实例详解)• 一起来聊聊与Java中性能相关的设计模式• 详解PHP八大设计模式
    1/1

    PHP中文网