首页手记面向对象4原则

面向对象4原则

标签：

Java

OCP(开闭原则)

类应该对扩展开放，对修改而关闭。

应用举例

本人是做彩票业务的，就以彩票举例吧。下面是一段设计不良的校验投注号码的代码

 public boolean validate(String drawNum){
    if (type.equals("PL3")) {  
        PL3Validate validatePL3 = new PL3Validate();  
        validatePL3.validate();  
    }  
    else if (type.equals("PL5")) {  
        PL5Validate validatePL5 = new PL5Validate();  
        validatePL5.validate();  
    } 
}

其对应的类图为：

若这时添加大乐透彩种的校验，需要修改OCPDemo中的validate的代码，加入另外一个else if 分支，这违反了OCP原则，并没有对修改而关闭。
可以进行如下修改：
我们添加抽象类AbstractNumberValidate，让PL3Validate和PL5Validate继承该类，OCPDemo仅依赖AbstractNumberValidate类。上面的代码修改为：

 AbstractNumberValidate validate;
 public static class PL3ValidateImpl extends AbstractNumberValidate{
     public boolean validate(String drawNum){
         return false;
     }
 }

修改后的类图为：

这样无论添加任何彩种，OCPDemo的validate都不需要更改。若这时添加大乐透彩种的校验，只需要添加一个DLTValidate类继承AbstractNumberValidate实现自己的校验规则，并注入到OCPDemo中即可。

这里仅仅以继承的方式来解决上边的问题，解法不唯一。

OCP不仅仅是继承

OCP关系到灵活性，而不只是继承。
例如：你在类中有一些private的方法，（这就是禁止为修改而关闭），但是你有一些public方法以不同的方式调用private方法（允许为扩展而开放）

OCP的核心是 让你有效的扩展程序，而不是改变之前的程序代码。

DRY(不自我重复)

通过将共同之物抽取出来并置于单一地方避免重复的程序代码。

举例说明

Java初学者，使用JDBC，查询数据库中数据时，会有如下代码，每调用一个查询均会有
3部分，执行查询，提取结果，关闭结果集合。

        //调用查询
        stmt = conn.createStatement();
        result = stmt.executeQuery("select * from person");//执行sql语句，结果集放在result中  
        //提取结果
        while(result.next()){//判断是否还有下一行  
            String name = result.getString("name");//获取数据库person表中name字段的值  
            Person p=new Person();
            p.setName(name);
        }  
        //关闭结果集合
        result.close();  
        stmt.close();

如果每调用查询一次数据库均要写上述代码，绝对会非常的累，也违反DRY原则，系统中会出现大量的重复代码。
下面让我们看看Spring的JdbcTemplate如何遵循DRY原则。上边的模式，有一定的套路，Spring总结了套路，封装成了模板，经过Spring的封装，只需传入Sql，和结果集合转换的类。代码如下：

    //实际只需调用queryForObject即可
    @Override
    public <T> T queryForObject(String sql, Class<T> requiredType) throws DataAccessException {
        return queryForObject(sql, getSingleColumnRowMapper(requiredType));
    }

    public <T> T query(final String sql, final ResultSetExtractor<T> rse) throws DataAccessException {
        Assert.notNull(sql, "SQL must not be null");
        Assert.notNull(rse, "ResultSetExtractor must not be null");
        if (logger.isDebugEnabled()) {
            logger.debug("Executing SQL query [" + sql + "]");
        }
        class QueryStatementCallback implements StatementCallback<T>, SqlProvider {
            @Override
            public T doInStatement(Statement stmt) throws SQLException {
                ResultSet rs = null;
                try {
                    //执行SQL
                    rs = stmt.executeQuery(sql);
                    //----提取结果-start
                    ResultSet rsToUse = rs;
                    if (nativeJdbcExtractor != null) {
                        rsToUse = nativeJdbcExtractor.getNativeResultSet(rs);
                    }
                    return rse.extractData(rsToUse);
                    //--------提取结果-end
                }
                finally {
                //关闭结果集合
                    JdbcUtils.closeResultSet(rs);
                }
            }
            @Override
            public String getSql() {
                return sql;
            }
        }
        return execute(new QueryStatementCallback());
    }

DRY不仅应用于编码

抽取出重复程序代码是运用DRY的好开始，但DRY的内涵可不只是如此！当试图避免重复程序代码时，实际也在试着确保你对应用程序中每一个功能和需求只实现一次。
其实无论编写需求，开发用例或者编写代码都应该遵守DRY原则！

举个我工作中的例子
关于红包回收业务需求
我们的业务需求文档写了如下需求：

红包过期应该进行自动回收
红包领取后30天内有效，过期应该回收。
红包活动过期，应该回收未使用的红包。

这个是明显的不遵循DRY，当然产品经理可能没有听说过DRY，如果你遇到了这种情况，请默默的在心里将需求凝练下即可。例如：

应按规则回收红包，规则如下：
a. 未使用的在红包活动过期后回收
b. 已领取部分使用的自领取之日起30天后进行回收
c. 已使用完毕的不进行回收

SRP(单一职责)

系统中每一个对象应该具有单一职责，所有对象的服务都应该聚焦在实现该职责上。

应用举例

假设系统中有如下一个简单的Car类，其内部结果如下类图：

下面我们针对这个简单的例子，找出其不符合SRP的地方。

找出一个类中不符合SRP的方法为：

做填空，该【XXX类】自己【XXX 方法】，找出语义不通顺的地方
结合自身业务理解进行进一步分析，最终确定不符合SRP的部分。

以Car类为例子我们先进行第一步：

该 Car 自己 start

该 Car 自己 stop

该 Car 自己 getOil

该 Car 自己 wash （？车自己洗车）

该 Car 自己 drive （？车自己驾驶，难道是自动驾驶的车）

我们找出两个方法可能不遵循SRP，一个是wash，一个是drive。

下面我们执行第二步，根据根据业务理解进行分析。
这里我们没有什么业务背景，仅依据生活经验进行分析。

车一般有其他人或机构进行清洗，不属于车的部分。应该从Car移除
drive，处理自动驾驶车以外，车均由司机驾驶，自动驾驶车的驾驶员可以理解为电脑，所以drive也不属于Car类，应该从Car类移除。

从上边的小例子我们可以看出：

方法名称要与具体实现的功能相符，否则第一步无法部分进行。
对业务的理解很重要，否则无法最终决定违反SRP的部分。

2点说明

DRY和SRP往往一同出现，DRY关注把一个功能片段放到一个单独的地方。
SRP是关于一个类只做一件事。
内聚力的另外一个名称就是SRP。

LSP（里氏替换原则）

子类型必须能够替换其基类型。

违反LSP的情形举例

假设我们有一个Graph2D 用于制作2D平面，现在要新创建一个Graph3D类，用于构建立体图，下面我们使用违反LSP原则的方式实现。

public static class Graph2D{
        int x;
        int y;

        public void setGraph(int x,int y){
            this.x=x;
            this.y=y;
        }
    }
    public static class Graph3D extends Graph2D{
        int z;

        public void setGraph(int x,int y,int z){
            this.x=x;
            this.y=y;
            this.z=z;
        }
    }
    public static void main(String[] args) {
        Graph3D Graph3D=new Graph3D();
        // 由于继承，使用者会非常迷茫，如何设置x,y,z
        Graph3D.setGraph(x, y);//来自父类Graph2D
        Graph3D.setGraph(x, y, z);//自己的
    }

上边的代码我们让Graph3D继承了Graph2D，造成Graph3D的使用者对setGraph产生了疑惑。因为有2个setGraph方法。若不了解内部实现的人，将难以使用。

如何解决不满足LSP的情况

一共有3种处理方式：委托，聚合，组合。

委托

将特定工作的责任委派给另外一个类或方法。

如果你想要使用另一个类的功能性，但不想改变该功能，考虑以委托代替继承。

下面我们以委托的方式，解决上的问题,修改后代码，仅有一个setGraph方法，不会产生不必要的麻烦。
原本的类图为：

以委托的方式修改后的类图，这时Graph3D依赖时Graph2D

相应的代码如下：

public static class Graph2D{
        int x;
        int y;

        public void setGraph(int x,int y){
            this.x=x;
            this.y=y;
        }
    }
    public static class Graph3D {
        int z;
        private Graph2D graph2D;//将平面部分委托给Graph2D处理
        public void setGraph(int x,int y,int z){
            graph2D.setGraph(x, y);
            this.z=z;
        }
    }
    public static void main(String[] args) {
        Graph3D graph3D=new Graph3D();
        graph3D.setGraph(x, y, z);
    }