>>>>系统架构设计师在线辅导

    >>>>系统架构设计师培训视频

    >>>>系统架构设计师考试教材

    系统架构设计师是一个最终确认和评估系统需求，给出开发规范，搭建系统实现的核心构架，并澄清技术细节、扫清主要难点的技术人员。系统架构设计师考试合格人员能够根据系统需求规格说明书，结合应用领域和技术发展的实际情况，考虑有关约束条件，设计正确、合理的软件架构，确保系统架构具有良好的特性；能够对项目的系统架构进行描述、分析、设计与评估；能够按照相关标准编写相应的设计文档；能够与系统分析师、项目管理师相互协作、配合工作；具有高级工程师的实际工作能力和业务水平。

    架构师是由国外引进的一个概念，国外软件开发的几个职位是技术官、架构师、设计师、开发、测试，对应我们的公司应该是技术总监、架构师、系统分析员、程序员、测试人员。

    1OO的设计原则

    采用面向对象的分析和设计思想，为我们分析和解决问题提供了一种全新的思维方式。我们在拿到需求之后(略去OOA，以后补全)，接下来的问题就是：如何对系统进行面向对象的设计呢？

    按照软件工程的理论，面向对象的设计要解决的核心问题就是可维护性和可复用性。尤其是可维护性，它是影响软件生命周期重要因素，通常情况下，软件的维护成本远远大于初期开发成本。

    一个可维护性很差的软件设计，人们通常称之为“臭味”的，形成的原因主要有这么几个：过于僵硬、过于脆弱、复用率低或者黏度过高。相反，一个好的系统设计应该是灵活的、可扩展的、可复用的、可插拔的。在20世纪80到90年代，很多业内希赛网不断探索面向对象的软件设计方法，陆续提出了一些设计原则。这些设计原则能够显著地提高系统的可维护性和可复用性，成为了我们进行面向对象设计的指导原则：

    1、单一职责原则SRP

    每一个类应该只专注于做一件事。

    2、“开-闭”原则OCP

    每一个类应该是对扩展开放，对修改关闭。

    3、里氏代换原则LSP

    避免造成派生类的方法非法或退化，一个基类的用户应当不需要知道这个派生类。

    4、依赖倒转原则DIP

    用依赖于接口和抽象类来替代依赖容易变化的具体类。

    5、接口隔离原则ISP

    应当为客户提供尽可能小的接口，而不是提供大的接口。

    其中，“开-闭”原则是面向对象的可复用设计的基石，其他设计原则是实现“开-闭”原则的手段和工具。

    我会为大家一一进行讲解。

    2　单一职责原则SRP(Single-ResponsibilityPrinciple)

    2.1什么是单一职责

    单一职责就是指一个类应该专注于做一件事。现实生活中也存谥钊绱死嗟奈侍猓?ldquo;一个人可能身兼数职，甚至于这些职责彼此关系不大，那么他可能无法做好所有职责内的事情，所以，还是专人专管比较好。”我们在设计类的时候，就应该遵循这个原则：单一职责。

    我们以计算器编程为例：

    在有些人眼里，计算器就是一件东西，是一个整体，所以它把这个需求进行了抽象，最终设计为一个Calculator类，代码如下：

    classCalculator{

    publicStringcalculate(){

    Console.Write("Pleaseinputthefirstnumber:");

    StringstrNum1=Console.ReadLine();

    Console.Write(Pleaseinputtheoperator:");

    StringstrOpr=Console.ReadLine();

    Console.Write("Pleaseinputthesecondnumber:");

    StringstrNum2=Console.ReadLine();

    StringstrResult="";

    if(strOpr=="+"){

    strResult=Convert.ToString(Convert.ToDouble(strNum1)+Convert.ToDouble(strNum2));

    }

    elseif(strOpr=="-"){

    strResult=Convert.ToString(Convert.ToDouble(strNum1)-Convert.ToDouble(strNum2));

    }

    elseif(strOpr=="*"){

    strResult=Convert.ToString(Convert.ToDouble(strNum1)*Convert.ToDouble(strNum2));

    }

    elseif(strOpr=="/"){

    strResult=Convert.ToString(Convert.ToDouble(strNum1)/Convert.ToDouble(strNum2));

    }

    Console.WriteLine("Theresultis"+strResult);

    }}

    另外，还有一部分人认为：计算器是一个外壳和一个处理器的组合。

    classAppearance{

    publicintdisplayInput(String&strNum1,String&strOpr,String&strNum2){

    Console.Write("Pleaseinputthefirstnumber:");

    strNum1=Console.ReadLine();

    Console.Write(Pleaseinputtheoperator:");

    strOpr=Console.ReadLine();

    Console.Write("Pleaseinputthesecondnumber:");

    strNum2=Console.ReadLine();

    return0;

    }　publicStringdisplayOutput(StringstrResult){

    Console.WriteLine("Theresultis"+strResult);

    }

    }

    classProcessor{

    publicStringcalculate(StringstrNum1,StringstrOpr,StringstrNum2){

    StringstrResult="";

    if(strOpr=="+"){

    strResult=Convert.ToString(Convert.ToDouble(strNum1)+Convert.ToDouble(strNum2));

    }

    elseif(strOpr=="-"){

    strResult=Convert.ToString(Convert.ToDouble(strNum1)-Convert.ToDouble(strNum2));

    }

    elseif(strOpr=="*"){

    strResult=Convert.ToString(Convert.ToDouble(strNum1)*Convert.ToDouble(strNum2));

    }

    elseif(strOpr=="/"){

    strResult=Convert.ToString(Convert.ToDouble(strNum1)/Convert.ToDouble(strNum2));

    }

    returnstrResult;

    }

    }

    为什么这么做呢？因为外壳和处理器是两个职责，都是很容易发生需求变动的因素，所以把他们放到一个嘀校ケ沉说ヒ恢霸鹪颉?/p>

    比如，用户可能对计算器提出以下要求：

    第一，目前已经实现了“加法”、“减法”、“乘法”和“除法”，以后还可能出现“乘方”、“开方”等很多运算。

    第二，现在人机界面太简单了，还可能做个Windows计算器风格的界面或者Mac计算器风格的界面。

    所以，把一个类Calculator拆分为两个类Appearance和Processor，更容易应对需求变化。如果界面需要修改，那么就去修改Appearance类；如果处理器需要修改，那么就去修改Processor类。

    我们再举一个邮件的例子。我们平常收到的邮件内容，看起来是一封信，实际上内部有两部分组成：邮件头和邮件体。电子邮件的编码要求符合RFC822标准。

    第一种设计方式是这样：

    interfaceIEmail{

    publicvoidsetSender(Stringsender);

    publicvoidsetReceiver(Stringreceiver);

    publicvoidsetContent(Stringcontent);

    }

    classEmailimplementsIEmail{

    publicvoidsetSender(Stringsender){//setsender;}

    publicvoidsetReceiver(Stringreceiver){//setreceiver;}

    publicvoidsetContent(Stringcontent){//setcontent;}

    }

    这个设计是有问题的，因为邮件头和邮件体都有变化的可能性。

    1、邮件头的每一个域的编码，可能是BASE64，也可能是QP，而且域的数量也不固定。

    2、邮件体中封装的邮件内容可能是PlainText类型,也可能是HTML类型，甚至于流媒体。

    所谓第一种设计方式违背了单一职责原则，里面封装了两种可能引起变化的原因。

    我们依照单一职责原则，对其进行改进后，变为第二种设计方式：

    interfaceIEmail{

    publicvoidsetSender(Stringsender);

    publicvoidsetReceiver(Stringreceiver);

    publicvoidsetContent(IContentcontent);

    }

    interfaceIContent{

    publicStringgetAsString();

    }

    classEmailimplementsIEmail{

    publicvoidsetSender(Stringsender){//setsender;}

    publicvoidsetReceiver(Stringreceiver){//setreceiver;}

    publicvoidsetContent(IContentcontent){//setcontent;}

    }

    有的资料把单一职责解释为：“仅有一个引起它变化的原因”。这个解释跟“专注于做一件事”是等价的。如果一个类同时做两件事情，那么这两件事情都有可能引起它的变化。同样的道理，如果仅有一个引起它变化的原因，那么这个类也就只能做一件事情。

    2.2单一职责原则的使用

    单一职责原则的尺度如何掌握呢？我怎么能知道该拆分还是不应该拆分呢？原则很简单：需求决定。如果你所需要的计算器，永远都没有外观和处理器变动的可能性，那么就应该把它抽象为一个整体的计算器；如果你所需要的计算器，外壳和处理器都有可能发生变动，那么就必须把它拆离为外壳和处理器。只能有一个原因可能引起计算器的变化。

    单一职责原则把相同的职责进行聚合，避免把相同的职责分散到不同的类之中，这样就可以控制变化，把变化限制在一个地方，防止因为一个地方的变动，引起更多地方的变动的“涟漪效应”。单一职责原则实际上消除了对象之间的耦合，避免一个类承担过多的职责。单一职责不是说一个类就只有一个方法，而是单一功能。

    我们在使用单一职责原则的时候，牢记以下几点：

    A、一个设计合理的类，应该仅有一个可以引起它变化的原因，即单一职责，如果有多个原因可以引起它的变化，就必须进行分离；

    B、在没有需求变化征兆的情况下，应用SRP或其他原则是不明智的，因为这样会使系统变得很复杂，系统由一堆细小的颗粒组成，这纯属于没事找抽；

    C、在需求能够预计或实际发生变化时，就应该使用SRP原则来重构代码，有经验的设计师、架构师对可能出现的需求变化很敏感，设计上就会具有前瞻性。

    后记：最近看了一个“现场说法”的电视节目，着实有意思。说是最近有两个偷车大盗被我警方抓获。这俩大盗都是贼中高手，非常了得，不过，他们却有着不同的成长路线。

    其中一个大盗，苦心钻研开锁技术，专门去香港学习先进技术，前后花了一百多万，非常舍得投资，回来后屡屡得手。另一个大盗，就比较狡猾，整天到商场的停车场，跟随着宝马、奔驰的车主，在车主购物的时候，伺机偷去车钥匙，然后从停车场把车开走，案发的时候案值达到了千万。呵呵，看来干什么事，都得找到关键所在。

    相关编辑推荐

    系统架构设计师：面向过程和面向对象

    系统架构设计师：详解面向过程

    系统架构设计师：架构师的职责

    系统架构设计师：详解面向对象