精华内容
下载资源
问答
  • 六大设计原则

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

    六大设计原则

    1.单一职责原则(Single Responsibility Principle)

    定义:应该有且仅有一个原因引起类的变更
    单一职责原则的好处

    • 类的复杂性降低,实现什么职责都有清晰明确的定义
    • 可读性提高,复杂性降低
    • 可维护性提高,可读性提高
    • 变更引起的风险降低

    2.里氏替换原则(Liskov Substitution Principle)

    定义:
    1)如果对每一个类型为S的对象o1,都有类型为T的对象o2,使得以T定义的所有程序P在所有的对象o1都代换成o2时,程序P的行为没有发生变化,那么类型S是类型T的子类型。
    2)只要父类能出现的地方子类就可以出现,而且替换为子类也不会产生任何错误或异常,使用者可能根本就不需要知道是父类还是子类。反过来,有子类出现的地方,父类未必就能适合。

    里氏替换原则为良好的继承定义了一个规范:

    • 1.子类必须完全实现父类的方法(在类中调用其他类时务必要使用父类或接口,如不能,则违背LSP原则)
    • 2.子类可以有自己的个性
    • 3.覆盖或实现父类的方法时输入参数可以被放大(子类中方法的前置条件必须与超类中被覆写的方法的前置条件相同或者更宽松)
    • 4.重写或实现父类的方法时输出结果可以被缩小

    3.依赖倒置原则

    在Java语言中,抽象就是指接口或抽象类,两者都是不能直接被实例化的;细节就是实现类,实现接口或继承抽象类而产生的类就是细节,其特点就是可以直接被实例化,也就是可以加上一个关键字new产生一个对象。在Java中的表现是:

    • 模块间的依赖通过抽象发生,实现类之间不发生直接的依赖关系,其依赖关系是通过接口或抽象类产生的;
    • 接口或抽象类不依赖于实现类;
    • 实现类依赖接口或抽象类。

    在Java中,只要定义变量就必然要有类型,一个变量可以有两种类型:表面类型和实际类型,表面类型是在定义的时候赋予的类型,实际类型是对象的类型。

    4.接口隔离原则

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

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

    一个类应该对自己需要耦合或调用的类知道得最少。
    类与类之间的关系是建立在类间的,而不是方法间,因此一个方法尽量不要引入一个类中不存在的对象。

    6.开闭原则

    开闭原则对扩展开放,对修改关闭,并不意味着不做任何的修改,低层模块的变更,必然要有高层模块进行耦合,否则就是一个孤立无意义的代码片段。

    展开全文
  • java六大设计原则 个人见解层次分明
  • 六大设计原则总结

    2016-06-23 09:43:29
    六大设计原则是我们在项目实施的过程中要求项目管理者和开发者都必须要参考的原则。
  • 浅谈C#六大设计原则

    2020-08-19 02:33:28
    主要介绍了C#六大设计原则的相关内容,文中代码非常细致,供大家参考和学习,感兴趣的朋友可以了解下
  • 六大设计原则之开闭原则

    万次阅读 多人点赞 2016-08-28 10:32:38
    开闭原则的定义开闭原则是java世界里最基础的设计原则,它指导我们如何建立一个稳定,灵活的系统。开闭原则定义如下:Software entities like classes,modules and functions should be open for extension but ...

    这里写图片描述

    开闭原则的定义

    开闭原则是java世界里最基础的设计原则,它指导我们如何建立一个稳定,灵活的系统。开闭原则定义如下:

    Software entities like classes,modules and functions should be open for extension but closed for modifications.

    一个软件实体如类,模块和函数应该对扩展开放,对修改关闭。

    什么是开闭原则

    开闭原则明确的告诉我们:软件实现应该对扩展开放,对修改关闭,其含义是说一个软件实体应该通过扩展来实现变化,而不是通过修改已有的代码来实现变化的。那什么是软件实体呢?软件实体包括以下几个部分:

    • 项目或软件产品中按照一定的逻辑规则划分的模块
    • 抽象和类
    • 方法
      一个软件产品只要在生命周期内,都会发生变化,即然变化是一个事实,我们就应该在设计时尽量适应这些变化,以提高项目的稳定性和灵活性,真正实现“拥抱变化”。开闭原则告诉我们应尽量通过扩展软件实体的行为来实现变化,而不是通过修改现有代码来完成变化,它是为软件实体的未来事件而制定的对现行开发设计进行约束的一个原则。

    我们举例说明什么是开闭原则,以书店销售书籍为例,其类图如下:

    这里写图片描述

    书籍接口:

    public interface IBook{
      public String getName();
      public String getPrice();
      public String getAuthor();
    }
    

    小说类书籍:

    public class NovelBook implements IBook{
       private String name;
       private int price;
       private String author;
    
       public NovelBook(String name,int price,String author){
         this.name = name;
         this.price = price;
         this.author = author;
       }
    
       public String getAutor(){
         return this.author;
       }
    
       public String getName(){
         return this.name;
       }  
    
       public int getPrice(){
         return this.price;
       } 
    }
    

    Client类:

    public class Client{
       public static void main(Strings[] args){
         IBook novel = new NovelBook("笑傲江湖",100,"金庸");
         System.out.println("书籍名字:"+novel.getName()+"书籍作者:"+novel.getAuthor()+"书籍价格:"+novel.getPrice());
       }
    
    }
    

    项目投产生,书籍正常销售,但是我们经常因为各种原因,要打折来销售书籍,这是一个变化,我们要如何应对这样一个需求变化呢?

    我们有下面三种方法可以解决此问题:

    • 修改接口
      在IBook接口中,增加一个方法getOffPrice(),专门用于进行打折处理,所有的实现类实现此方法。但是这样的一个修改方式,实现类NovelBook要修改,同时IBook接口应该是稳定且可靠,不应该经常发生改变,否则接口作为契约的作用就失去了。因此,此方案否定。

    • 修改实现类
      修改NovelBook类的方法,直接在getPrice()方法中实现打折处理。此方法是有问题的,例如我们如果getPrice()方法中只需要读取书籍的打折前的价格呢?这不是有问题吗?当然我们也可以再增加getOffPrice()方法,这也是可以实现其需求,但是这就有二个读取价格的方法,因此,该方案也不是一个最优方案。

    • 通过扩展实现变化
      我们可以增加一个子类OffNovelBook,覆写getPrice方法。此方法修改少,对现有的代码没有影响,风险少,是个好办法。

    下面是修改后的类图:

    这里写图片描述

    打折类:

    public class OffNovelBook implements NovelBook{
    
       public OffNovelBook(String name,int price,String author){
          super(name,price,author);
       }
    
       //覆写价格方法,当价格大于40,就打8析,其他价格就打9析
       public int getPrice(){
         if(this.price > 40){
            return this.price * 0.8;
         }else{
            return this.price * 0.9;
         }     
       } 
    }
    

    现在打折销售开发完成了,我们只是增加了一个OffNovelBook类,我们修改的代码都是高层次的模块,没有修改底层模块,代码改变量少,可以有效的防止风险的扩散。

    我们可以把变化归纳为二种类型:

    • 逻辑变化
      只变化了一个逻辑,而不涉及其他模块,比如一个算法是abc,现在需要修改为a+b+c,可以直接通过修改原有类中的方法的方式来完成,前提条件是所有依赖或关联类都按照相同的逻辑处理

    • 子模块变化
      一人模块变化,会对其它的模块产生影响,特别是一个低层次的模块变化必然引起高层模块的变化,因此在通过扩展完成变化。

    为什么使用开闭原则

    第一:开闭原则非常有名,只要是面向对象编程,在开发时都会强调开闭原则

    第二:开闭原则是最基础的设计原则,其它的五个设计原则都是开闭原则的具体形态,也就是说其它的五个设计原则是指导设计的工具和方法,而开闭原则才是其精神领袖。依照java语言的称谓,开闭原则是抽象类,而其它的五个原则是具体的实现类。

    第三:开闭原则可以提高复用性
    在面向对象的设计中,所有的逻辑都是从原子逻辑组合而来,不是在一个类中独立实现一个业务逻辑。只有这样的代码才可以复用,粒度越小,被复用的可能性越大。那为什么要复用呢?减少代码的重复,避免相同的逻辑分散在多个角落,减少维护人员的工作量。那怎么才能提高复用率呢?缩小逻辑粒度,直到一个逻辑不可以分为止。

    第四:开闭原则可以提高维护性
    一款软件量产后,维护人员的工作不仅仅对数据进行维护,还可能要对程序进行扩展,维护人员最乐意的事是扩展一个类,而不是修改一个类。让维护人员读懂原有代码,再进行修改,是一件非常痛苦的事情,不要让他在原有的代码海洋中游荡后再修改,那是对维护人员的折磨和摧残。

    第五:面向对象开发的要求
    万物皆对象,我们要把所有的事物抽象成对象,然后针对对象进行操作,但是万物皆发展变化,有变化就要有策略去应对,怎么快速应对呢?这就需要在设计之初考虑到所有可能变化的因素,然后留下接口,等待“可能”转变为“现实”。

    如何使用开闭原则

    第一:抽象约束
    抽象是对一组事物的通用描述,没有具体的实现,也就表示它可以有非常多的可能性,可以跟随需求的变化而变化。因此,通过接口或抽象类可以约束一组可能变化的行为,并且能够实现对扩展开放,其包含三层含义:

    • 通过接口或抽象类约束扩散,对扩展进行边界限定,不允许出现在接口或抽象类中不存在的public方法。
    • 参数类型,引用对象尽量使用接口或抽象类,而不是实现类,这主要是实现里氏替换原则的一个要求
    • 抽象层尽量保持稳定,一旦确定就不要修改

    第二:元数据(metadata)控件模块行为
    编程是一个很苦很累的活,那怎么才能减轻压力呢?答案是尽量使用元数据来控制程序的行为,减少重复开发。什么是元数据?用来描述环境和数据的数据,通俗的说就是配置参数,参数可以从文件中获得,也可以从数据库中获得。

    第三:制定项目章程
    在一个团队中,建立项目章程是非常重要的,因为章程是所有人员都必须遵守的约定,对项目来说,约定优于配置。这比通过接口或抽象类进行约束效率更高,而扩展性一点也没有减少。

    第四:封装变化
    对变化封装包含两层含义:
    (1)将相同的变化封装到一个接口或抽象类中
    (2)将不同的变化封装到不同的接口或抽象类中,不应该有两个不同的变化出现在同一个接口或抽象类中。
    封装变化,也就是受保护的变化,找出预计有变化或不稳定的点,我们为这些变化点创建稳定的接口。

    参考:

    设计模式之禅 秦小波著 机械工业出版社

    展开全文
  • 今天上传了一个自己做的设计原则的小例子(不是项目设计),里面包含六大设计原则的定义,与一些小示例,结构比较清晰,对于想我这种小白应该都能看得明白。由于官方调整积分过高,现在已经下调,不好意思了大家!
  • 安卓六大设计原则

    千次阅读 2017-03-07 09:27:09
    安卓六大设计原则包括: (1) 单一职责原则;  (2)氏替换原则; (3)依赖倒置原则;  (4)接口隔离原则; (5)迪米特原则;  (6)开闭原则。
    安卓六大设计原则包括:
    
    (1) 单一职责原则; 
    (2)里氏替换原则;
    (3)依赖倒置原则; 
    (4)接口隔离原则;
    (5)迪米特原则; 
    (6)开闭原则。

      一.单一替换原则

          定义:它规定一个类应该只有一个发生变化的原因

           特点:

    (1)降低类的复杂度,对类或接口的职责有明确的定义;

    (2)提高可读性;

    (3)降低变更引起的风险,接口改变只影响相应的实现类,不影响其他类。

    重点:

    (1)接口一定要做到单一原则;

    (2)类的单一原则比较难以实现,尽量做到只有一个原因引起变化;

    (3)一个方法尽可能做一件事情,能分解就分解,分解到原子级别。

    适用范围:接口,方法,类。

    栗子:封装log工具类,可以全局打印,自动获取类名作为TAG,在log信息后面附加方法名,线程,机型,网络信息。

    二.里氏替换原则

    定义:所有引用基类的地方必须能透明的使用其子类的对象;(只要出现父类的地方都可以替换成子类,替换后不会产生任何错误,使用只需要知道是父类还是子类)

    优缺点:核心是继承,所以她的优缺点也就是继承的优缺点。

    继承优点:

    (1)代码共享:共享代码,子类都拥有父类的方法和属性,将父类的代码共享给了子类;

    (2)重用性:提高代码的重用性,子类重用了父类的代码;

    (3)子父类异同:子类形似父类,异于父类,父子都不同;

    (4)扩展性:提高代码的可扩展性,子类就可以为所欲为了,子类可以随意扩展父类;

    (5)开放性:提高产品或项目的开放性,父类随意扩展,开放性随之增加了;

    继承缺点:

    (1)灵活性:降低代码的灵活性,子类必须拥有父类的属性和方法,子类受到了父类的约束。这时从子类的角度讲的;

    (2)耦合性:增强了耦合性,父类的属性和方法被修改时,还需要顾及其子类,可能会带来大量的重构,这时从父类的角度讲的。

    里氏替换优点:继承优点


    里氏替换缺点:

    (1)将子类都当作了父类使用,抹杀了子类的个性

    2)将子类单独作为一个业务来使用,会让代码间的关系都复杂化,缺乏类替换标准。

    重点:

    (1)返回值:父类方法返回值类型F,子类方法返回值类型S,里氏替换原则是S范围必须小于F。(向下转型)

    (2)重载:父类和子类的方法参数类型或者数量不用,如果要符合里氏替换原则的话,子类参数必须大于等于父类参数,即不能让子类自己定义的方法被调用

    三.依赖倒置原则

    定义:高层模块不应该依赖低层模块,二者都应该依赖其抽象;抽象不应该依赖细节;细节不应该依赖抽象

    重点:抽象就是接口和抽象类,细节就是具体的实现类

    优点:

    (1)减少类之间的耦合

    (2)提高系统稳定性

    (3)降低并发风险

    (4)提高代码可读性

    依赖倒置注入实现:

    (1)构造函数注入依赖对象:通过构造函数参数声明依赖对象;

    (2)Setter()方法注入依赖对象:通过setter()函数参数声明依赖对象;

    (3)接口注入依赖对象:通过接口的方法中的参数声明依赖对象

    依赖本末本质:通过抽象(接口或者抽象类),使各个类和模块实现彼此独立,实现模块间松耦合

    注意点:尽量不要覆盖方法,如果该方法已在抽象类中实现,子类不要覆盖。

    四.接口隔离原则

    定义:

    (1)建立单一接口,功能尽量细化,不要建立臃肿的接口;

    (2)不需要的接口:客户端尽量不依赖其不需要的接口,客户端需要什么接口就提供什么接口,剔除不需要的接口,对接口进行细化,保持方法最少;

    (3)最小接口:类同的依赖关系应该建立在最小接口伤,尽量细化接口。

    单一职责和接口隔离的区别:

    单一职责:注重职责,注重业务逻辑的划分

    接口隔离:注重的是接口的方法尽量少

    特点:

    (1)接口尽量小

    (2)拆分接口 : 接口隔离的核心定义, 不出现臃肿的接口;

    (3)接口高内聚

    (4)高内聚 : 提高接口, 类, 模块的处理能力, 减少对外界交互;

    (5)具体方法 : 接口中尽量少公布public 方法, 对外公布的 public 方法越少, 变更的风险就越小, 有利于后期的维护;

     

    定制服务:

    起源 : 系统模块间的耦合需要有相互访问的接口, 这里就需要为各个 客户端 的访问提供定制的服务接口;

    要求 : 只提供访问者需要的方法, 不需要的就不提供;

     

    接口隔离限度

      (1)粒度小 : 接口粒度越小, 系统越灵活, 但是同时使系统结构复杂, 开发难度增加, 降低了系统的可维护性;

    (2)粒度大 : 灵活性降低, 无法提供定制服务, 增大项目风险;

     


    原子接口划分原则:

    (1)接口模块对应关系 : 一个接口只服务于一个子模块 或 业务逻辑;

    (2)方法压缩 : 通过业务逻辑, 压缩接口中得 public 方法, 减少接口的方法的数量;

    (3)修改适配 : 尽量去修改已经污染的接口, 如果变更风险较大, 采用适配器模式进行转化处理;


      五.迪米特法则

    定义:  最少知识原则, 一个对象应该对其它对象有最少的了解, 即一个类对自己需要耦合或者调用的类知道的最少;朋友间必须保持距离

    距离太近示例 : 朋友间不能无话不说, 无所不知, 类 A 与 B 耦合, B 将很多方法暴露给 A, 两个类之间的的耦合关系非常牢固, 这明显违反设计原则;

    保持距离方法 : 将 类 B 暴露给 A 的方法封装, 暴露的方法越少越好, 类 B 高内聚, 与 A 低耦合;

      设计方法 : 一个类的 public 方法越多, 修改时涉及的范围也就越大, 变更引起的风险也就越大, 在系统设计时要注意, 能用 private 就用private , 能用protected 就用 protected, 能少用 public 就少用 public,能加上 final 就加上 final;

    优点 : 类间解耦, 弱耦合, 耦合降低, 复用率提高;

    缺点: 类间的耦合性太低, 会产生大量的中转或跳转类, 会导致系统的复杂性提高, 加大维护难度;

     


    六.开闭原则

    定义:软件的实体 类, 模块, 函数 应该对扩展开放, 对修改关闭; 即 软件实体 应该 通过扩展实现变化, 不是通过 修改已有的代码实现变化;

     

    优点: 

    (1)利于测试 : 如果改变软件内容, 需要将所有的测试流程都执行一遍, 如 单元测试, 功能测试, 集成测试等, 如果只是扩展, 只单独测试扩展部分即可;

    (2)提高复用性 : 所有逻辑都从原子逻辑组合, 原子逻辑粒度越小, 复用性越大; 这样避免相同逻辑存在, 修改时需要修改多个此相同逻辑;

      (3)提高可维护性 : 维护一个类最好的方式是 扩展一个类, 而不是修改一个类, 如果需要修改需要读懂源码才能修改, 扩展的话只需要了解即可, 直接继承扩展;

      (4)抽象  单一  最小化,面向接口编程

    (5)高扩展性

    (6)高内聚低耦合

     


    展开全文
  • IOS设计模式的六大设计原则之接口隔离原则(ISP,Interface Segregation Principle)-附件资源
  • 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种设计模式

    展开全文
  • 六大设计原则-迪米特原则

    千次阅读 2020-03-23 17:27:07
    面向对象语言是万物皆对象,类与类之间交互越频繁,类与类之间的关系也就越密切,这就是耦合,耦合度越高,当一个类发生改变时,对另一个类的影响也就越。一个好的系统要做到高内聚低耦合,迪米特原则就是要降低类...
  • 面向对象设计的六大设计原则(iOS)

    千次阅读 2018-09-11 18:12:32
    六大设计原则 原则一:开闭原则(Open Close Principle) 定义 用抽象构建框架,用实现扩展细节。 不以改动原有类的方式来实现新需求,而是应该以实现事先抽象出来的接口(或具体类继承抽象类)的方式来实现...
  • 六大设计原则之里氏替换原则

    万次阅读 2016-08-28 11:27:48
    里氏替换原则定义里氏替换原则(Liskov Substitution Principle,LSP): 第一种定义:如果对每一个类型为S的对象o1,都有类型为T的对象o2,使得以T定义的所有程序P在所有的对象o1都代换为o2,程序P的行为没有发生变化...
  • OO六大设计原则最全分析总结篇

    千次阅读 2018-04-20 09:06:14
    面向对象(OO)的基本特征: 抽象,先不考虑细节 封装,隐藏内部实现 ... OO六大设计原则: 单一职责 开闭原则 里氏替换 依赖倒置 接口隔离 迪米特法则 1. 单一职责原则(SRP) 定义...
  • 1.什么是设计模式 设计模式就是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解 ...3.六大设计原则 废话少说,看图! ...
  • 六大设计原则浅析

    千次阅读 2016-04-14 22:08:59
    一、设计在软件开发中的重要性重要性在上大学的时候我们总是不理解为什么要讲这么理论性的东西,当时就一个感觉就是没什么用,我们更想去学习一些可以看到...设计原则我们先来思考一个问题: 怎么样的软件才算一个好的
  • JAVA设计模式之六大设计原则

    千次阅读 2018-10-16 16:26:43
    在程序设计中,我们通常要遵循以下六大原则: 单一职责原则 官方定义: 就一个类(接口、结构体、方法等等)而言,有且仅有一个引起它变化的原因。 个人理解: 通俗的来讲做一件事就是专注做一件事,不可以...
  • 六大设计原则之OCP

    千次阅读 2018-10-21 23:09:25
    开闭原则(Open Closed Principle),简称OCP。 定义 软件实体应该对扩展开放,对修改关闭。何为软件实体?主要包括项目或软件产品按照一定的逻辑规则划分的模块,抽象,类,方法。实质是通过扩展来实现变化。 ...
  • 设计模式之六大设计原则

    千次阅读 2018-09-01 23:03:28
    单一职责原则(功能拆分) 核心:提高程序的可重用性 一个类只能有一个引起它变化的原因 解决的问题:降低类的复杂度、降低部件的耦合度 里氏代换原则 (继承) 核心:子类必须能够替换掉它们的父类型(即可以...
  • 六大设计原则之依赖倒置原则

    万次阅读 2016-08-23 11:42:52
    依赖倒置原则定义依赖倒置原则(Dependence Inversion Principle ,DIP)定义如下:High level modules should not depend upon low level modules,Both should depend upon abstractions.Abstractions should not ...
  • 六大设计原则-里氏替换原则

    千次阅读 2020-03-22 23:51:18
    里氏替换原则 什么是里氏替换原则? 里氏替换原则的定义:任何使用基类的地方,都可以透明的使用其子类。从定义中可以看出,它和继承差不多,我们也可以这样理解,里氏替换原则=继承+透明,也就是继承的加强版,取...
  • 六大设计原则之迪米特原则

    千次阅读 2016-08-27 16:05:36
    迪米特原则的定义迪米特原则(Law of Demeter,LoD),也叫最少知识原则(Low knowledge Principle,LKP):一个对象应该对其他对象有最少的了解。通俗的讲:一个类对自己需要耦合或调用的类知道的最少,你(被耦合或调用的...
  • 六大设计原则-单一职责原则

    千次阅读 2020-03-21 16:33:42
    单一职责原则 针对的问题 类T负责两个不同职责:职责P1和职责P2。当业务发生改变需要修改职责P1,有可能会影响到职责P2的功能。 解决方案 遵循单一职责原则,分别创建两个类:类T1和类T2。类T1负责职责P1的功能...
  • 软件工程六大设计原则

    千次阅读 2020-01-07 16:57:43
    1、单一职责原则 概念描述 对类来说,一个类应该只负责一项职责。如果一个类负责两个职责,可能存在职责1变化,引起职责2的变化情况。可以基于抽象逻辑,或者业务逻辑对类进行细化。 2、接口隔离原则 概念描述...
  • 六大设计原则之接口隔离原则

    万次阅读 2016-08-24 21:20:55
    接口隔离原则定义接口隔离有两种定义: Clients should not be forced to depend upon interfaces that they don’t use. 客户端不应该依赖它不需要的接口 那依赖什么呢?依赖它需要的接口,客户端需要什么接口就...
  • 六大设计原则之单一职责原则

    千次阅读 2016-08-17 20:20:28
    单一职责原则单一职责原则(Single Responsibility Principle)–SRP:There should never be more than one reason for a class to change.应该有且仅有一个原因引起类的变更。单一职责原则好处 降低类的复杂性每个类...
  • 六大设计原则-开闭原则

    千次阅读 2020-03-27 21:21:25
    面向对象语言是一种静态语言,最害怕变化,一旦变化就会波及很多东西,从而修改完需要进行全面测试,可以看出,修改需要付出的成本特别。最理想的就是不去修改原有的代码,要新增代码,原有代码才是最可靠的。 ...
  • 设计模式-六大设计原则

    千次阅读 2018-07-31 00:01:19
    1. 单一职责原则(SRP) 定义:就一个类而言,应该仅有一个引起它变化的原因。  从这句定义我们很难理解它的含义,通俗讲就是我们不要让一个类承担过多的职责。如果一个类承担的职责过多,就等于把这些职责耦合在...
  • 六大设计原则-依赖倒置原则

    千次阅读 2020-03-25 15:35:07
    什么是依赖倒置原则? 高层模块不应该依赖于低层模块,二者应该通过抽象依赖,而不是依赖细节 为什么要使用依赖倒置原则? 面向对象语言开发,就是类与类之间进行交互,如果高层直接依赖低层的细节,细节是多变的...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 122,483
精华内容 48,993
关键字:

六大设计原则