阅读 2484

如何写出优秀的代码?设计模式六大原则告诉你

人生一切难题,知识给你答案

温馨提示:阅读本文需要4-5分钟(少量代码)


今天,我们来解决一个问题:

如何写出优秀的代码?设计模式六大原则告诉你

人生一切难题,知识给你答案。


==单一原则==

定义:应该有且仅有一个原因引起类的变更。

单一原则适用于接口、类以及方法,对于接口,我们在设计的时候一定要做到单一,但对于实现类就需要多方面考虑。生搬硬套单一原则会引起类的剧增,给维护带来非常多的麻烦。而且过分细分类的职责也会人为地增加系统的复杂性。

最常见的就是Activity类,如果我们在Activity中进行网络请求操作,请求完毕又进行业务处理,处理之后通知View的刷新,这样做的话Activity就会变的十分臃肿,Activity的职责就是显示视图并处理与用户的交互,如何解决呢?抽离网络请求操作与业务操作,通过接口回调通知Activity视图的变更,推荐使用MVP模式。

对于单一原则,建议是接口一定要做的单一职责,类的设计尽量做到只有一个原因引起变化。

==开闭原则==

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

开闭原则的定义已经非常明确地告诉我们:软件实体应该对扩展开放,对修改关闭,其含义是说一个软件实体应该通过扩展来实现变化,而不是通过修改已有的代码来实现变化。

比如现有一个类ProductFactory用来生产一堆产品:

public class ProductFactory {
    private final static List<Product> productList=new ArrayList<>();

    static {
        Product product=new Product();
        product.setPrice(10);
        product.setName("产品A");
        productList.add(product);
        product=new Product();
        product.setPrice(10);
        product.setName("产品B");
        productList.add(product);
    }
    
    public List<Product> getProduct(){
        return productList;
    }

}
复制代码

客户端通过创建ProductFactory并调用getProduct方法就可以获取产品列表,看似非常完美,如果这个时候产品说我想获取产品A,然后过了几天由于产品效益不是很高,需要做打折处理,这个时候怎么办?是在ProductFactory类中新增方法还是直接在该方法中修改?由于业务的不断变化,造成该类被频繁修改。

使用开闭原则来解决,创建一个接口IProduct,内部约定一个规则:

public interface IProduct {
    List<Product> getProduct();
}
复制代码

正常产品获取:

public class ProductFactory implements IProduct {

    private final static List<Product> productList=new ArrayList<>();

    static {
        Product product=new Product();
        product.setPrice(10);
        product.setName("产品A");
        productList.add(product);
        product=new Product();
        product.setPrice(10);
        product.setName("产品B");
        productList.add(product);
    }

    @Override
    public List<Product> getProduct() {
        return productList;
    }
}
复制代码

客户端使用:

public class Client {
    public static void main(String[] args){
        IProduct productFactory=new ProductFactory();
        List<Product> productList=productFactory.getProduct();
    }
}
复制代码

产品经理说我只需要产品A的产品,通过扩展来实现:

public class ProductAFactory implements IProduct {

    private final static List<Product> productList=new ArrayList<>();

    static {
        Product product=new Product();
        product.setPrice(10);
        product.setName("产品A");
        productList.add(product);
        product=new Product();
        product.setPrice(10);
        product.setName("产品B");
        productList.add(product);
    }

    @Override
    public List<Product> getProduct() {
        List<Product> list=new ArrayList<>();
        for(Product product:productList){
            boolean isProductA=product.getName().equals("产品A");
            if(isProductA){
                list.add(product);
            }
        }
        return list;
    }
}

复制代码

客户端那边只需要把ProductFactory替换成ProductAFactory即可,即使产品说需要将产品进行打折处理,我们只需要创建打折类实现IProduct并实现getProduct方法进行打折处理。

==里氏替换原则==

定义:所有引用基类(父类)的地方必须能透明地使用其子类的对象。

里氏替换原则告诉我们,在软件中将一个基类替换成其子类对象,程序将不会产生任何错误和异常;反之则不行,如果一个软件实体使用的是一个子类对象的话,那么它不一定能够使用基类对象。

子类的所有方法必须在父类中声明,或子类必须实现父类中声明的方法。根据里氏替换原则,为了保证系统的扩展性,在程序中通常使用父类来进行定义。

在运用里氏替换原则时,尽量把父类设计为抽象类或者接口,让子类继承父类或实现父接口,并实现在父类中声明的方法。运行时,子类实例替换父类实例,我们可以方便地扩展系统的功能。

==依赖倒置原则==

定义:高层模块不应该依赖低层模块,两者都应该依赖于抽象。抽象不应该依赖于细节,细节应该依赖于抽象。

在Java中,抽象指接口或者抽象类,两者都不能直接被实例化。

细节就是实现类,实现接口或继承抽象类而产生的就是细节。

高层模块就是调用端,低层模块就是具体实现类。

依赖倒置的具体表现就是,模块间的依赖通过抽象发生,实现类之间不发生直接依赖关系,其依赖关系是通过接口或者抽象类产生的。

如果类与类直接依赖细节,那么就会直接耦合,如此一来当修改时,就会同时修改依赖者代码,限制了可扩展性。

==迪米特原则==

定义:一个软件实体应当尽可能少地与其他实体发生相互作用。

迪米特原则又被称为最少知识原则,通俗地讲,设计系统时尽量减少对象之间的交互,如果两个对象之间不必彼此直接通信,那么这两个对象就不应当发生任何直接的相互作用。

如果其中的一个对象需要调用另一个对象的某个方法,可以通过第三方转发这个调用。引入一个合理的第三者来降低现有对象之间的耦合度。

==接口隔离原则==

定义:一个类对另一个类的依赖应该建立在最小的接口上。

建立单一接口,不要建立庞大臃肿的接口;尽量细化接口,接口中的方法尽量少。也就是说,我们要为各个类建立专用的接口,而不要试图建立一个很庞大的接口供所有依赖它的类调用。

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


838794-506ddad529df4cd4.webp.jpg

关注下面的标签,发现更多相似文章
评论