软件开发设计原则
类图：
这幅图清晰地表达了六大设计原则，但仅限于它们叫什么名字而已，它们具体是什么意思呢？下面我将从原文、译文、理解、应用，这四个方面分别进行阐述。
基本设计原则
1、单一职责原则（Single Responsibility Principle - SRP）
原文：There should never be more than one reason for a class to change。
译文：永远不应该有多于一个原因来改变某个类。
理解：对于一个类而言，应该仅有一个引起它变化的原因。说白了就是，不同的类具备不同的职责，各施其责。这就好比一个团队，大家分工协作，互不影响，各做各的事情。
应用：当我们做系统设计时，如果发现有一个类拥有了两种的职责，那就问自己一个问题：可以将这个类分成两个类吗？如果真的有必要，那就分吧。千万不要让一个类干的事情太多！
2、开放封闭原则（Open Closed Principle - OCP）
原文：Software entities like classes，modules and functions should be open for extension but closed for modifications。
译文：软件实体，如：类、模块与函数，对于扩展应该是开放的，但对于修改应该是封闭的。理解：简言之，对扩展开放，对修改封闭。换句话说，可以去扩展类，但不要去修改类。应用：当需求有改动，要修改代码了，此时您要做的是，尽量用继承或组合的方式来扩展类的功能，而不是直接修改类的代码。当然，如果能够确保对整体架构不会产生任何影响，那么也没必要搞得那么复杂了，直接改这个类吧。
3、里氏替换原则（Liskov Substitution Principle - LSP）
原文：Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it。
译文：使用基类的指针或引用的函数，必须是在不知情的情况下，能够使用派生类的对象。理解：父类能够替换子类，但子类不一定能替换父类。也就是说，在代码中可以将父类全部
替换为子类，程序不会报错，也不会在运行时出现任何异常，但反过来却不一定成立。
应用：在继承类时，务必重写（Override）父类中所有的方法，尤其需要注意父类的protected 方法（它们往往是让您重写的），子类尽量不要暴露自己的public 方法供外界调用。
该原则由麻省理工学院的Barbara Liskov 女士提出，她是美国第一位获取计算机博士学位的女性，曾经也获得过计算机图灵奖。
4、最少知识原则（Least Knowledge Principle - LKP）
原文：Only talk to you immediate friends。
译文：只与你最直接的朋友交流。
理解：尽量减少对象之间的交互，从而减小类之间的耦合。简言之，一定要做到：低耦合，高内聚。
应用：在做系统设计时，不要让一个类依赖于太多的其他类，需尽量减小依赖关系，否则，您死都不知道自己怎么死的。
该原则也称为“迪米特法则（Law of Demeter）”，由Ian Holland 提出。这个人不太愿意和陌生人说话，只和他走得最近的朋友们交流。
5、接口隔离原则（Interface Segregation Principle - ISP）
原文：The dependency of one class to another one should depend on the smallest possible interface。
译文：一个类与另一个类之间的依赖性，应该依赖于尽可能小的接口。
理解：不要对外暴露没有实际意义的接口。也就是说，接口是给别人调用的，那就不要去为难别人了，尽可能保证接口的实用性吧。她好，我也好。
应用：当需要对外暴露接口时，需要再三斟酌，如果真的没有必要对外提供的，就删了吧。一旦您提供了，就意味着，您将来要多做一件事情，何苦要给自己找事做呢。
6、依赖倒置原则（Dependence Inversion Principle - DIP）
原文：High level modules should not depends upon low level modules。Both should depend upon abstractions。Abstractions should not depend upon details。Details should depend upon abstractions。
译文：高层模块不应该依赖于低层模块，它们应该依赖于抽象。抽象不应该依赖于细节，细节应该依赖于抽象。
理解：应该面向接口编程，不应该面向实现类编程。面向实现类编程，相当于就是论事，那是正向依赖（正常人思维）；面向接口编程，相当于通过事物表象来看本质，那是反向依赖，即依赖倒置（程序员思维）。
应用：并不是说，所有的类都要有一个对应的接口，而是说，如果有接口，那就尽量使用接口来编程吧。
将以上六大原则的英文首字母拼在一起就是SOLID（稳定的），所以也称之为SOLID 原则。只有满足了这六大原则，才能设计出稳定的软件架构！但它们毕竟只是原则，只是四人帮给我们的建议，有些时候我们还是要学会灵活应变，千万不要生搬硬套，否则只会把简单问题复杂化，切记！
补充设计原则
1、组合/聚合复用原则（Composition/Aggregation Reuse Principle - CARP）
当要扩展类的功能时，优先考虑使用组合，而不是继承。这条原则在23 种经典设计模式中频繁使用，如：代理模式、装饰模式、适配器模式等。可见江湖地位非常之高！
2、无环依赖原则（Acyclic Dependencies Principle - ADP）
当A 模块依赖于B 模块，B 模块依赖于C 模块，C 依赖于A 模块，此时将出现循环依赖。在设计中应该避免这个问题，可通过引入“中介者模式”解决该问题。
3、共同封装原则（Common Closure Principle - CCP）
应该将易变的类放在同一个包里，将变化隔离出来。该原则是“开放-封闭原则”的延生。
4、共同重用原则（Common Reuse Principle - CRP）
如果重用了包中的一个类，那么也就相当于重用了包中的所有类，我们要尽可能减小包的大小。
5、好莱坞原则（Hollywood Principle - HP）
好莱坞明星的经纪人一般都很忙，他们不想被打扰，往往会说：Don’t call me，I’ll call you。翻译为：不要联系我，我会联系你。对应于软件设计而言，最著名的就是“控制反转”（或称为“依赖注入”），我们不需要在代码中主动的创建对象，而是由容器帮我们来创建并管理这些对象。
其他设计原则
1、不要重复你自己（Don’t repeat yourself - DRY）
不要让重复的代码到处都是，要让它们足够的重用，所以要尽可能地封装。
2、保持它简单与傻瓜（Keep it simple and stupid - KISS）
不要让系统变得复杂，界面简洁，功能实用，操作方便，要让它足够的简单，足够的傻瓜。
3、高内聚与低耦合（High Cohesion and Low Coupling - HCLC）
模块内部需要做到内聚度高，模块之间需要做到耦合度低。
4、惯例优于配置（Convention over Configuration - COC）
尽量让惯例来减少配置，这样才能提高开发效率，尽量做到“零配置”。很多开发框架都是这样做的。
5、命令查询分离（Command Query Separation - CQS）
在定义接口时，要做到哪些是命令，哪些是查询，要将它们分离，而不要揉到一起。
6、关注点分离（Separation of Concerns - SOC）
将一个复杂的问题分离为多个简单的问题，然后逐个解决这些简单的问题，那么这个复杂的问题就解决了。难就难在如何进行分离。
7、契约式设计（Design by Contract - DBC）
模块或系统之间的交互，都是基于契约（接口或抽象）的，而不要依赖于具体实现。该原则建议我们要面向契约编程。
8、你不需要它（You aren’t gonna need it - YAGNI）
不要一开始就把系统设计得非常复杂，不要陷入“过度设计”的深渊。应该让系统足够的简单，而却又不失扩展性，这是其中的难点。
敏捷开发模式的修炼之道
关于高内聚低耦合
什么是耦合度
软件设计中通常用耦合度和内聚度作为衡量模块独立程度的标准。划分摸块的一个准则就是高内聚低耦合。耦合度(Coupling)是对模块间关联程度的度量。耦合的强弱取决与模块间接口的复杂性、调用模块的方式以及通过界面传送数据的多少。模块间的耦合度是指模块之间的依赖关系，包括控制关系、调用关系、数据传递关系。模块间联系越多，其耦合性越强，同时表明其独立性越差。降低模块间的耦合度能减少模块间的影响，防止对某一模块修改所引起的“牵一发动全身”的水波效应，保证系统设计顺利进行。内聚和耦合密切相关，同其它模块存在强耦合关系的模块常意味这弱内聚，强内聚常意味着弱耦合。
耦合度就是某模块（类）与其它模块（类）之间的关联、感知和依赖的程度，是衡量代码独立性的一个指标，也是软件工程设计及编码质量评价的一个标准。
耦合的强度依赖于以下几个因素：
（1）一个模块对另一个模块的调用；
（2）一个模块向另一个模块传递的数据量；
（3）一个模块施加到另一个模块的控制的多少；
（4）模块之间接口的复杂程度。
耦合按从强到弱的顺序可分为以下几种类型：
非直接耦合：两模块间没有直接关系，之间的联系完全是通过主模块的控制和调用来实现的数据耦合：一个模块访问另一模块，彼此间通过简单数据参数来交换输入、输出信息。这里的简单数据参数不同于控制参数、公共数据结构或外部变量。
标记耦合：如一组模块通过参数表传递记录信息，就是标记耦合。这个记录是某一数据结构的子结构，不是简单变量。
控制耦合：一个模块通过传递开关、标志、名字等控制信息，明显的控制选择另一模块的功能。
外部耦合：一组模块都访问同一全局简单变量而不是同一全局数据结构，而且不是通过参数传递该全局变量的信息
公共耦合：一组模块都访问同一个公共数据环境。该公共数据环境可以是全局数据结构、共享的通信区、内存的公共覆盖区等。
内容耦合：一个模块直接修改另一个模块的数据，或直接转入另一个模块内聚度是指内部各元素之间联系的紧密程度，模块的内聚种类通常可分为7种，按其内聚度从低到高的次序依此为：偶然内聚、逻辑内聚、瞬时内聚、过程内聚、通信内聚、顺序内聚、功能内聚。
二、为什么要低耦合
了解什么是耦合及耦合的分类后，我想大家对为什么要降低耦合度已经有一定的认识，并且多数开发人员也大概尝尽了高耦合带来的苦头。道理很简单，耦合度很高的情况下，维护代码时修改一个地方会牵连到很多地方，如果修改时没有理清这些耦合关系，那么带来的后果可能会是灾难性的，特别是对于需求变化较多以及多人协作开发维护的项目，修改一个地方会引起本来已经运行稳定的模块错误，严重时会导致恶性循环，问题永远改不完，开发和测试都在各种问题之间奔波劳累，最后导致项目延期，用户满意度降低，成本也增加了，这对用户和开发商影响都是很恶劣的，各种风险也就不言而喻了。
为了预防这些问题的发生，其中一个重要手段就是降低代码的耦合度。但也不可能有绝对的零耦合，比如基于J2EE编程那就必须和JDK耦合，而且高耦合也不是一无是处，如果在设计前期预料到某功能后期基本不用修改，那么即使高耦合了也关系不大。
但是，在还没有能力设计出基本不用修改的代码前，还得要求以低耦合为标准。那么怎样才能最大限度地降低耦合度呢？下面介绍降低耦合度的几种方法。
三、降低耦合度的方法
1、少使用类的继承，多用接口隐藏实现的细节。java面向对象编程引入接口除了支持多态外，隐藏实现细节也是其中一个目的。
2、模块的功能化分尽可能的单一，道理也很简单，功能单一的模块供其它模块调用的机会就少。（其实这是高内聚的一种说法，高内聚低耦合一般同时出现，为了限制篇幅，我们将在以后的版期中讨论）。
3、遵循一个定义只在一个地方出现。
4、少使用全局变量。
5、类属性和方法的声明少用public，多用private关键字，
6、多用设计模式，比如采用MVC的设计模式就可以降低界面与业务逻辑的耦合度。
7、尽量不用“硬编码”的方式写程序，同时也尽量避免直接用SQL语句操作数据库。
8、最后当然就是避免直接操作或调用其它模块或类（内容耦合）；如果模块间必须存在耦
合，原则上尽量使用数据耦合，少用控制耦合，
限制公共耦合的范围，避免使用内容耦合。
内聚：故名思议，表示内部间聚集、关联的长度，那么高内聚就是指要高度的聚集和关联。
高内聚:
类与类之间的关系而定，高，意思是他们之间的关系要简单，明了，不要有很强的
关系，不然，运行起来就会出问题。一个类的运行影响到其他的类。由于高内聚具备鲁棒性，可靠性，可重用性，可读性等优点，模块设计推荐采用高内聚。这是软件工程中的概念，是判断设计好坏的标准，主要是面向OO的设计，主要是看类的内聚性是否高，偶合度是否低“高内聚，低耦合”，首先要知道一个软件是由多个子程序组装而成，而一个程序由多个模块(方法)构成!“高内聚，低耦合”主要是阐述的面向对象系统中，各个类需要职责分离的思想。
每一个类完成特定的独立的功能，这个就是高内聚。耦合就是类之间的互相调用关系，如果耦合很强，互相牵扯调用很多，那么会牵一发而动全身，不利于维护和扩展。类之间的设置应该要低耦合，但是每个类应该要高内聚。耦合是类之间相互依赖的尺度。如果每个对象都有引用其它所有的对象，那么就有高耦合，这是不合乎要求的，因为在两个对象之间，潜在性地流动了太多信息。
低耦合是合乎要求的：它意味着对象彼此之间更独立的工作。低耦合最小化了修改一个类而导致也要修改其它类的"连锁反应"。内聚是一个类中变量与方法连接强度的尺度。
高内聚是值得要的：因为它意味着类可以更好地执行一项工作。低内聚是不好的，因为它表明类中的元素之间很少相关。成分之间相互有关联的模块是合乎要求的。每个方法也应该高内聚。大多数的方法只执行一个功能。不要在方法中添加'额外'的指令，这样会导致方法执行更多的函数。
推广开来说，这个思想并不限于类与类之间的关系。模块和模块，子系统之间也都要遵守这个原则，才可以设计出延展性比较强的系统。
目录 1接口类型 (2) 1.1人机接口 (2) 1.2软件-硬件接口 (2) 1.3软件接口 (2) 1.4通信接口 (2) 2接口设计规范 (2) 2.1基本内容 (2) 2.2规格说明 (3) 2.2.1人机接口 (3) 2.2.2软件-硬件接口 (3) 2.2.3软件接口 (3) 2.2.4通信接口 (3) 3接口设计文档提纲 (3)
1接口类型 1.1人机接口 人机接口是指计算机系统为完成人与机器之间互相传送信息而提供的功能的接口，包括硬件及程序。 1.2软件-硬件接口 软件-硬件接口是指软件系统中软件与硬件之间的接口。例如软件与接口设备之间的接口。 1.3软件接口 软件接口是软件系统中程序之间的接口。包括软件系统与其他系统或子系统之间的接口、程序模块之间的接口、程序单元之间的接口等。 1.4通信接口 通信接口是指处理机和标准通信子系统之间的接口。包括为实现数据通信用来完成接口功能的部件、装置及有关软件。 2接口设计规范 2.1基本内容 1、接口的名称标识 2、接口在该软件系统中的地位和作用 3、接口在该软件系统中与其他程序模块和接口之间的关系 4、接口的功能定义 5、接口的规格和技术要求，包括它们各自适用的标准、协议或约定 6、各个接口的数据特性 7、各个接口的资源要求，包括硬件支持、存储资源分配等 8、接口程序的数据处理要求
9、接口的特殊设计要求 10、接口对程序编制的要求 2.2规格说明 2.2.1人机接口 准确地说明人机接口的设计条件、设计特征、编程要求等技术内容。包括人机交互环境、人机接口部件、信息传输方式及传输特性、信息格式、数据处理、存储资源分配和程序编制要求等。 2.2.2软件-硬件接口 逐个描述每一个软件-硬件间接口的设计特性。包括接口硬件说明、接口功能说明、接口信息说明、接口处理方法、接口控制方式、接口时间特性、存储资源分配和程序编制要求等。 2.2.3软件接口 逐个说明本软件系统与其他软件系统间接口的设计特征。包括接口功能说明、接口约定、数据特性、数据处理方法、接口程序运行控制、接口时间特性、存储资源分配和程序编制要求等。 2.2.4通信接口 逐个描述各个通信接口的设计特性。包括硬件描述、接口功能说明、通信协议、报文处理、存储资源分配、程序接口设计和程序编制要求等。 3接口设计文档提纲 1概述........................................................................................................................................................... 错误！未定义书签。 1.1编写目的......................................................................................................................................... 错误！未定义书签。 1.2参考资料......................................................................................................................................... 错误！未定义书签。 1.3术语和缩写词................................................................................................................................ 错误！未定义书签。2软件系统综述......................................................................................................................................... 错误！未定义书签。3接口设计.................................................................................................................................................. 错误！未定义书签。 3.1接口框图......................................................................................................................................... 错误！未定义书签。 3.2接口一览表.................................................................................................................................... 错误！未定义书签。 3.3人机接口......................................................................................................................................... 错误！未定义书签。 3.4软件-硬件接口 .............................................................................................................................. 错误！未定义书签。
公共设施设计的原则 目录 ?（一）易用性原则 ?（二）安全性原则 ?（三）系统性原则 ?（四）审美性原则 ?（五）独特性原则 ?（六）公平性原则 ?（七）合理性原则 ?（八）环保性原则 （一）易用性原则 “一个商品售货员将饼干扔在你的脚下，而你不得不弯下腰将摔碎的商品捡起——毫无疑问，这种情况下，你十之八九会非常生气并将你的愤怒表达出来，但自动售货机这样做的时候，…..。”很明显，很多具有明确产品属性的公共设施设计缺乏“可以被人容易和有效使用的能力。”我们有时不得不在自动取款机前等待前面的老人一遍有一遍的重复错误操作，而无法施以援手。这就是公共设施缺乏易用性所造成的困扰。易用性（Usability）通俗的讲就是指“（产品）是否好用或有多么好用”。它是就有明确使用功能的公共设施设计时必须考虑的原则性问题，比如垃圾桶开口的设计就既要考虑到防水功能，又不能因此使垃圾投掷产生困难，或是人们在使用自动取款机时，如何可以不再使用容易忘记的密码确认方式，如何可以在操作完成后记得取回银行卡。这些都是公共设施设计时应该考虑的易用性原则。 （二）安全性原则 笔者曾在公共设施设计专题课程中向学生提问过这样一个问题：“如果儿童在广场中玩耍时不慎被某些公共设施所伤害（如公共座椅的金属扶手、公共电话亭侧面挡板边沿），那么，这种意外伤害的责任较多的应归咎于设计者，还是使用者（这里特指儿童）呢？”多数学生认为责任应是儿童的玩耍调皮或父母缺少看护造成，只有少数学生认为是设计师的设计疏漏所引起的，笔者赞同少数学生的观点。作为设置与公共环境中的公共设施，设计时必须考虑到参与者与使用者可能在使用过程中出现的任何行为，儿童的天性就是玩耍嬉闹，这是不能改变的，而能改变的是以儿童身高作为一个尺度，低于此高度的公共设施均应考虑到其材料、结构、工艺及形态的安全性，在设计伊始便尽量避免对使用者所造成的安全隐患，这就是公共设施设计的安全性原则。 （三）系统性原则 通常情况下，在公共休息区内，或在公共座椅的周围应设置垃圾桶，而垃圾桶的数量应于公共座椅的数量向匹配，太多会造成浪费，而太少则会诱使随意丢弃垃圾的行为。可见，公共座椅与垃圾桶之间存在着某种匹配关系。再如健身设施周围相对集中的公共照明设施，便起
原因是我们在使用这两种设备时的观看距离不同，桌面端我们的眼睛离屏幕较远，而在移动端则相反，因此我们应该在移动端使用较小的字号反差。
栅格系统 小屏幕上，一些桌面端无关大雅的间距不等问题会变得突出。 Lofter是网易一款精品优雅的App，但其文章正文界面却略有瑕疵： 可以看到段落右侧与卡片的间距明显大于左侧。造成这个问题的原因是设计时对文本框的宽度与文字大小之间在关系考虑不周全，导致文字并不能完美地填充满文本框。
上图为iPhone5中此界面的放大效果并加上了辅助线，仔细观察，去除黄色部分各20px的间距后，文本框宽度是558px，而正文使用的字号是30px，所以行末留下18px的空余空间。如果字号定 为31px，则刚好可以放下18个字后填满558px像素的文本框。 当然31px的字号在实际环境中可能并不是一个最合理的字号设定，因为它并不能被整除使用到@1x 的iOS开发环境。在实际设计中，可以先设定一个栅格系统，以iPhone5为例，定义最小栅格 为8x8px的话，得到如下一个栅格图：
以8为基本单位，把所有字号、文本框宽度设定为8的倍数，这样我们就可以确保汉字始终保持对齐。 对齐 “…所有的元素都是正方體。但是從二十世紀開始使用標點後，到了現代桌上出版時代，許多排版工具軟體都直接套用來自日本的「禁則處理」—即避頭尾點；加上與西方文字混排的狀況越來越多，以至於無法做到縱橫對齊的基礎。但是至少段落的頭尾還是需要對齊。這就是為什麼對齊對電子書與長文章來說十分重要的原因。” ——董福興《簡單做好中文排版》 在英文的段落排版中，通常是左侧对齐，而让右侧自然形成起伏边（rag）。对中文排版与阅读习惯而言则相反，段落的头尾对齐尤其重要。 先来看一个反例：
《基础工程》课程设计 ——某办公楼桩基础设计 一：设计资料 1、建筑场地土层按其成因土的特征和力学性质的不同自上而下划分为四层，物理力学指标见下表。地下水位在地面以下 2.0m ，地下水水质分析结果表明，本场地下水无腐蚀性。 建筑安全等级为Ⅱ级，已知作用到基础顶面处的柱荷载： 轴向力kN F K 2850=，力矩m kN M ?=0.395，水平力kN H 42=。 2、根据地基条件和施工设备，采用钢筋混凝土预制桩，以黄土粉质粘土为桩 尖持力层。 钢筋混凝土预制桩断面尺寸为400mm ×400mm 。桩长根据地质勘察资料和《规 范》知一般应选择硬土层作为桩端持力层故确定第3层粘土为桩端持力层。查《规范》和经验知：桩顶嵌入承台0.1m 。由题目要求知采用钢筋混凝土预制桩，故由经验选择选择桩截面为方桩，为400mm ×400mm ，桩长至少为2m+9m+0.1m=11.1m 查规范知桩端嵌入持力层为5d-10d 故选择5d ，所以桩长为11.1+5x0.4=13.1m 故选择桩长为13m 。有《规范》知承台埋深一般为1-2米，选承台埋深为D=2m ，桩端进持力层2m 。初步确定承台尺寸为2×2m 。 3、桩身混凝土强度为C35，所以，轴心抗压强度设计值 f c ＝ 16.7MPa ，弯曲强度设计值为f m ＝19MPa ，主筋采用：4Φ18，强度设计值： f y ＝310MPa 4、承台混凝土强度为C30。轴心抗压强度设计值为 f c ＝14.3MPa ，弯曲抗压强度设计值为 f m ＝16.5MPa 。 设计要求： 1、单桩竖向承载力标准值和设计值的计算； 2、确定桩数和桩的平面布置图； 3、群桩中基桩的受力验算 4、承台结构设计及验算； 5、桩及承台的施工图设计：包括桩的平面布置图，桩身配筋图， 承台配筋和必要的施工说明； 6、需要提交的报告：计算说明书和桩基础施工图。
服务端与手机平台 接口协议 BespRout 2014年11月
文档修改/审批记录
目录 1.概述 (4) 2.涉及接口 (4) 3.接口总体要求 (4) 3.1.系统间接口的原则 (4) 3.2.处理流程 (4) 3.3.接口实现方式 (5) 4.XXX服务端接口 (5) 4.1.XX模块-根据XX下载相关的配置文件 (5) 4.2.XX模块-生成指定XX的文件配置 (6) 4.3.APP启动-初使化参数 (7) 5.附件 (8) 5.1.备注说明 (8)
1. 概述 本文档提供接口给手机端使用，为手机端提供业务平台数据 2. 涉及接口 本文档涉及的外围系统接口包括：无 3. 接口总体要求 3.1.系统间接口的原则 接口设计遵循如下原则： ?安全可靠性原则：系统应提供良好的安全性和可靠性策略，支持多种安全而 可靠的技术手段，制定严格的安全可靠的管理措施； ?开放性原则：提供开放式标准接口，提供与其它系统的互联互通； ?灵活性原则：提供灵活的接口设计，便于接口的变动。 ?可扩展性原则：支持新业务的扩展以及接口容量与接口性能的提高； ?可管理性原则：提供良好的管理机制，保证在运行过程中提供给管理员方便 的管理方式以处理各种情况； ?统一性原则：应当保证系统的接口方式、接口形式、使用的协议等标准、统 一。 3.2.处理流程 接口处理流程
3.3. 接口实现方式 手机APP 应用 与服务端采用基于HTTP 的REST 协议完成，数据传输默认为JSON 4. XXX 服务端接口 测试地址前缀: http://192.168.3.208:8088/xxx/xxx 4.1. XX 模块-根据XX 下载相关的配置文件
设计模式六大设计原则 单一职责原则(Single Responsibility Principle-SRP) 理解：对于一个类而言，应该仅有一个引起它变化的原因。说白了就是，不同的类具备不同的职责，各施其责。这就好比一个团队，大家分工协作，互不影响，各做各的事情。 应用：当我们做系统设计时，如果发现有一个类拥有了两种的职责，那就问自己一个问题：可以将这个类分成两个类吗？如果真的有必要，那就分吧。千万不要让一个类干的事情太多！开放封闭原则(open closed principle-OCP) 理解：简言之，对扩展开放，对修改封闭。换句话说，可以去扩展类，但不要去修改类。应用：当需求有改动，要修改代码了，此时您要做的是，尽量用继承或组合的方式来扩展类的功能，而不是直接修改类的代码。当然，如果能够确保对整体架构不会产生任何影响，那么也没必要搞得那么复杂了，直接改这个类吧。 里氏替换原则(liskov substitution principle -LSP) 理解：父类能够替换子类，但子类不一定能替换父类。也就是说，在代码中可以将父类全部替换为子类，程序不会报错，也不会在运行时出现任何异常，但反过来却不一定成立。 应用：在继承类时，务必重写（Override）父类中所有的方法，尤其需要注意父类的protected 方法（它们往往是让您重写的），子类尽量不要暴露自己的public 方法供外界调用。 最少知识原则(last knowledge principle-LKP) 理解：尽量减少对象之间的交互，从而减小类之间的耦合。简言之，一定要做到：低耦合，高内聚。 应用：在做系统设计时，不要让一个类依赖于太多的其他类，需尽量减小依赖关系，否则，您死都不知道自己怎么死的。 接口隔离原则(Interface Segregation Principle - ISP) 理解：不要对外暴露没有实际意义的接口。也就是说，接口是给别人调用的，那就不要去为难别人了，尽可能保证接口的实用性吧。她好，我也好。 应用：当需要对外暴露接口时，需要再三斟酌，如果真的没有必要对外提供的，就删了吧。一旦您提供了，就意味着，您将来要多做一件事情，何苦要给自己找事做呢。 依赖倒置原则(Dependence Inversion Principle – DIP) 理解：应该面向接口编程，不应该面向实现类编程。面向实现类编程，相当于就是论事，那是正向依赖（正常人思维）；面向接口编程，相当于通过事物表象来看本质，那是反向依赖，即依赖倒置（程序员思维）。 应用：并不是说，所有的类都要有一个对应的接口，而是说，如果有接口，那就尽量使用接口来编程吧。
工艺设计的基本原则和程序 一、工艺设计的基本原则 水泥厂工艺设计的基本原则可归纳如下： (1)根据计划任务书规定的产品品种、质量、产量要求进行设计。 计划任务书规定的产品产量往往有一定范围，设计产量在该范围之内或略超出该范围，都应认为是合适的；但如限于设备选型，设计达到的产量略低干该范围，则应提出报告，说明原因，取得上级同意后，按此继续设计。 对于产品品种，如果设计考虑认为计划任务书的规定在技术上和经济上有不适当之处，也应提出报告，阐明理由，建议调整，并取得上级的同意。例如，某大型水泥厂计划任务书要求生产少量特种水泥，设计单位经过论证，认为大型窑改变生产品种，在技术上和经济上均不合理，建议将少量特种水泥安排给某中小型水泥厂生产，经上级批准后，改变了要求的品种。 窑、磨等主机的产量，除了参考设备说明和经验公式计算以外，还应根据国内同类型主机的生产数据并参考国内外近似规格的主机产量进行标定。在工厂建成后的较短时期内，主机应能达到标定的产量；同时，标定的主机产量应符合优质、高产、低消耗和设备长期安全运转的要求，既要发挥设备能力，但又不能过分追求强化操作。 (2)选择技术先进、经济合理的工艺流程和设备。 工厂的工艺流程和主要设备确定以后，整个工厂设计可谓大局已定。工厂建成后，再想改变其工艺流程和主要设备，将是十分困难的。例如，要把湿法厂改为干法厂，固然困难；要把旧干法厂改为新型干法厂，也非易事。例如，为了利用窑尾废气余热来烘干原料，生料磨系统也得迁移，输送设备等也得重新建设，诸如此类的情况，在某些条件下就不一定可行。 在选择生产工艺流程和设备时，应尽量考虑节省能源，采用国内较成熟的先进经验和先进技术；
设计移动端报表， 你不得不知道的五个原则 随着移动互联的飞速发展，手机成为人们工作、生活中必不可少的工具，移动端报表被越来越多的企业所重视。数字化转型过程中，企业总少不了对移动端报表的需求。 数钥分析云，除了支持PC端、大屏，也支持移动端查看，可以快速集成到企业微信、钉钉、致远M3中，让用户随时随地查看报表，实时掌握企业数据，辅助企业经营。 我们在搭建或规划移动端报表时，常常会遇到一些问题： ?手机屏幕小，如何呈现核心业务指标？ ?布局固化，想要更多的布局交互模式… ?视觉效果不好，追求“高颜值”移动报表… ?指标太粗，看不出问题出在哪… ?指标太细，又看不到整体情况… 其实，我们仔细看这些问题，无非就是两点： 1、美观的需求：充分结合移动端的特点和产品优势，进行合理布局，凸显关键指标信息，合理美化，提高报表的美观度； 2、业务的需求：除了精美的外表外，更重要的是把控业务需求，在有限的屏幕范围内，呈现核心指标，指标粗细结合，全面展现业务状态。 所以，在做移动端报表时，我们要综合移动端特点、业务诉求和分析云产品优势，做出一张符合需求的移动端报表。
设计移动端报表原则： 1、基本元素，简单明了 移动端报表，主要以图表呈现，图形在信息的传递上具有更好的呈现效果。所以，合理使用图表，达到信息传递的效果。分析云移动端支持表格、柱状图、折线图、饼图、仪表盘…等各种图形，能够满足用户分析需求。 2核心数据，一目了然 1、移动端报表，最核心的元素置顶呈现，可以采用指标呈现，数字的表达更加醒目、简洁，且占用空间少，是最直接展示方式。
2、可以通过设置前景色、背景色的变化实现预警，让异常指标展现更加一目了然。 3、尽量在一屏内展现完整数据，减少滚屏的出现，如果表格较大，展示的数据较多，分析云也支持锁定前N列功能或横屏查看，保障用户清晰的看到数据内容。 3、布局清晰，条理性强 与PC端报表不同，移动端报表的呈现形式主要是竖排展现。想要更多的布局交互模式，那就少不了分析云的分段器。 分析云的分段器，可以帮助用户快速实现视图的切换，满足沉浸式阅读需求，大大方便了用户的应用。
施工组织设计的基本原则 ①配套投产,根据建设项目的生产工艺流程、投产先后顺序,都要服从施工组织总设计的规划和安排。安排各单位工程开竣工期限，满足配套投产； ②确定重点,保证进度； ③建设总进度一定要留有适当的余地; ④重视施工准备,有预见地把各项准备工作做在工程开工的前头； ⑤选择有效的施工方法,优先采用新技术、新工艺，确保工程质量和生产安全; ⑥充分利用正式工程,节省暂设工程的开支； ⑦施工总平面图的总体布置和施工组织总设计规划应协调一致、互为补充。 施工组织设计一般分为三个阶段: 1、施工条件设计(或称施工组织基本概况); 2、施工组织总设计； ３、各个建筑物等单位工程的施工设计。 施工组织设计目录 一、编制说明 二、编制依据 三、工程概况 1、工程名称及规模
２、工程范围及内容 3、建筑与结构 4、电气工程 5、给排水工程 ６、采暖工程 ７、材料做法 8、工期要求 ９、质量要求 10、安全及环保要求 1１、自然条件 12、施工条件 13、相关单位 二、施工总体组织及规划１、总体主导思路 2、项目管理组织 ３、施工队伍部署及任务划分4、施工准备 ５、各部门职责 6、施工总平面布置 7、总体施工组织方案 ８、施工工期目标规划 9、工程质量目标规划
10、安全、文明施工与环保目标规划 三、施工进度计划安排 1、总工期计划安排 ２、工程项目阶段性目标计划 ３、施工进度计划横道图 四、劳动力计划安排 五、主要施工机械设备配备 六、主要材料（设备)供应进度计划 七、主要分部、分项工程施工方法技术及措施 1、施工测量 2、基坑(槽)土方开挖与回填 ３、基础工程施工 4、模板工程 5 、钢筋工程 ６、砼工程 ７、砖砌体工程施工 8、室内墙面、天棚装修 9、窗安装 10、普通地砖地面 11、外墙外保温 1２、脚手架工程 １３、屋面防水施工
最近一段时间一直在做APP接口，总结一下APP接口开发过程中的注意事项： 1、效率：接口访问速度 APP有别于WEB服务，对服务器端要求是比较严格的，在移动端有限的带宽条件下，要求接 口响应速度要快，所有在开发过程中尽量选择效率高的框架，PHP建议使用YAF框架。 2、数据格式 最好使用JSON格式数据，因为JSON有较好的跨平台性。对于 3、数据量 按需分配，APP客户端需要什么数据就返回什么数据，过多的数据量影响处理速度，最重要的 是影响传输效率。 4、接口、参数命名准确 无论是接口还是参数，命名都应该有意义，让人一目了然。 5、一个页面尽可能就用一个接口 现在很多的APP页面都有广告、焦点图、文章列表等，对于这些不同格式的数据，不可能都分 配一个接口，这样加大了APP请求接口数，影响响应速度。建议服务器端尽可能处理好数据后 通过一个接口返回给APP客户端。 6、缓存 这点比较重要，不管是文件缓存还是memcache缓存。 7、接口要有可扩展性 8、接口安全 目前一般都是在APP客户端和服务器通过约定的算法，对传递的参数值进行验证匹配。但是如 果APP程序被反编译，这些约定的算法就会暴露，特别是在安卓APP中，有了算法，完全就 可以通过验证模拟接口请求。 9、接口版本控制 对于接口版本控制，自己目前也没有找到一个好的方法，怎么去应对不断的APP版本升级，新、旧接口的处理。 10、接口数据、状态 接口必须提供明确的数据状态信息，不管是成功的，还是失败的，都必须返回给APP客户端。 以上10点就是自己在这端时间做APP接口过程中注意的事项，写的有点乱，想到什么就写什么。
保持用户的劳动付出。 智能有爱：给用户提供让他感到惊喜有趣的、智能高效的、贴心的设计。 一、内容优先 对于手机而言，屏幕空间资源显得非常珍贵。为了提升屏幕空间的利用率，界面布局应以内容为核心，而提供符合用户期望的内容是移动应用获得成功的关键。如何设计和组织内容，使用户能快速理解移动应用所提供的内容，使内容真正有意义，这是非常重要的。 重组内容，使内容符合移动的特征 在PC上的网页内容往往相对复杂，在进行内容移动化时，并不合适把内容直接照搬到手机端。在进行移动应用设计时，应该重组内容，使其符合移动应用的特征。 移动应用的内容应使用用户的语言，以用户熟悉的维度来组织内容，这样更容易查找目标信息，提升内容的利用率；删除无关的多余内容，让内容更简洁清晰，考虑在小屏幕空间可以合理的布局，增加屏幕的利用率；内容要是清晰和具体的，是用户恰好需要的；内容要是有情景特征的，可以在不同的情景下给用户提供不同的情景下的内容。 优先突出用户需要的信息，而简化界面的导航 一个应用提供给用户的信息往往是太多而不是太少，设计师们的关注重点也会转移到如何让用户找到内容，而忽略了能给用户获得价值的是内容，而不是导航。 在移动应用设计时，我们更为关注的是用户需要的内容，其次才是导航。在内容本身复杂而多变的时候，如何让用户能更快速地获取恰当的信息，在移动情景中会显得很重要。 适时提升屏幕空间的利用率 即使用户的视觉注意点集中在内容上，在设计方面也要把屏幕资源更多的给内容而不是导航。只是在恰当的时候，可以让用户呼出导航即可。 二、为触摸而设计 点击操作是PC 时代交互的基础，在触屏设备上基于手指的手势操作已经代替了鼠标的点击操作。手势操作灵活多变、交互自然，但也带来识别性差、操作精度不高等缺点，都需要一些手势设计的基本原则来指导和完善。 以信息架构为基础，建立手势交互规范 在一个移动应用中，手势的统一性非常重要。让用户在应用的任何界面中都知道怎么使用手势，并
施工组织设计的基本原则 ①配套投产，根据建设项目的生产工艺流程、投产先后顺序，都要服从施工组织总设计的规划和安排。安排各单位工程开竣工期限，满足配套投产； ②确定重点，保证进度； ③建设总进度一定要留有适当的余地; ④重视施工准备，有预见地把各项准备工作做在工程开工的前头； ⑤选择有效的施工方法，优先采用新技术、新工艺，确保工程质量和生产安全； ⑥充分利用正式工程，节省暂设工程的开支； ⑦施工总平面图的总体布置和施工组织总设计规划应协调一致、互为补充。 施工组织设计一般分为三个阶段： 1、施工条件设计(或称施工组织基本概况)； 2、施工组织总设计； 3、各个建筑物等单位工程的施工设计。 施工组织设计目录 一、编制说明 二、编制依据 三、工程概况 1、工程名称及规模
2、工程范围及内容 3、建筑与结构 4、电气工程 5、给排水工程 6、采暖工程 7、材料做法 8、工期要求 9、质量要求 10、安全及环保要求 11、自然条件 12、施工条件 13、相关单位 二、施工总体组织及规划 1、总体主导思路 2、项目管理组织 3、施工队伍部署及任务划分 4、施工准备 5、各部门职责 6、施工总平面布置 7、总体施工组织方案 8、施工工期目标规划 9、工程质量目标规划
10、安全、文明施工与环保目标规划 三、施工进度计划安排 1、总工期计划安排 2、工程项目阶段性目标计划 3、施工进度计划横道图 四、劳动力计划安排 五、主要施工机械设备配备 六、主要材料(设备)供应进度计划 七、主要分部、分项工程施工方法技术及措施 1、施工测量 2、基坑（槽）土方开挖与回填 3、基础工程施工 4、模板工程 5 、钢筋工程 6、砼工程 7、砖砌体工程施工 8、室内墙面、天棚装修 9、窗安装 10、普通地砖地面 11、外墙外保温 12 、脚手架工程 13、屋面防水施工
接口与接口设计原则 一．11种设计原则 1.单一职责原则 - Single Responsibility Principle(SRP) 就一个类而言，应该仅有一个引起它变化的原因。职责即为“变化的原因”。 2.开放-封闭原则 - Open Close Principle(OCP) 软件实体（类、模块、函数等）应该是可以扩展的，但是不可修改。对于扩展是开放的,对于更改是封闭的. 关键是抽象.将一个功能的通用部分和实现细节部分清晰的分离开来。开发人员应该仅仅对程序中呈现出频繁变化的那些部分作出抽象. 拒绝不成熟的抽象和抽象本身一样重要 ) 3.里氏替换原则 - Liskov Substitution Principle(LSP) 子类型(subclass)必须能够替换掉它们的基类型(superclass)。 4.依赖倒置原则(IoCP) 或依赖注入原则 - Dependence Inversion Principle(DIP)
抽象不应该依赖于细节。细节应该依赖于抽象。Hollywood原则: "Don't call us, we'll call you". 程序中所有的依赖关系都应该终止于抽象类和接口。针对接口而非实现编程。任何变量都不应该持有一个指向具体类的指针或引用。任何类都不应该从具体类派生。任何方法都不应该覆写他的任何基类中的已经实现了的方法。 5.接口隔离原则(ISP) 不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。多个面向特定用户的接口胜于一个通用接口。 6.重用发布等价原则(REP) 重用的粒度就是发布的粒度。 7.共同封闭原则(CCP) 包(类库、DLL)中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包产生影响，则将对该包中的所有类产生影响，而对于其他的包不造成任何影响。 8.共同重用原则(CRP) 一个包(类库、DLL)中的所有类应该是共同重用的。 如果重用了包(类库、DLL)中的一个类，
公共设施设计 《浅谈长沙王陵公园公共设施设计》 班级： 姓名： 学号： 指导老师：
目录 一、公共设施设计概述 二、公共设施设计方法及原理 三、公共设施设计发展趋势 四、公共设施设计案例调查与分析 王陵公园——考查与分析 ——后期改造
一．公共设施设计概述 （一）公共设施的含义： 公共设施是指城市、社区等公共空间的基本服务性功能设备，是现代城市发展而产生的融工业与环境设计于一体的新型的环境设计产品，是现代城市不可缺少的基本构成要素。 公共设施是指为市民提供公共服务产品的各种公共性、服务性设施，按照具体的项目特点可分为教育、医疗卫生、文化娱乐、交通、体育、社会福利与保障、行政管理与社区服务、邮政电信和商业金融服务等。 （二）公共设施设计的意义： 公共设施是给予公众提供生活、交流、工作和学习必不可少的公共服务设施，同时具有美化环境和改善环境作用，是体现城市人文关怀的基本“标尺”，是展示现代城市文明的重用标志之一。 （三）公共设施的发展概况： 工业革命以前,公共设施品种少，功能单纯。随着城市及工业技术的发展，公共设施的品种逐渐丰富起来，功能服务也开始从单一化向多功能化发展。二十世纪电脑技术和网络技术的出现，使公共设施更具有了智能化的服务功能，从而大幅度降低了服务成本，并使人们的生活变得更为方便和舒适。 （四）公共设施设计的范畴： 包括政治（如检阅台及检阅广场）、经济（如交易市场）、文化（如剧院）及公众日常活动等方面的公共配套需求设备都属于公共设施设计的范畴。（五）公共设施的基本要求与特点： 公众化、安全性、美化性、坚固性、耐候性、实用性、舒适性和醒目化。（六）公共设施的艺术化与景观化： 公共环境空间中设施除了应具有实用性和功能性以外，还扮演着美化环境的重要角色，因此将公共设施艺术化与景观化是对公共设施设计与制造的基本要求。 （七）公共设施的人性化设计： 公众不仅可以使用设施的功能来满足其需求，还能参与设施所能赋予的某种特殊的活动，从而产生精神上的愉悦和快感，即所谓“人机互动”。 （八）公共设施所属系统分类： 公共交通系统：交通警示、路障、公交站台、停车场、车站、收费站、加 油站、自行车停放点、警亭、人行护栏等。 公共卫生系统：垃圾桶、垃圾房、垃圾处理站、公厕、洗手饮水池、痰 盂等。 公共照明系统：公路照明灯、泛光灯、嵌地灯、射灯、庭院灯等。 公共信息系统：电话亭、邮筒、电子信息屏、导示牌、广告牌、告示牌等。 公共休息系统：休息亭、休闲廊架、休息桌椅。 公共活动系统：健身设施、跑道、游泳池、露天舞场、球场、儿童游乐 设施。
【总结】移动应用界面设计的尺寸设置及规范 时间2014-05-04 15:15:07 青溪·札记 原文appdesign-sizesetting/ 主题用户界面设计移动应用 刚接触移动应用的界面设计，最先跳入脑海的疑问是：画布尺寸设计多大（特别是Android）、图标和字体大小怎么定、需要设计多套设计稿么、如何切图以配合开发的实现？ 本篇将结合iOS和android官方的设计规范、搜集的资料以及工作中的摸索，来分享移动应用界面设计中的尺寸规范等问题，希望能给移动端的新手设计师些许指引。若有不当之处，欢迎斧正。 一、android篇 1、android分辨率 Android的多分辨率，一向是设计师和开发者非常头疼的事儿。尽管如此，对于多分辨造成的复杂问题，也是大家要优先解决的。Android支持多种不同的dpi 模式：ldpi 、mdpi 、hdpi 、xhdpi 、xxhdpi 、xxxhdpi 注意，ppi、dpi 是密度单位，不是度量单位： * ppi (pixels per inch)：图像分辨率（在图像中，每英寸所包含的像素数目） * dpi (dots per inch)：打印分辨率（每英寸所能打印的点数，即打印精度） dpi主要应用于输出，重点是打印设备上；ppi对于设计师应该比较熟悉，photoshop画布的分辨率常设置为72像素/英寸，这个单位其实就是ppi 。尽管概念不同，但是对于移动设备的显示屏，可以看作ppi=dpi 。 ppi的运算方式是：PPI = √（长度像素数2 + 宽度像素数2） / 屏幕对角线英寸数。即：长、宽各自平方之和的开方，再除以屏幕对角线的英寸数。 以iphone5为例，其ppi=√（1136px2 + 640px2）/4 in=326ppi（视网膜Retina屏） 对于android手机，一个不确切的分法是，720 x 1280 的手机很可能接近 320 dpi （xhdpi模式），480 x 800 的手机很可能接近 240 dpi （hdpi模式），而320 x 480 的手机则很接近 160 dpi（mdpi模式）。
第三章工艺流程设计 第一节概述 工艺流程设计和车间布置设计是工艺设计的两个主要内容，是决定工厂的工艺计算、车间组成、生产设备及其布置的关键步骤。 生产工艺流程设计在整个工艺设计中最先开始，但随着工艺及其他专业设计的展开，通常需要对初步的工艺流程设计进行局部修改，所以几乎是最后才完成。 生产工艺流程设计的主要任务包括两个方面：其一是确定由原料到成品的各个生产过程及顺序，即说明生产过程中物料和能量发生的变化及流向，应用了哪些生物反应或化工过程及设备。其二是绘制工艺流程图。 在发酵生产过程中，原料往往不是直接变成产品，而是通过一系列的半成品或中间产品再变成成品，同时还有副产品和废液、废渣等生成，“三废”必须严格治理。 因为工艺流程设计是最关键的设计，与其他专业设计息息相关，所以需要由浅人深和分阶段进行。同时必须经过反复推敲，精心安排和计算，不断修改和完善，才能完成设计任务。 生产工艺流程的设计往往经历三个阶段，即：生产工艺流程示意图、生产工艺流程草图、生产工艺流程图。 具体地说，生产方法和生产规模确定后就可以开展设计生产工艺流程示意图。工艺流程示意图作出后，就可以进行物料衡算和能量衡算以及部分设备计算和选型。待设备设计全部完成后，再修改、充实工艺流程草图，根据流程草图和设备设计进行车间布置设计。根据车间布置图再来修改工艺流程草图，最后得出生产工艺流程图。 当然上面介绍的示意图、草图、流程图的设计程序并非一成不变，还需根据设计项目的难度、技术的成熟程度、设计人员水平及实践经验等多方面因素决定。若设计人员经验丰富，而且是难度不大、技术成熟的项目，甚至可以一次完成生产工艺流程图的设计。 第二节生产方法的选择和工艺流程的设计原则 生产工艺流程设计是整个工艺设计的基础，工艺流程图是指导施工的重要图纸。通常，生产方法的选择和工艺流程设计，是决定设计成败的关键工作。 一、生产方法的选择 生产方法即工艺路线的选择，是生物工程工厂设计的关键步骤。一般要对可选择的各种生产方法进行全面的比较分析，从中选出技术先进、经济合理的工艺路线，以保证项目投产后能达到高产、低耗、优质和安全运转。 以发酵工厂为例，介绍选择生产方法的主要依据。 1．原料来源、种类和性质 如需应用进口原料如啤酒生产的麦芽，则必须采取先进的生产方法和技术，以保证生产出高质量的产品，供出口或内销。原料的种类和性质不同，则生产方法也要相应改变。对酒精生产，采用糖蜜或淀粉作原料，则工艺路线就大不相同。即便是淀粉质原料，也有谷类、薯类原料和野生植物淀粉质原料之分，其工艺流程也有一定差异。 2.产品的质量和规格 糖蜜原料发酵生产三级酒精，可采用两塔式液相过塔蒸馏流程；若生产一级或优级酒精，则必须采用三塔式或多塔式流程。又如啤酒生产中，淡色啤酒或浓色啤酒的糖化、煮沸工艺就不相同。 3．生产规模 工厂的设计生产能力对工艺流程的选择也有影响。生产规模较小时，可采用分批发酵法；对于大型企业，则采用连续发酵工艺有利于生产过程的机械化、自动化和稳产高产的实现。 4.技术水平 生产方法的选择也必须考虑技术水平。如酒精生产，连续发酵技术要求较高的操作技术，而间歇生产则较易掌握。又如味精生产，应用糖蜜原料发酵谷氨酸的方法，具有产酸高、经济效益好的优点，但对菌种和生产技术水平要求严格。所以生产工艺既要考虑先进性，又要保证切实可行。
软件设计的七大原则 设计模式遵循的一般原则： 1.开-闭原则(Open-Closed Principle, OCP):一个软件实体应当对扩展开发,对修改关闭.说的是,再设计一个模块的时候,应当使这个模块可以在不被修改的前提下被扩展.换言之,应当可以在不必修改源代码的情况下改变这个模块的行为，在保持系统一定稳定性的基础上，对系统进行扩展。这是面向对象设计（OOD）的基石，也是最重要的原则。 2.里氏代换原则(Liskov Substitution Principle,常缩写为.LSP) (1).由Barbar Liskov(芭芭拉.里氏)提出，是继承复用的基石。 (2).严格表达:如果每一个类型为T1的对象o1,都有类型为T2的对象o2,使得以T1定义的所有程序P在所有的对象o1都代换称o2时,程序P的行为没有变化,那么类型T2是类型T1的子类型. 换言之,一个软件实体如果使用的是一个基类的话,那么一定适用于其子类,而且它根本不能察觉出基类对象和子类对象的区别.只有衍生类可以替换基类，软件单位的功能才能不受影响，基类才能真正被复用，而衍生类也能够在基类的基础上增加新功能。
(3).反过来的代换不成立 (4).<墨子.小取>中说:"白马,马也; 乘白马,乘马也.骊马(黑马),马也;乘骊马,乘马也." (5).该类西方著名的例程为:正方形是否是长方形的子类(答案是"否")。类似的还有椭圆和圆的关系。(6).应当尽量从抽象类继承,而不从具体类继承,一般而言,如果有两个具体类A,B有继承关系,那么一个最简单的修改方案是建立一个抽象类C,然后让类A和B 成为抽象类C的子类.即如果有一个由继承关系形成的登记结构的话,那么在等级结构的树形图上面所有的树叶节点都应当是具体类;而所有的树枝节点都应当是抽象类或者接口. (7)."基于契约设计(Design By Constract),简称DBC"这项技术对LISKOV代换原则提供了支持.该项技术Bertrand Meyer伯特兰做过详细的介绍: 使用DBC,类的编写者显式地规定针对该类的契约.客户代码的编写者可以通过该契约获悉可以依赖的行为方式.契约是通过每个方法声明的前置条件(preconditions)和后置条件(postconditions)来指定的.要使一个方法得以执行,前置条件必须为真.执行完毕后,该方法要保证后置条件为真.就是说,在重新声明派生类中的例程(routine)时,只能使用相等或者更弱的
苏州城市标识设计说明: 苏州就是一座非常有魅力的旅游城市,更就是人间天堂。 有人来到苏州,主要欣赏的就就是苏州的古典园林,苏州给人印象最深的也就就是古典园林。所以在苏州城市标识的设计上,采用亭子的基本形态,亭顶用一个“人”字来表现,体现“以人为本”的设计原则。亭身用一个打开的“扇子”来表现,用以体现苏州给人带来的舒适,静谧的感觉。扇面用苏州古典园林的“八边形”门与方形景窗,以及园林中的窗饰纹样来表现,更加直观的给人一种“苏州印象”的感觉。色彩运用上,用苏州印象色:黑与白来表现,体现出苏州古城特有的城市意蕴,同时在视觉给人一种恬淡素雅,小家碧玉的苏式印象感。 公共设施设计说明: 公交站台就是道路系统中的节点设施,设计的此公交站台既要满足基本功能要求,又要有其自身的艺术性,成为街道上的景观亮点。 构件设计上采用玻璃顶板与漏空的侧板,可减少街道景观的障目感与繁杂感,方便候车的人对外观望。玻璃顶盖向后方有2%的倾斜角,利于雨水与一些落果物的排除。 前后通透的空间设计,使公交站台的小环境与周围大环境融为一体,既可保障候车人的视线通畅,又可美化整体城市环境。 外观形态设计上,采用苏州古典园林窗饰的经典纹样来表现侧板,既能保证视线的通透感,又能体现苏州文化底蕴,再加上材料的使用上,用一些高分子纤维玻璃与金属钢材,更赋于苏州城一种时代感。 另外,结合一些攀爬类植物,即能在夏天遮阳,舒适凉爽,冬日给人充足光照,而且没话了城市环境。就是的整体的景观效果更加自然,生态,环保。 休息座椅设计说明: 此休息座椅的设计就是一种放置式的公共座椅,外观形态的设计上采用苏州古典园林的窗饰的经典纹样为基本元素,加以艺术的沉淀,呈现出一种简洁大方而又美观的形态。 色彩设计上采用代表苏州的经典色彩(经典黑与经典白),就是座椅既能突出自身的色彩感觉,又能融入到整个苏州的城市色彩中。 材料设计上采用高分子树脂材料,此材料耐久性强,且质地柔软,废人一种亲与力,也更能体现出人性化设计的理念。 公用电话亭设计说明: 公用电话亭就是城市的聆听者,标志着一个城市生活的节奏与效率,通过固话的交流,沟通,就是整个城市紧密的连接在一起。 在构建设计上,吧亭基抬高十公分,在雨雪天可以起到防雨水的作用,亭顶的设计采用玻璃材质,可满足白天的采光要求,再抬高十公分,使亭中的通风更加流畅,向后倾斜2%的角度,利于排水与杂物。 外观形态的设计上,采用方形,简单,大方,墙面的处理,采用苏州古典园林的窗饰纹样为基本元素,使电话亭的设计更具有地方特色。(门前的斜坡设计更能体现无障碍设计)。 色彩设计上,采用苏州的经典代表色,灰白黑,一方面就是整个物体的色彩能自然融入整个大的环境中,另一方面,就是来此的游客更能加深对苏州的印象。 垃圾箱设计说明: 城市的环境卫生,关系到环境的质量与人的健康。城市垃圾箱的配置,反映城市生活品质,也就是城市文明程度的标志。 此垃圾箱的设计采用固定箱式的形式,外观形态的设计上采用简洁大方的方形,使整体上