设为首页 加入收藏

TOP

SOLID 设计原则(一)
2017-10-13 10:40:33 】 浏览:529
Tags:SOLID 设计 原则

SOLID 原则基本概念:

程序设计领域, SOLID (单一功能、开闭原则、里氏替换、接口隔离以及依赖反转)是由罗伯特·C·马丁在21世纪早期 引入的记忆术首字母缩略字,指代了面向对象编程和面向对象设计的五个基本原则。当这些原则被一起应用时,它们使得一个程序员开发一个容易进行软件维护和扩展的系统变得更加可能SOLID被典型的应用在测试驱动开发上,并且是敏捷开发以及自适应软件开发的基本原则的重要组成部分。

 

[S] Single Responsibility Principle (单一功能原则)

单一功能原则 :单一功能原则 认为对象应该仅具有一种单一功能的概念。

换句话说就是让一个类只做一种类型责任,当这个类需要承担其他类型的责任的时候,就需要分解这个类。在所有的SOLID原则中,这是大多数开发人员感到最能完全理解的一条。严格来说,这也可能是违反最频繁的一条原则了。单一责任原则可以看作是低耦合、高内聚在面向对象原则上的引申,将责任定义为引起变化的原因,以提高内聚性来减少引起变化的原因。责任过多,可能引起它变化的原因就越多,这将导致责任依赖,相互之间就产生影响,从而极大的损伤其内聚性和耦合度。单一责任,通常意味着单一的功能,因此不要为一个模块实 现过多的功能点,以保证实体只有一个引起它变化的原因。

                                                   

namespace SOLID
{
    public class Users
    {
        /// <summary>
        /// 支付
        /// </summary>
        public void Pay(){}

        /// <summary>
        /// 数据库操作
        /// </summary>
        public void DataAccess(){}

        /// <summary>
        /// 日志操作
        /// </summary>
        public void Logger(){}
    }
}

在这个用户类中有这三个功能:1.支付逻辑,2数据库逻辑,3.日志操作。如果将这三个功能结合在一个类中,可能会出现修改部分代码时会破坏其他的部分。多个功能也使这个用户类难以理解,降低了内聚性。所以最好就是将这个类分离为三个分离的类,每个类仅仅有一个功能。

namespace SOLID
{
    /// <summary>
    /// 数据库操作
    /// </summary>
    class DataAccess { }
/// <summary> /// 日志 /// </summary> class Logger { }
/// <summary> /// 支付 /// </summary> class Pay { } }

 

[o] Open Close Principle (开闭原则)

开闭原则(ocp) 认为“软件体应该是对于扩展开放的,但是对于修改封闭的”的概念。

软件实体应该是可扩展,而不可修改的。也就是说,对扩展是开放的,而对修改是封闭的。这个原则是诸多面向对象编程原则中最抽象、最难理解的一个。
对扩展开放,意味着有新的需求或变化时,可以对现有代码进行扩展,以适应新的情况。
对修改封闭,意味着类一旦设计完成,就可以独立完成其工作,而不要对类进行任何修改。
可以使用变化和不变来说明:封装不变部分,开放变化部分,一般使用接口继承实现方式来实现“开放”应对变化,说大白话就是:你不是要变化吗?,那么我就让你继承实现一个对象,用一个接口来抽象你的职责,你变化越多,继承实现的子类就越多。

                                                    

    abstract class DataAccess
    {
        public abstract void OpenConnection();
        public abstract void CloseConnection();
        public abstract void ExecuteCommand();
    }

    /// <summary>
    /// SQL
    /// </summary>
    class SqlDataAccess : DataAccess
    {
        /// <summary>
        /// 打开SQL数据库
        /// </summary>
        public override void OpenConnection(){}
        /// <summary>
        /// 关闭Sql数据连接
        /// </summary>
        public override void CloseConnection(){}
        /// <summary>
        /// 执行Sql数据命令
        /// </summary>
        public override void ExecuteCommand(){}
    }
    
    /// <summary>
    /// ORACLE
    /// </summary>
    class OracleDataAccess : DataAccess
    {
        /// <summary>
        /// 打开Oracle数据连接
        /// </summary>
        public override void OpenConnection(){}
        /// <summary>
        /// 关闭Oracle数据连接
        /// </summary>
        public override void CloseConnection(){}
        /// <summary>
        /// 执行Oracle数据命令
        /// </summary>
        public override void ExecuteCommand(){}
    }

 

[L] Liskov Substitution Principle(里氏替换原则)

里氏替换原则 :里氏替换原则 认为“程序中的对象应该是可以在不改变程序正确性的前提下被它的子类所替换的”的概念。

软件工程大师Robert C. Martin把里氏替换原则最终简化为一句话:“Subtypes must be substitutable for their base types”。也就是,子类必须能够替换成它们的基类。即:子类应该可以替换任何基类能够出现的地方,并且经过替换以后,代码还能正常工作。另外,不应该 在代码中出现if/else之类对子类类型进行判断的条件。里氏替换原则LSP是使代码符合开闭原则的一个重要保证。正是由于子类型的可替换性才使得父类 型的模块在无需修改的情况下就可以扩展。在很

首页 上一页 1 2 3 下一页 尾页 1/3/3
】【打印繁体】【投稿】【收藏】 【推荐】【举报】【评论】 【关闭】 【返回顶部
上一篇GOF23设计模式归类 下一篇RPC 使用中的一些注意点

最新文章

热门文章

Hot 文章

Python

C 语言

C++基础

大数据基础

linux编程基础

C/C++面试题目