面向对象六大原则

最近在工作中发现自己对设计模式是一知半解，打算认真看一下设计模式相关的书籍，并做一些记录与大家分享（不要嫌弃我写的不好，因为现在的我确实很菜）。

先来看面向对象的六大原则吧

（一） 单一职责原则
（二） 开闭原则
（三） 里氏替换原则
（四） 依赖倒置原则
（五） 接口隔离原则
（六） 迪米特原则

单一职责原则

    定义 ： 就一个类而言，应该仅有一个引起它变化的原因。简单的讲呢，就是一个类中应该是一组相关性很高的函数、数据的封装。

    class ImageLoader{
        download();
        cache();
        display();
    }
    就像上面的代码一样我们把所有功能写到一个类中，随着我们项目越来越大功能也越来越大，会导致这个类很庞大也很脆弱。这时候可以拆分出来每个功能都有一个单独的类来完成。
    class Cache(){        
         cache();   
    }
    class Download{
        download();
    }
    就像这样我们把缓存和下载单独拿出来 Imageloader只保留显示的功能，这样我们的代码结构就会清晰很多。

开闭原则

    定义 软件中的对象（类、模块、函数等）应该对于扩展是开放的，但是对于修改是封闭的。 也就是说当软件需要变化时我们应该尽量通过扩展的方式来实现变化，而不是通过修改已有的代码来实现。

    class MemoryCache{
        get();
        put();          
    }
    我们有这么个类给用户使用

    class ImageLoader{
        MemoryCache m = new MemoryCache();
        display();

    }
    在我们的ImageLoader中只能使用这个类进行内存缓存。那么问题来了假如用户有个需求需要自己实现那该怎么办呢，总不能去修改我们之前的代码吧（可能会对其他地方有影响）。这时候我们可以这样把get 和 put抽象出来
    interface Cache{
        put();
        get();
    }
    然后  class MemoryCache implements Cache{
        get();
        put();          
    }
    现在我们的ImageLoader也要做出改变了
    class ImageLoader{
        Cache m = new Cache();
        display();
        m.get();
        m.set();
        set(Cache m);
    }

    这样当我们不想用这个MemoryCache我们可以实现Cache接口去自己实现 然后set就行了  （是不是太啰嗦了）

里氏替换原则

    定义 所有引用基类的地方必须能透明使用其子类的对象。 里氏替换原则就是依赖于继承，多态两大特性。就两个字  ：  抽象。
    就像之前的缓存类一样 MemoryCache 可以替换掉 Cache的工作并且还能保证行为的正确性。
    我们把put 和 set 抽象了 这就使我们的缓存类有了扩展的可能，保证了可扩展性。
    里氏替换为我们提供了一个指导原则  也就是建立抽象，通过抽象建立规范，具体实现在运行时替换掉抽象，保证系统的扩展性，灵活性

依赖倒置原则

    定义 高层模块不应该依赖低层模块，两者之间都应该依赖抽象
        抽象不应该依赖细节(实现类)，细节应该依赖抽象
        模块间的依赖关系通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的。

    class ImageLoader{
        MemoryCache m = new MemoryCache();
        display();

    }
        这个时候我们的ImageLoader就是依赖了MemoryCache 所以Imageloader 和 MemoryCache有直接的耦合当我们的具体实现需要变化时意味着要同时修改依赖者的代码,限制了系统的可扩展性。
        当产品升级 我们会发现 MemoryCache已经不能满足需求了  这可怎么办呢 
        其实我们可以不要ImageLoader去依赖MemoryCache这个具体的实现 我们应该依赖Cache这个抽象
        就和开闭原则里一样  通过set 去替换Cache的工作 这样系统的扩展性就跟高了  完美的解决了我们之前的问题。

接口隔离原则

        定义  客户端不应该依赖它不需要的接口。类间的依赖关系应该是建立在最小的接口上。
        把非常庞大、臃肿的接口拆分成更小和更具体的接口  客户将会只需知道他们感兴趣的方法。
        接口隔离原则的目的是系统解开耦合 从而容易重构 更改和重新部署。

        interface CUser{
            register();
            login();
            delete();
        }
        CUser中有个delete但是实际上用户是用不到的 只有后台管理员才有delete的权限所以我们拆分一下。

        interface CUser{
            register();
            login();
            delete();
        }

        interface MUser{
                delete();
            }

迪米特原则

        定义 一个对象应该对其他对象有最少的了解。也就是只和最近的朋友通信.

        例如 我们找房子先找中介然后中介把房子提供给我们，我们自己看合不合适 这个过程我们即和中介有交互也和房子有交互，导致我们的工作量很大 显然不符合我们找中介的原因（就是图个方便）那这个时候该怎么办呢  
        我们可以这样  我们把我们的要求直接和中介说 由中介去找房子比对  我们只需要知道中介是否找到了房子就好了  这个过程中呢 我们只是和中介有交互。