面向对象设计原则和23个
设计模式的笔记
面向对象三大特点：
----------------------------------
封装：
------------------
封装，也就是把客观事物封装成抽象的类，并且类可以把自己的数据和方法只让可信的类或者对象操作，对不可信的进行信息隐藏。
不关注处理过程了，只有对象和其职能。
只允许设定的对象访问自身信息，其余私人信息隐藏。
作用：封装可以隐藏实现细节，使得代码模块化，局域化，简单；
继承：
------------------
继承的父类最好是接口，最好连属性都没有。
少用实现继承（库内使用较多），多用组合。
忘了多重继承，除非实现多接口。
作用：扩展已有代码模块；代码重用（库内使用较多），多态的基础
多态：
------------------
静态--编程时采用父类型-针对接口编程
动态--执行时才实际映射成具体的子类
作用：静态时针对接口编程，执行时才体现实际的效果
面向对象设计原则：
------------------------------------
单一职责原则（SRP）：
------------------
就一个类而言，应该仅有一个引起它变化的原因；当职责越多，耦合越多，易遭破坏
软件设计真正要做的就是发现职责并将这些职责相互分离
把职责分离到单独的类中,因为每一个类都是变化的轴线，当需求变化时,该变化会反映为类的职责的变化，如果一个类承担了多余一个的职责,那么引起他变化的原因就会有多个。职责定义为“变化的原因”。
如果一个类承担的职责过多,就等于把这些职责耦合在了一起,一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力，这种耦合会导致脆弱的设计，当变化发生时，设计会受到意想不到的破坏。
另一方面，如果应用程序的变化方式总是导致这两个职责同时变化，那么就不必分离它们，实际分离它们就会导致不必要的复杂性的臭味。
SRP是所有原则中最简单的也是最难以正确应用的原则之一。
开放封闭原则：
------------------
软件实体应该可以扩展，但是不可修改。
软件要容易维护又不容易出问题的最好方法是多扩展，少修改。
无论模块多么封闭，都会有无法封闭的变化，事先构造抽象隔离这些变化。
面对新需求，对程序的改动是通过增加新代码进行的，而不是更改现有的代码。
OCP的关键是抽象，对于代码的改动是通过增加新代码进行的，而不是更改现有代码，因此他就不会引起像不遵循OCP原则那样的连锁改动。
通常，我们更愿意一直等到确实需要那些抽象时再把他放进去，“我们愿意被第一颗子弹射中，但是我们不会再被同一支枪射得其他子弹射中”。
可以按照以下的一些方法完成这项工作:
我们首先编写测试.测试描绘了系统的一种使用方法,通过首先编写测试,我们迫使系统成为可测试的,在一个具有可测试的.在一个具有可测试性的系统中发生变化时,我们可以坦然对之,因为我们已经构建了使用系统可测试的抽象,并且通常这些抽象中的许多都会隔离以后发生的其他种类的变化.
在许多方面,OCP都是面向对象设计的核心所在,遵循这个原则可以带来面向对象技术所声称的巨大好处(灵活,可重用,可维护性),然而,并不是说只要使用一种面向对象的语言就是遵循了这个原则,对于程序中的每个部分都肆意进行抽象同样不是一个好主意,正确的做法是,开发人员应该仅仅对程序中呈现出频繁变化的那部分作出抽象.拒绝不成熟的抽象和抽象本身一样重要.
依赖倒转原则
------------------
高层模块不应该依赖低层模块，两个都应该依赖于抽象
抽象不应该依赖于细节，细节应该依赖于抽象
即要针对接口编程，不要对实现编程
本应该是高层的策略设置模块去影响低层细节实现的模块的，包含高层业务规则的模块应该优先并独立于包含实现细节的模块，无论如何高层模块都不应该依赖于低层模块。
我们更希望能够重用的是高层策略模块，如果高层模块独立于底层模块，那么高层模块就能更容易的被重用，该原则是框架的设计核心原则。
所有结构良好的面向对象的架构都具有清晰的层次定义，每个层次通过一个定义良好的、受控制的接口向外提供一组内聚的服务。
每个较高的层次都为它所需要服务声明一个抽象接口，较低层次实现了这些抽象接口，每个高层类都通过接口使用下一层，这样高层就不依赖于低层。低层反而依赖于在高层中声明的抽象服务接口。
这种倒置不仅仅是依赖关系的倒置。它也是接口所有权的倒置。
依赖倒置可以应用于任何一个类向另一个类发送消息的地方。
违反DIP，高层策略没有和底层实现分离，抽象没有和具体细节分离，没有这种分离，高层策略
就自动的依赖于低层模块，抽象就自动的依赖于具体细节。
里氏代换原则（LSP）
------------------
子类型必须替换掉它们的父类型。
适用于父类的一定适用于子类
LSP让我们得到一个非常重要的结论:一个模型，如果孤立的看，并不具有真正意义上的有效性，
模型的有效性必须通过他的客户程序来表现。
如果一组类都支持一个公共的职责，那么它们就应该从一个公共的超类继承该职责。如果公共的
超类还不存在，那么就创建一个，并把公共的职责放入其中，毕竟这样一个类的有用性是确定无
疑的。
有一些简单的启发规则可以提供一些有关违反LSP的提示，这些规则都和以某种方式从其基类中
去除某功能的派生类有关，完成的功能少于其基类的派生类通常是不能替换其基类的，因此就违
反了LSP。
另外一种违反LSP的规则形式是在派生类的方法中添加了其基类不会抛出的异常，如果基类的使
用者不期望这些异常，那么把它们添加到派生类的方法中就会导致不可替代性，此时要遵循LSP，要么就必须改变使用者的期望，要么派生类就不应该抛出这些异常。
OCP是OOD中很多说法的核心。如果这个原则应用的有效，应用程序就会具有更多的可维护性，
可重用性以及健壮性，LSP是使用OCP成为可能的主要原则之一。
迪米特法则（LoD）
------------------
如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需
要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。
法则强调类之间的松耦合。
接口隔离原则ISP
------------------
这个原则用来处理“胖”接口所具有的缺点。如果类的接口不是内聚的，就表示该类具有胖的接口。换句话说，类的胖接口可以分解成多组方法，每一组方法服务于一组不同的客户端程序。
不应该强迫客户依赖于它们不用的方法。
如果一个客户端程序依赖于一个含有它不使用的方法的类，但其他客户端缺要使用该方法，那当
其他客户端对这个类改变时，就会影响到这个类。
创建模式
----------------------------------
抽象工厂模式（Abstract Factory）
提供一个创建一系列相关或相互依赖对象的接口，而无需指定他们具体的类。
################################
一个抽象工厂多个方法，每个方法创建一个（抽象）对象；
不同工厂实例可得到不同风格对象集；
-----优缺点-----
创建操作和实际的产品对象集都独立出来
更换产品对象集很方便
接口已定义好能创建的集中对象个数，难扩展--通过参数传入创建不同类（返回对象类型很难定，需要向下类型转换不安全）
-----关联-----
具体的工厂通常是单件
通常用工厂方法或原型来实现抽象工厂中的各方法
建造者模式（Builder）
将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。
################################
定义一个有创建各子部件方法（不返回）和返回组合好的父部件的接口，从而封装内部子对象创建的细节
实现子类，以不同的创建方式实现这些方法，每个子类就是一种创建子部分方法
外部通过创建导向器Director配置创建子部件的方式（顺序和约束），并得到组合好的父部件。
最终产品不需要是抽象类，直接具体的复合类即可
-----关联-----
Builder着重于一步步创建复杂对象，最后返回
Abstract Factory创建一系列多个对象，创建一个返回一个
Composite通常是用Builder生成的
工厂方法模式（Factory Method）
定义一个用于创建对象的接口，让子类决定实例化哪一个类。
################################
一个接口一个方法创建一个抽象对象，子类确定实现那个具体类。
通过传入参数生成不同对象避免为已确定的类型生成不同子类（写在父类中）
-----关联-----
通常在Template Method中被调用
原型模式（Prototype）
用原型实例指定创建对象的种类，并通过拷贝这些原型创建新的对象。
################################
用来Clone一个自身的对象，包含一个Clone的操作。
从一个对象再创建另外一个可定制的对象，而不需要知道任何创建的细节。
注意Clone过程中的浅拷贝和深拷贝的问题
-----优缺点-----
运行时刻增加删除新原型
定制新的原型并加入到系统中很方便
原型需要有Clone操作，已有类无Clone操作时，不能被原型化。
-----关联-----
Composite和Decorator模式也常用到Prototype模式
单件模式（SingleTon）
保证一个类仅有一个实例，并提供一个访问它的全局访问点
################################
只有一个实例，全局可访问
类构造函数为保护类型，不允许直接构建，但允许子类化
简单工厂模式(StaticFactory Method)
由一个工厂对象决定创建出哪一种产品类的实例。
################################
一个创建类一个创建方法
传入不同参数创建不同对象
-----关联-----
Factory Method模式将实例化那个具体类放到了工厂的子类来实现。
简单工厂新加一个类需要修改代码，而工厂方法只需要扩展一个子类。
结构模式
----------------------------------
适配器模式（Adapter）
将一个类的接口转换成客户希望的另外一个接口。
################################
类适配-多重继承实现适配
对象适配-组合实现适配
-----关联-----
Bridge实现抽象与实现的分离可独立改变
桥接模式（Bridge）
将抽象部分与它的实现部分分离，使它们都可以独立的变化
################################
抽象和实现部分都可以独立的扩展
解决了继承机制的父子绑带关系
-----优缺点-----
分离接口及其实现部分
抽象也可扩充，提高可扩充性
-----关联-----
Abstract Factory可用于创建和配置一个特定的Bridge模式
Adapter在已有系统但要升级时使用，Bridge在系统设计的时候就使用
组合模式（Composite）
将对象组合成树形结构以表示“部分-整体”的层次结构。
################################
使组合体和单体具有同一抽象类型，从而可以统一处理
每个子部件保留父部件的显示引用有利于遍历和消息传递
共享子部件涉及FlyWeight模式以及多个父部件的定位
特别关注父子部件的引用排序遍历传递定位等
-----关联-----
父子部件连接采用Responsibility of Chain
FlyWeight模式共享子部件，但不再能引用父部件
装饰模式（Decorator）
动态的给一个对象添加一些额外的职责，就增加功能来说，装饰模式比生成子类更为灵活################################
在不影响已有的对象的情况下动态透明的添加额外职责，需要共用一个接口
原有类集不能通过子类进行扩充时用装饰者
-----优缺点-----
被装饰的组件类的接口尽可能的简单
避免多个功能组合时可能产生的很多子类，通过每个子功能一个类，动态去组合。
-----关联-----
Decorator可以改变对象的外表，Strategy可以改变对象的内核
外观模式（Facade）
为子系统中的一组接口提供一个一致的界面。
################################
为复杂的子系统提供一个简单接口
-----优缺点-----
有利于分层系统；有利于重用旧有的代码；减少接口，降低耦合
-----关联-----
Mediator在内部同事间进行通信，Facade对外
享元模式（Flyweight）
运用共享技术有效地支持大量细粒度的对象
################################
通过一个抽象工厂来生成享元
不保存对象存引用节约内存
对象不能保存外部环境状态（通过方法处理外部状态），否则无法共享
模式可引申出引用计数和垃圾回收
-----关联-----
用Flyweight来实现State/Strategy模式
代理模式（Proxy）
为其他对象提供一种代理以控制对这个对象的访问
################################
代理在客户与实现之间提供了间接性
远程代理--为一个对象在不同地址空间提供局部代表
虚拟代理--接管对开销大的对象的操作，优化性能（如打开图片多的网站）
安全代理--控制对真实对象的访问权限
智能指引--指当调用真实的对象时，代理处理另外的一些事。如智能指针
行为模式
----------------------------------
职责链模式(Chain of Responsibility)
使多个对象都有机会处理请求，避免请求的发送者和接收者之间的耦合关系。################################
串起一个消息链
发请求消息的人不管谁接收，只管丢到链上，降低耦合，简化连接
链的设置分静态和动态的
请求表示为(直接用方法调用/用编码参数Code后if处理/封装成对象用getkey方法)
子类只捕获自己的消息
-----关联-----
常与Composite一块使用，父构件作为其后继
命令模式(Command)
将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化
################################
接收Command的接收者有操作相关状态信息
Command是回调函数机制的一个OO替代品
支持取消操作，只要在执行前保存原状态-与Memento合作
支持修改日志，在动作时保存修改
通过Command在原语操作上构建新的高层操作层，如DB事务处理
将调用操作的对象与知道如何实现该操作的对象解耦
命令粒度大可不要接收者，大部分要传入
解释器模式(Interpreter)
给定一个语言，定义它的文法的一种表示，并定义一个解释器使用该表示来解释语言中的句子################################
划分为终结符表达式和非终结符表达式
递归的解析非终结符表达式
迭代器模式(Iterator)
提供一种方法顺序访问一个聚合对象中各个元素，而不需要暴露该对象内部表示。################################
将遍历访问等操作独立于内部对象
要求对象为同类型或有共同接口
根据控制迭代的人不同分为内部迭代器和外部迭代器
中介者模式(Mediator)
用一个中介对象来封装一系列的对象交互（双向）
################################
中介者包含多个内部对象的引用
各内部对象可见且仅见中介者，降低耦合
将各成员交互的复杂性转化为中介者复杂性
成员与中介者通信：观察者模式/中介者定义接口，成员将自身作为参数传入
-----关联-----
Facade为单向且对外提供接口
Mediator为内部协同各对象交互
通信可用观察者模式
备忘录模式(Memento)
在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态################################
状态操作只对触发者可见确保封装性
观察者模式（Observer/Publish-Subscribe）
定义对象间的一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并自动更新
################################
让多个观察者对象同时监听某一个主题对象，当状态变化时自动通知所有观察者对象。
实质是为了解除耦合
创建目标到观察者的映射(直接保存观察者的引用/建立关联查找机制如hash)
同时观察多个目标(扩展Update函数传入目标自身)
谁触发更新：
状态变-自动更新-无缓冲重复操作可能效率低
状态变不更新客户手动更新-客户可能忘记更新
目标和观察者关系复杂时可以使用更改管理器
委托方式-委托可以看作对函数的抽象
进一步的抽象，用事件机制解决观察者的方法不可统一为Update名称的问题
定义一个事件委托update（EventHandler）
将具体观察者的操作绑定到事件中。
当主题者状态变更时，调用Update事件，触发操作。
-----优缺点-----
目标观察者解耦
支持广播通信
可能导致意外的Update
-----关联-----
更改管理器其实是个中介者，可用单件实现
状态模式（State）
允许一个对象在其内部状态改变时改变它的行为
################################
封装特定状态下对应的行为
谁来定义状态转换(固定的接口方法/子状态类自己确定转换)
状态机着重于状态转换/State着重于状态对应行为的抽象
-----关联-----
状态对象通常是Singleton
策略模式(Strategy)
定义一系列的算法，把它们一个个封装起来，并且使它们可相互替换。
################################
定义算法家族，分别封装起来，让它们之间可互相替换；让算法的变化，不会影响到使用算法的客户。
-----关联-----
与State结构相同
算法的创建可以结合创建模式
模版方法模式(Template Methed)
定义一个操作中算法的骨架，而将一些步骤延迟到子类中。
################################
使子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
重要的代码复用技术，在类库中尤为重要。
-----关联-----
模版方法使用继承来改变算法的一部分。Strategy使用委托来改变整个算法。
访问者模式(Visitor)
表示一个作用于某对象结构中的各元素的操作。使你可以在不改变各元素类的前提下定义作用于这些元素的新操作。
################################
给整个对象结构增加一个新方法。
要求原有的对象结构有Accept机制
在对象结构稳定，会涉及到增加操作时适用
采用了双分派的技术
-----关联-----
访问者可以用于Interpreter
面向对象与设计模式的关系 自从GOF出了那本《设计模式》之后，再这四五年中，设计模式一词已经成了架构设计的代言，随后阎宏博士在中国道家思想与《建筑永恒之道》的基础之上，使用中国四大名著中的故事，为我们谱写了一本《Java与模式》，王永刚与王永武与为我们送来了一本《道法自然》更加为初学设计模式的朋友们带来了福音。 设计模式是在面向对象的基础之上，对软件的架构进行合理的组合，按照一定的原则“依赖倒置、李式代换、帝米特法则”使软件架构达到一种松散耦合、以求得对变化的适用。 所以设计模式的前提就是面向对象，其利用接口对模块进行隔离（门面模式、桥梁模式），利用多态对变化进行封装（策略模式、状态模式、装饰模式）、对创建进行合理规划（静态工厂模式、工厂模式、单例模式、多例模式）如果不能很好得掌握面向对象（OO）就更谈不上利用设计模式的成熟思想。 我们公司主要对国有大中企业的内部管理及物流状况进行开发，比如现在这个项目，是为一个政企不分的大型老国有企业，我们的开发建立在他们的体制改革基础之上，变化是常常发生的，因为他们的业务本身就在变化的过程中。 像这样的大型系统，如果不利用面向对象与设计模式的成熟思
想，很难对几百万行的代码进行控制。 在开发中，我们对于从业人员的要求必须得能看懂我做的UML 图，设计中在关键点上我会采用适合设计模式：比如策略、门面、状态、工厂、装饰、桥梁... 而这些设计模式是建立在很强的OO思想之上的，如果对于OO 都不能很好的掌握，更谈不上设计模式了。比如针对接口编成，多态性的应用，以及满足“李式代换、底米特法则等等”。如果不能用OO与设计模式的术语进行有效的沟通，那么对于项目的管理与技术沟通都是存在问题的。 在一些复杂的地方，如果一点点讲明是很麻烦并且很浪费时间的，如果说在这一个采用了“装饰模式”，假如对方能很快明白装饰模式是怎么一会儿事，那么他就可以快速的跟据UML图把这几个类做出来。
结构化分析设计与面向对象分析设计比较研究 重庆工商大学计算机科学与技术08软件龚霞 指导老师康世瀛 中文摘要：解析了结构化方法和面向对象方法这两种软件开发方法具有的分析设计过程，讨论了各自在不同软件开发中的应用及局限性，提出了在选用面向对象开发大型软件系统的同时可结合结构化方法。 关键词：软件开发；结构化方法；面向对象方法 Abstract：This paper anatomizes the analysis and design process of Structural method and objected-oriented method,discusses their applications and disadvantages and proposes that structural method can also be used while developing the large-scale software systems in selecting the objected-oriented method. Key words：software-development;objected-oriented method;structural method 一、引言 结构化方法由E.Yourdon和L.L.Constantine在1978年提出，结构化方法又可称为面向功能的软件开发方法或面向数据流的软件开发方法。结构化方法是建立在软件生存周期的模型基础上的一种软件开发方法，相对于早期的个体化开发方法无疑是前进了一大步。 由于传统的生命周期开发学存在下面的问题：生产率提高的幅度远不能满足需求，软件的重用度很低，软件难以维护，软件往往不能满足用户的需求。所以出现了面向对象软件开发方法。这是一种自底向上和自顶向下相结合的方法，而且它以对象建模为基础，从而不仅考虑了输入、输出数据结构，实际上也包含了所有对象的数据结构，所以面向对象的软件开发方法彻底实现了PAM没有完全实现的目标。不仅如此，面向对象技术在需求分析、可维护性和可靠性这三个软件开发的关键环节和质量指标上有了
面向对象设计原则 ?OO原则： ◆封装变化之物 ◆针对接口编码，而不是对实现 ◆应用程序中的每一个类只有一个改变的理由 ◆类是关于行为与功能的 ?目的： 设计原则形成更可维护更具灵 ◆使用已被证实的OO设计原则形成更可维护、更具灵 活性以及更易扩展的软件 Design Principles ?OCP (The Open-Closed Principle) 开放-封闭原则 SRP(The Single Responsibility Principle)单职责原则?SRP (The Single-Responsibility Principle) 单一职责原则?LSP (The Liskov Substitution Principle) Liskov替换原则 ?DIP (The Dependency-Inversion Principle) 依赖倒置原则?ISP (The Interface-Segregation Principle) 接口隔离原则?CARP (Composition/Aggregation Principle ) 合成/聚合复用 原则 ?LoD(Law of Demeter) 迪米特法则
Open-Closed Principle ?开-闭原则（Open-Closed Principle） 对扩展开放对修改关闭 ◆对扩展开放，对修改关闭 ◆OCP允许改变，以不需要修改现有程序代码的方式 进行 SRP ?单一职责原则(SRP) 就一个类而言，应该仅有一个引起它变化的原因。 ◆就个类而言，应该仅有个引起它变化的原因。
Example: SRP violation interface Modem{ public void dial (String pno);ti public void dial (String pno);public void hangup();public void send (char c); public char recv();}connection management data communication Example Separated modem interface
一设计原则及思路 1、猪场选址应远离住宅区，便于防疫，同时避免周围用户受粪便气味影响。 2、猪场规划时，生产、生活区一定要分开，便于猪场防疫及管理。生产区应建在主风向的上风口，不受生活区的影响。 3、生产区各幢舍最好要有走廊连接，便于猪场猪群周转，同时生产人员可以同外界隔开，达到真正意义的全封闭生产。 4、分为上、中、下三层结构，上层为水电通道，中层行走及转群，下层是主粪沟。 5、每个猪舍的粪便都冲入到主粪沟，然后流到化粪池中。这种设计的缺陷是粪便会沉淀在粪沟中，过一段时间后需要清理粪沟，否则猪舍的空气环境会受很大的影响，不利于猪只的生活。如果有劳动力，可以让饲养员把猪舍中的粪铲出圈外，而不把它冲入粪沟内，这样对猪舍的环境比较有利。 6、本设计方案本着勤俭节约、美观大方、经济实用的原则，充分利用已经建成的猪舍,囿于条件限制,产房适当放宽。配种舍与妊娠舍合用一幢猪舍. 一、基本设计参数的选择根据我国目前实际情况和现有生产水平，对年产2000头肉猪生产线实行工厂化生产管理方式，采用先进饲养工艺和技术，其设计的生产性能参数选择为：平均每头母猪年生产2.2窝，提供19.8头肉猪，母猪利用期为三年。肉猪平均日增重700克以上，达90—100公斤体重的日龄为168天左右（24周）。肉猪屠宰率75%，胴体瘦肉率65%。猪群存栏：1256头基础母猪：124头其中：空怀9头妊娠90头哺乳25头公猪6头，后备母猪12头，后备公猪2头整个生长期的成活率大于90% 二、生产工艺程序1、本方案的肉猪生产程序是以“周”为计算单位，工厂化流水生产作业程序性生产方式，全过程分为四个生产环节。按下列工艺流程图示进行。产房4周育仔舍5周中、大猪舍15周种猪9-10周肉猪24周出栏上市配种舍5周妊娠舍11周2、配种妊娠阶段。在配种舍内饲养空怀、后备、断奶母猪及公猪进行配种。每周参加配种的母猪6头，保证每周能有5头母猪分娩。妊娠母猪放在妊娠母猪舍内饲养，在待产前转入产房。3、母猪产仔阶段。母猪按预产期进产仔舍产仔，在产仔舍内4周，仔猪平均4周断奶。如果有特殊情况，可将仔猪进行合并，这样不负担哺乳的母猪转回配种舍等待配种。4、仔猪培育阶段。断奶后仔猪进入仔猪培育舍培育至9周龄转群，仔猪在育仔舍5周。5、中猪饲养阶段。9周龄仔猪由育仔舍转入到中猪舍饲养7周（16周龄）预计体重可达50公斤左右。6、大猪饲养阶段。将50公斤左右的猪群转入大猪舍饲养至24周龄，体重达90—100公斤出栏上市。一般每周可出栏60头猪左右。三、猪场布局根据实际情况因地制宜并在利用充分利用地形的基础上进行猪舍布局。猪场生产程序分空怀母猪、配种、妊娠；分娩哺乳；断奶仔猪培育；肉猪饲养四个阶段。各区域配有专门化猪舍和设备。猪舍力求紧凑合理，互不干扰，便于猪群周转，严格做到各生产单元全进全出，各舍的大小以及规格布局，按设计要求系统安排，形成稳定的生产流水线。猪场除各生产环节的猪舍和设备外，还需外围的配套条件，包括种猪来源、饲料来源，全年约需全价配合饲料700吨，以及供水设施、排污设施、办公、宿舍、交通运输、防疫消毒等生产和附属设施。四、猪舍设计（一）、配种舍妊娠舍（图1、图2）生产线有124头母猪。配种母猪在配种舍内饲养，空怀、后备、妊娠母猪在妊娠舍内饲养。配种舍内设配种栏，一个配种栏内养1头公猪，设在4个单体栏之后，共设8个配种栏。配种后的母猪在单体栏饲养，观察4周，确认妊娠后转妊娠舍饲养，对未妊娠或返情的母猪送回到配种栏内接受第二情期配种。对连续两个情期均配不上的母猪建议淘汰处理，用后备母猪增补。单体栏成60厘米夹道，两侧隔栏用直径1寸(33毫米)钢管组成，高90厘米，限制母猪饲养，猪栏前设贯通食槽，后部有40厘米宽的横走向漏缝地板，下有粪沟，便于饲养管理，围栏长2.2-2.5米，每头猪实占面积1.3平方米。共设单体栏32个。设计配种舍长22.5宽8.6m 0.9m走道0.9m走道图1 配种舍平面图1、每个配种栏对应四个母猪单体栏，单体栏内是刚断奶的母猪及配种1—3周的母猪。到配种后第四周，利用妊娠诊断仪诊断母猪是否怀孕，怀孕的母猪转到妊娠母猪舍饲养，没有怀孕的母猪留在配种舍等待下次配种。2、124头母猪猪场至少需要2头试情公猪，每周有6头猪配种。3、后备母猪、空怀母猪可放
设计模式六大设计原则 单一职责原则(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.选择题 (1)软件工程的概念是在（）年被首次提出的。 A.1949 B.1968 C.1972 D.1989 (2)下列不属于软件工程的目标的一项是（） A.提高软件产品的质量 B.提高软件产品的可靠性 C.减少软件产品的需求 D.控制软件开发成本 (3)软件危机产生的主要原因是（） A.软件工具落后 B.软件生产能力不足 C.对软件认识不够 D.软件本身的特点及开发方法 (4)人们公认的第一门面向对象编程语言是（）。 A. Simula B. Smalltalk C. C++ D. Java (5)下列编程语言中不支持面向对象的特性的是（）。 A. C++ B. ANSI C C. Java D. Objetive c (6)下列选项中不是面向对象方法的相关原则的是（）
A.封装 B.继承 C.多态 D.结构 (7)（）是面向对象方法中用来描述”对客户隐藏对象的属性和实现细节”的概念。 A.封装 B.继承 C.多态 D.抽象 (8)下列选项中不属于面向对象方法的优势之-的是（）。 A.复用性强 B.改善了软件结构 C.软件的执行效率更高 D.抽象更符合人类的思维习惯 2.判断题 (1)软件就是程序，编写软件就是编写程序。对错 (2)软件危机的主要表现是软件需求增加，软件价格上升。对错 (3) C语言对面向对象的发展起到了重要作用。对错 (4)面向对象方法中的对象是从客观世界中抽象出来的一个集合体。对错 (5)面向对象可以保证开发过程中的需求变化完全不会导致系统结构的变化。对错 (6)面向对象方法就是使用面向对象的程序设计语言进行编程。对错
(7)对象的自治性指的是对象是完全封闭的,不受任何外界影响。对错 (8)类是面向对象程序中的构造单位，也是面向对象程序设计语言的基本成分。对错 第二章 1.选择题 1.选择题 (1)下列关于模型的表述，不正确的项是（）。 A.建模语言只能是图形表示的 B.模型所描绘的系统蓝團既可以包括详细的计划，也可以包括系统的总体计划 C.模型可以帮助开发组生成有用的工作产品 D.最好的模型总是与现实世界联系密切 (2) UML的全称是（）。 A. Unify Modeling L.anguage B. Unified Modeling Language
本地传输网优化的规划设计思路 程万品 （广州杰赛科技股份有限公司-西南分院） 摘要：本文对本地传输网的需求和存在问题进行分析，提出传输网优化的必要性。并以网络结构、传输设备、光缆线路三大要素对本地传输网的优化内容进行探讨，并就部分细节问题具体展开。 关键词：网络、传输、线路 一、引言 运营商近几年通对本地传输网的大力建设，本地传输网形成了一定的规模和层次，但因工程建设周期、设计衔接、建设衔接、建设难度及建设遗留问题等原因，现各运营商的本地传输网在安全性、可控性、高效性和扩展性均存在不同程度的问题和隐患。随着通信技术的不断发展，为了满足人们对2G/3G/4G移动业务及宽带/专线等多业务需求的增长，通过优化使传输网络尽可能达到结构清晰、提高网络利用率、提高网络安全性、提高网络拓展性、节约建设成本等目的。 二、网络现状分析 传输规划设计整体思路就是通过对熟悉网络现状资源、分析传输网存在的问题、拟定传输网发展方向及目标、展开网络优化工作。主要从以下几个方面对本地传输网进行分析： 2.1 网络高效性 高效性是网络生产电路的效益，如通道规划安排产出的通路应是高产出、高效率的，使网络的投资成本得到充分的发挥，并降低运营成本。 网络通道利用率偏低的原因：综合业务接入不同传输网，通道大量闲置；老旧设备性能对新业务接入能力的不足，通道利用率低；通道使用缺少整体规划（或由于电路的紧急开通），而造成的电路运行混乱，致使电路调配日益复杂、局端上下电路难度增加、交叉矩阵浪费严重且使用不均衡、电路运行的清晰度低；光缆规划建设及纤芯使用的合理性，限制了设备组网的灵活性，存在大范围纤芯迂回的现象；管理不到位，纤芯使用混乱。 2.2 网络安全性 安全性指保证网络设备运行的稳定、安全，网络运行的保护、恢复等，设备板件的保护备份等，即应有较强的对网络正常运行的保障和障碍时快速代通和尽量小影响用户的能力； 个别网络结构安全性差，结构合理性需提高；骨干设备尤其是中心局房设备关键板件存在不安全隐患；电路运行负荷分担不均衡，个别设备业务过于集中；同步链路的传送主备用链路规划欠合理，存在过长同步链路，造成同步质量欠佳；光缆线路仍存在大的故障点，如存在关键节点单路由引入、较长链状结构等。 2.3 网络可控性 可控性是指对网络应有较强的网络管理能力，实现业务电路在传输网络上的端到端调配，保证业务的即时开通、调配，使传输网成为可运营的基础网络。
精品文档 1、在用例分析模型使用UML用例图中,用例与参与者之间的关系是 （A）通信(或者关联) （B）泛化（C）实现 (D)使用 2、UML用例图中,用例之间有三种关系,以下属于用例之间关系的是 （A）包含（B）实现（C）通信（D）参与 3、UML类图中,表示整体与局部关系的是 （A）聚合（B）依赖（C）关联（D）继承 4、在某信息系统中，存在如下的业务陈述：①一个客户提交0个或多个订单；②一个订单由一 个且仅由一个客户提交。系统中存在两个类：“客户”类和“订单”类。对应每个“订单”类和“客户”类之间是 （A）关联（B）依赖（C）聚集（D）继承 5、和都能够表示对象之间的交互,因此他们被合称为交互图 （A）顺序图类图（B）协作图状态图 （C）顺序图协作图（D）类图状态图 6、UML顺序图以二维图表来显示交互。纵向是时间轴，时间自上而下。横向显示了代表协作中 单个对象的分类角色。每个对象用方框表示，对象的名字在方框内部，并在名字的下方加下划线。每个分类角色表现为垂直列。在角色存在的时间内，显示为虚线 （A）生命线（B）协作消息（C）激活（D）对象 7、Machine软件公司为Benz公司的一款跑车设计了一个过程控制的紧急按钮，该按钮的功能根 据汽车的行驶状态不同，而具有不同的功能，比如汽车静止时，该按钮可以快速启动汽车； 当汽车的时速超过200km/h时，该按钮可以在2秒内将车平稳地停下来；当汽车向后行驶时，该按钮可以立即刹车，基于以上功能考虑，架构师Bob在设计该按钮时，应该采用哪种设计模式 （A）命令模式（B）状态模式（C）观察者模式 (D) 外观模式详细8、 River软件公司开发一个Web服务器，该服务器能够根据客户端的请求，执行相应的处理， 还可以对同时到达的请求排队，并对成功执行的每个请求记录日志。系统设计师Bob在设计该系统时，应该使用哪个设计模式以更好地支持对请求的处理 （A）适配器模式（B）观察者模式（C）命令模式 (D) 外观模式
面向对象设计原则
单一职责原则--SRP 一、SRP简介（SRP--Single-Responsibility Principle）： 就一个类而言，应该只专注于做一件事和仅有一个引起它变化的原因。 所谓职责，我们可以理解他为功能，就是设计的这个类功能应该只有一个，而不是两个或更多。也可以理解为引用变化的原因，当你发现有两个变化会要求我们修改这个类，那么你就要考虑撤分这个类了。因为职责是变化的一个轴线，当需求变化时，该变化会反映类的职责的变化。“就像一个人身兼数职，而这些事情相互关联不大，，甚至有冲突，那他就无法很好的解决这些职责，应该分到不同的人身上去做才对。” 二、举例说明： 违反SRP原则代码: modem接口明显具有两个职责：连接管理和数据通讯； interface Modem { public void dial(string pno); public void hangup(); public void send(char c); public void recv(); } 如果应用程序变化影响连接函数，那么就需要重构： interface DataChannel { public void send(char c); public void recv(); } interface Connection {
public void dial(string pno); public void hangup(); } 三、SRP优点： 消除耦合，减小因需求变化引起代码僵化性臭味 四、使用SRP注意点： 1、一个合理的类，应该仅有一个引起它变化的原因，即单一职责； 2、在没有变化征兆的情况下应用SRP或其他原则是不明智的； 3、在需求实际发生变化时就应该应用SRP等原则来重构代码； 4、使用测试驱动开发会迫使我们在设计出现臭味之前分离不合理代码； 5、如果测试不能迫使职责分离，僵化性和脆弱性的臭味会变得很强烈，那就应该用Facade或Proxy模式对代码重构；
移动通信无线基站接地系统 建设工程验收规范 V1.0 （试行稿） 1 总则 1.0.1 为保证移动通信基站内设备的安全与正常工作，确保建筑物、站内工作人员的安全，统一GMCC 移动基站接地系统施工、验收标准，特制定本规范。 1.0.2 本规范对新建移动通信基站的接地建设提出要求,同时也适用于移动通信基站的改建、扩建及相关通信系统的防雷及接地整改等工程的设计、施工、监理、验收和日常维护工作的技术要求和依据。 1.0.3 在基站接地建设中，应积极采取有理论依据、经反复实践证明行之有效的、经过鉴定的新技术、新工艺和新产品。 1.0.4 本规范与国家规范、部颁标准、规范相矛盾时，应以国家规范、部颁标准、规范为准；本规范解释权在广东移动通信有限责任公司工程管理中心。 2名词术语 2.0.1 地接地系统中所指的地，一般是指大地，具有导电的特性，能有效地泄放电流，一般可作为参考零电位。 2.0.2 接地体为使电流流入而埋入地下并直接与大地接触的导体。 2.0.3 环行接地体 围绕基站机房四周，按规定深度埋设于地下的封闭环行接地体（含垂直接地体）2.0.4 接地系统 接地线、接地汇集线（排）、接地引入线、接地体（网）的总称。 2.0.5 接地网 由基站基础中的钢筋网、围绕基站的环行接地体以及由地下其它导电材料所共同连接而成的接地体的总称。 2.0.6 接地汇集线引出机房、电力室等各种接地线的公共接地母线。 2.0.7 接地线通信设备与接地汇集线（地网）之间的连接线。
2.0.8 工作地 直流电源相对于大地为0V 的连接电路，它是直流电源利用大地构成回路的电路部分。工作地一般通过地线总汇流排下地。 2.0.9 保护地设备外壳及其连接到接地汇集总线（排）的保护地线、交流电源系统中的地线、电源和信号避雷器的地线等统称为保护地。 2.0.10 地电位升雷电流通过接地装置流入大地所引起大地电位的升高称为地电位升，会危害设备对地的绝缘。 2.0.11 接地体有效长度接地体有效的最大长度，即比这一长度更长的接地体超出有效长度部分视为无1/2 效，有效长度取决于土壤电阻率。l e = 2 p （l e为有效长度，为接地体埋设区域的土壤电阻率）。 3技术指标及质量要求 3.0.1 根据国家和信息产业部的相关规范要求，移动通信基站的工频接地电阻应在5Q以内；部分地处高山周边土壤电阻率大于3500Q m的基站，接地建设确有难度时，接地电阻可以适当放宽到10欧姆以下；基站地网应符合联合接地及等电位原理，其使用期应达到10年。 3.0.2 本规范要求的工频接地电阻为指定的仪表测量值，除规范规定的指定条件下的估算结果外，不接受以其它形式的估算或换算结果。 4地网设计原则与思路 4.0.1 基站选址时宜考虑基站地网建设的实际难度。地网设计中，应在综合考虑基站位置、地质气候条件、周边环境、占地赔偿等因素的基础上，因地制宜，合理利用已有资源，做到经济合理、安全可靠、维护方便。 4.0.2 基站地网是复杂的联合接地体，在设计时，应选择土壤电阻率均匀且方便人工作业的范围；对于不确定性因素较多的基站，应给予一定的设计裕量；设计方案应具有应对不可预见因素的调整空间，以便快速地完成设计变更和施工。 4.0.3 移动基站地网由机房地网、铁塔地网和变压器地网组成。基站地网应充分利用机房建筑基础（含地桩）、铁塔基础内的主钢筋和地下其它金属设施作为接地体的一部分。当铁塔设在机房房顶，电力变压器设在楼内时，其地网可共用机房地
可用性设计原则 文档修改记录
启发式评估原则 (1) 可学习性 (3) 1.可见性 (3) 刺激强度 (3) 模式 (3) 反馈 (4) 识别 (4) 定位 (4) 2.可预见性 (4) 一致性和正确性 (4) 惯例 (5) 熟悉度 (5) 布局 (5) 模式 (6) 3.映射与启示性 (6) 4.真实性 (6) 5.帮助性 (7) 有效性 (7) 1.效用 (7) 用户控制原则 (8) 操作与目标相符原则 (8) 正确的功能与复杂度平衡原则 (8) 2.容错性（安全性） (9) 避免出错原则 (10) 错误恢复原则 (10) 用户控制和自由——清楚的标识退出 (10) 3.稳定性 (11) 高效性（效率） (11) 4.简洁性 (11) 去除界面冗余元素原则 (11) 80/20原则 (11) 满意度原则 (12) 渐进原则 (12) 合理约束原则 (12) 5.快捷性 (12) 6.可记忆性 (13) 7.灵活性 (13) 满意度 (13)
概述 1.可用性定义 ISO9241/11中的可用性定义是：特定用户在特定的使用环境下，使用某个产品达到特定目标的有效性、效率和满意度的大小。 2.相关术语描述 使用环境——用户、目标、任务、设备（硬件、软件和原料）、以及使用产品的物理环境和社会环境。 用户——与产品进行交互的人。 目标——一个预期的结果。 产品——在设备中，需要被详细说明或评估其可用性的一部分。 有效性——用户完成特定任务和达到特定目标时所具有的正确和完整程度； 效率——用户完成任务的正确和完整程度与所使用资源（如时间）之间的比率； 满意度——用户在使用产品过程中所感受到的主观满意和接受程度。 可学习性 3.可见性 可见性原则是指用户了解系统所有功能和组件，包括各种可用功能和使用后的系统反馈。 可见性原则规定所有的用户必须能够获知系统所有的功能和过程。在复杂的应用程序中完全实现可见性可能会导致用户界面难以使用。 刺激强度 我们首先感觉到的是刺激的强度，然后才是行为的含义。换言之，在理解某个事物之前就已经感知到它的颜色、形状和尺寸了。 模式 可见性原则与后文中提到的渐进原则、简洁性原则联合作用。 仅使用可见性原则而不考虑渐进将会导致视觉上的超负荷。界面设计中很容易使系统中的所有功能都可见，但是它使得用户所有精力都放在了辨析系统的功能而不是认真学习用户交互界面，同时不能够按照要求进行交互并按照新的任务要求更新界面。
1、什么面向对象？ 面向对象不仅是以些具体的软件开发技术与策略，而且以一套关于如何看待软件系统与现实世界的关系，以什么观点来研究问题并进行求解，以及如何进行系统构造的软件方法学。 2、软件开发方法学的基本方法有哪些？ 1）软件工程和瀑布方法学2）新方法学：螺旋式、迭代式、递增式、合并式3）面向对象方法学：UML、RUP、XP 3、为什么需要OOA、OOD。 OOA就是运用面向对象的方法进行需求分析，OOA加强了对问题域和系统责任的理解，有利于人员之间的交流，对需求变化的适应性较强，很好的支持软件复用。 OOD就是运用面向对象的方法进行系统设计，OOD．符合人们习惯的思维方法，便于分解大型的复杂多变的问题；易于软件的维护和功能的增减；可重用性好；与可视化技术相结合，改善了工作界面。 4、从概念层次、规格层次、实现层次三个角度如何理解对象的概念？ 从概念层次来看，一个对象就是一系列的责任； 从规格层次来看，一个对象是一系列可以被其他对象或该对象自己调用的方法；从实现层次来看，一个对象是一些代码和数据。 5、如何绘制类图和对象图？简述其步骤。 类图绘制：1发现类，找到备选类，确定候选类2关联分析，确定关联关系，多重性分析3职责分析4限定与修改，导航性分析，约束，限定符; 对象图绘制：1发现类和对象2对其细化，分析，确定关系。 6、简述重定义方法与重载的区别。 重定义：1参数列表必须完全与被重写的方法相同2返回类型必须一直域被重写的方法的类型相同3访问修饰符的限制一定要大于被重写方法的访问修饰符4重写方法一定不能抛出新的检查异常或者比被重写方法申明更加宽泛的检查性异常：重载：1必须有不同参数列表2可以有不同的返回类型，只要参数列表不同即可3可有不同访问修饰符4可抛出不同的异常。 7.简述抽象方法与虚方法的联系与区别 虚方法有一个实现部分可以为子类实现有共同的方法，并为派生提供了覆盖该方法的选，抽象方法只是强制派生覆盖方法；抽象方法只能在抽象类中声明，而虚方法不是；抽象方法不能声明方法实体，虚方法可以；包含抽象方法的类不能实例化，但虚方法可以。 8、简述使用继承的规则。 1)、不要过度使用；2)、子类应是超类的一个类型；3)、子类应是超类的扩展； 4)、尽量少从具体类继承，最好继承接或抽象类。
文创产品设计思路六个原则 从“吃住行游购娱”到“商养学闲情奇”，旅游的升级换代随着社会物质生活水平的提高而不断加快。游客对于景区的文化内涵与文化体验需求不断提升。由此，设计感十足、独具特色、承载了景区文化内涵的特色文创商品逐步走俏，在游客心中占据越来越重要的地位。 一个优秀的文创产品，既具有产品实用功能性，更重要的是其中蕴含的精神文化，能够带给人生活的便利与文化的认同归属感。因而，景区文创产品设计也逐步成为景区营销中重要的载体。 一、景区文创产品的重要作用 1.制造话题 旅游商品通过文化创意的加成，形成了一个个病毒式的营销案例。当下传播最厉害的渠道即是互联网端的口碑传播，年轻人群构成了互联网上口碑传播的主要力量，旅游文创商品与年轻人群的传播痛点完美契合，故宫这几年的全面文创，尤其是文创商品，不仅为故宫带来了产品销量的增加，更在年轻人中形成了一股话题浪潮，在游客中代表传统的故宫仿佛获得了新生，也让文化以一种更新的方式影响着新一代人群。 以文化创意为核心举办的活动，不仅销售文化创意产品，也制造了足够的话题为景区吸引游客。在台湾，由荷兰设计师霍夫曼设计的18米高的黄色小鸭停泊在高雄港，一个月内吸引了近400万人次参观。 2.传播景区文化 通过文化创意产品的传播，还可以让非物质文化遗产再次以物质形态真正地融入现代人日常生活当中，将对“非遗”的保护和传承起到重要的作用。这样的文创产品不但越来越受到游客们的欢迎，同时更能促进景区“高频消费”。 在台北故宫博物院中，各色各样的文化创意产品与早已将文化、设计深深植入其品牌中，在有大开脑洞的文化创意产品吸引眼球的同时，也有深挖传统文化的文化创意产品通过一次次国际大奖将文化传播到全世界。 3.带动旅游景区发展 台湾是以文创为核心发展的地区，具有价值的旅游文化创意产品是每一个景区吸引游客，形成话题的必备妙招。 台湾乡村旅游的特色就是注重品牌与文化创意产品的开发。比如说酒庄，像水果、稻米这些农产品都可以做酒，于是监管粮食的部门就会辅导农民转型做乡村酒庄，甚至会扶持这些乡村酒庄去参加国际上的竞赛。
一、单一职责原则（ＳＲＰ） 就一个类而言，应该仅有一个引起它变化的原因。软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离。测试驱动的开发实践常常会在设计出现臭味之前就迫使我们分离职责。 二、开闭原则（ＯＣＰ） 软件实体（类、模块、函数）应该是可扩展的，但是不可修改的。也就是说：对于扩展是开放的，对于更改是封闭的。怎样可能在不改动模块源代码的情况下去更改它的行为呢？怎样才能在无需对模块进行改动的情况下就改变它的功能呢？关键是抽象！因此在进行面向对象设计时要尽量考虑接口封装机制、抽象机制和多态技术。该原则同样适合于非面向对象设计的方法，是软件工程设计方法的重要原则之一。 三、替换原则（ＬＳＰ） 子类应当可以替换父类并出现在父类能够出现的任何地方。这个原则是Liskov于1987年提出的设计原则。它同样可以从Bertrand Meyer 的DBC (Design by Contract〔基于契约设计〕) 的概念推出。 四、依赖倒置原则（ＤＩＰ） １、高层模块不应该依赖于低层模块。二者都应该依赖于抽象。２、抽象不应该依赖于细节。细节应该依赖于抽象。在进行业务设计时，与特定业务有关的依赖关系应该尽量依赖接口和抽象类，而不是依赖于具体类。具体类只负责相关业务的实现，修改具体类不影响与特定业务有关的依赖关系。在结构化设计中，我们可以看到底层的模块是对高层抽象模块的实现（高层抽象模块通过调用底层模块），这说明，抽象的模块要依赖具体实现相关的模块，底层模块的具体实现发生变动时将会严重影响高层抽象的模块，显然这是结构化方法的一个"硬伤"。面向对象方法的依赖关系刚好相反，具体实现类依赖于抽象类和接口。 五、接口分离原则（ＩＳＰ） 采用多个与特定客户类有关的接口比采用一个通用的涵盖多个业务方法的接口要好。ISP原则是另外一个支持诸如COM等组件化的使能技术。缺少ISP，组件、类的可用性和移植性将大打折扣。这个原则的本质相当简单。如果你拥有一个针对多个客户的类，为每一个客户创建特定业务接口，然后使该客户类继承多个特定业务接口将比直接加载客户所需所有方法有效。 以上五个原则是面向对象中常常用到的原则。此外，除上述五原则外，还有一些常用的经验诸如类结构层次以三到四层为宜、类的职责明确化（一个类对应一个具体职责）等可供我们在进行面向对象设计参考。但就上面的几个原则看来，我们看到这些类在几何分布上呈现树型拓扑的关系，这是一种良好、开放式的线性关系、具有较低的设计复杂度。一般说来，在软件设计中我们应当尽量避免出现带有闭包、循环的设计关系，它们反映的是较大的耦合度和设计复杂化。 面向对象之代码复用规则 1、对接口编程 "对接口编程"是面向对象设计（OOD）的第一个基本原则。它的含义是：使用接口和同类型的组件通讯，即，对于所有完成相同功能的组件，应该抽象出一个接口，它们都实现该接口。具体到JAVA中，可以是接口，或者是抽象类，所有完成相同功能的组件都实现该接口，或者从该抽象类继承。尽量使用接口。接口只是对象打交道的入口，只有具有继承关系才使用抽象类。 2、优先使用对象组合，而不是类继承 "优先使用对象组合，而不是类继承"是面向对象设计的第二个原则。并不是说继承不重要，而是因为每个学习OOP的人都知道OO的基本特性之一就是继承，以至于继承已经被滥用了，而对象组合技术往往被忽视了。只有有现实生活中的父子关系才使用继承。 相关的设计模式有：Bridge、Composite、Decorator、Observer、Strategy等。 3、将可变的部分和不可变的部分分离 "将可变的部分和不可变的部分分离"是面向对象设计的第三个原则。如果使用继承的复用技术，我们
网站设计中要注意的原则 网站是企业向用户和网民提供信息(包括产品和服务)的一种方式,是企业开展电子商务的基础设施和信息平台，离开网站(或者只是利用第三方网站)去谈电子商务是不可能的。企业的网址被称为“网络商标”，也是企业无形资产的组成部分，而网站是INTERNET上宣传和反映企业形象和文化的重要窗口。企业网站设计显得极为重要，下面是一些网站设计中应注意的原则。 一、明确建立网站的目标和用户需求 Web站点的设计是展现企业形象、介绍产品和服务、体现企业发展战略的重要途径，因此必须明确设计站点的目的和用户需求，从而做出切实可行的设计计划。要根据消费者的需求、市场的状况、企业自身的情况等进行综合分析，牢记以“消费者(customer)”为中心，而不是以“美术”为中心进行设计规划。在设计规划之初同样考虑:建设网站的目的是什么?为谁提供服务和产品?企业能提供什么样的产品和服务?网站的目的消费者和受众的特点是什么?企业产品和服务适合什么样的表现方式(风格)? 二、总体设计方案主题鲜明 在目标明确的基础上，完成网站的构思创意即总体设计方案。对网站的整体风格和特色作出定位，规划网站的组织结构。 Web站点应针对所服务对象(机构或人)的不同而具有不同的形式。有些站点只提供简洁文本信息;有些则采用多媒体表现手法，提供华丽的图像、闪烁的灯光、复杂的页面布置，甚至可以下载声音和录像片段。好的Web站点把图形表现手法和有效的组织与通信结合起来。要做到主题鲜明突出，要点明确，以简单明确的语言和画面体现站点的主题。调动一切手段充分表现网站点的个性和情趣，办出网站的特点。Web站点主页应具备的基本成分包括: 页头:准确无误地标识你的站点和企业标志; Email 地址:用来接收用户垂询; 联系信息:如普通邮件地址或电话; 版权信息:声明版权所有者等。注意重复利用已有信息。如客户手册.公共关系文档.技术手册和数据库等可以轻而易举地用到企业的Web站点中。 三、网站的版式设计 网页设计作为一种视觉语言，要讲究编排和布局，虽然主页的设计不等同于平面设计但它们有许多相近之处，应充分加以利用和借鉴。版式设计通过文字图形的空间组合，表达出和谐与美。一个优秀的网页设计者也应该知道哪一段文字图形该落于何处，才能使整个网页生辉。多页面站点页面的编排设计要求把页面之间的有机联系反映出来，特别要处理好页面之间和页面内的秩序与内容的关系。为了达到最佳的视觉表现效果，应讲究整体布局的合理性，使浏览者有一个流畅的视觉体验。 四、色彩在网页设计中的作用
面向对象设计原则和23个 设计模式的笔记 面向对象三大特点： ---------------------------------- 封装： ------------------ 封装，也就是把客观事物封装成抽象的类，并且类可以把自己的数据和方法只让可信的类或者对象操作，对不可信的进行信息隐藏。 不关注处理过程了，只有对象和其职能。 只允许设定的对象访问自身信息，其余私人信息隐藏。 作用：封装可以隐藏实现细节，使得代码模块化，局域化，简单； 继承： ------------------ 继承的父类最好是接口，最好连属性都没有。 少用实现继承（库内使用较多），多用组合。 忘了多重继承，除非实现多接口。 作用：扩展已有代码模块；代码重用（库内使用较多），多态的基础 多态： ------------------ 静态--编程时采用父类型-针对接口编程
动态--执行时才实际映射成具体的子类 作用：静态时针对接口编程，执行时才体现实际的效果 面向对象设计原则： ------------------------------------ 单一职责原则（SRP）： ------------------ 就一个类而言，应该仅有一个引起它变化的原因；当职责越多，耦合越多，易遭破坏 软件设计真正要做的就是发现职责并将这些职责相互分离 把职责分离到单独的类中,因为每一个类都是变化的轴线，当需求变化时,该变化会反映为类的职责的变化，如果一个类承担了多余一个的职责,那么引起他变化的原因就会有多个。职责定义为“变化的原因”。 如果一个类承担的职责过多,就等于把这些职责耦合在了一起,一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力，这种耦合会导致脆弱的设计，当变化发生时，设计会受到意想不到的破坏。 另一方面，如果应用程序的变化方式总是导致这两个职责同时变化，那么就不必分离它们，实际分离它们就会导致不必要的复杂性的臭味。 SRP是所有原则中最简单的也是最难以正确应用的原则之一。 开放封闭原则： ------------------ 软件实体应该可以扩展，但是不可修改。 软件要容易维护又不容易出问题的最好方法是多扩展，少修改。 无论模块多么封闭，都会有无法封闭的变化，事先构造抽象隔离这些变化。 面对新需求，对程序的改动是通过增加新代码进行的，而不是更改现有的代码。
设计集团管控模式的六条原则 某市政工程有限公司成立于1993年，并于2001年在原公司基础上组建成立了X建设集团，经过短短十多年的发展，已经形成了一个以工程建设为核心，以地产开发为补充，以对外投资为支撑的集团公司，经营范围涵盖市政道桥、建筑安装、地产开发、材料生产、汽车销售、传媒教育、商贸物流、园区开发等多个领域。然而面对业务规模扩张、业务领域不断多元化、以及业务跨地域发展所带来的挑战，集团管理出现了多种“并发症”：集团总部定位不明确，对下属公司的管理仍然沿用原来的部门和分公司管理模式，管理效率低下；下属分子公司达到30多家，由于缺少具体分析，使用“一刀切”的管控模式，有的不该管的管得过死，有的该管的却又放得过宽；集团层面的管理输出能力不足，想发挥集团协同效应却缺乏足够的资源；缺乏管控的手段和科学的评估和监控手段……。 集团化是企业成长发展到一定阶段之后的必然选择，然而在长大的过程也免不了伴随着这些成长的烦恼。因此集团管控也就成了企业集团化绕不开的话题。 一、什么是集团管控模式 所谓企业集团的管控模式，是指集团对下属企业基于集分权程度不同而形成的管控策略，其具体体现在通过管控部门的设置、管控流程设计以及集团文化的传播来影响下属经营单位的战略、营销、财务、经营运作等方面的内容。集团管控模式的选择，说到底就是对集团集权与分权的度的把握，通过集权与分权的有机结合，实现整个集团各层级权、责、利的平衡。 二、集团管控的三种基本模式 企业集团对下属企业的管控模式，按照总部的集、分权程度不同可以划分为“操作管控型”、“战略管控型”和“财务管控型”三种基本管控模式。
操作管控型操作管控型的管控模式是高度集权的管控模式，强调过程控制是这种管控模式的鲜明特点。集团总部从战略规划制定到实施几乎什么都管，集团总部的各种职能管理非常深入，如人事管理不仅负责全集团的人事制度政策的制定，而且负责管理各下属公司二级管理团队及业务骨干人员的选拔、任聘。在实行这种管理模式的集团中各下属企业业务相关性高。为了保证总部能够正确决策并能应付解决各种问题，总部职能部门的人员会很多，规模会很庞大。在全球工业化开始的初期阶段，许多老牌全球性集团公司选择此种集团管控模式，以力保其全球随需而变的战略实施。操作管控型主要适用于以下情况：产权关系紧密度高，总部为投资中心和利润中心，而下属企业只是成本中心。 战略管控型战略管控型的管控模式是集权与分权相结合的一种管控模式，强调程序控制是这种管控模式的突出特点。集团总部负责整体的战略规划，下属企业同时也制定本业务单元的战略规划。在实行这种管控模式的集团中，集团总部的规模并不大，各下属企业业务的相关性也较高。运用这种管理模式的典型公司有英国石油、壳牌石油、飞利浦等。目前世界上大多数集团公司都采用或正在转向这种管控模式。战略管控型主要适用于以下情况：各下属企业业务相关性较高，产权关系紧密度较高，下属企业的业务运作比较成熟，对集团总部影响较大等。 财务管控型财务管控型的管控模式是最为分权的管控模式，强调结果控制是这种管控模式的突出特点。在实行这种管控模式的集团中，各下属企业业务的相关性可以很小。集团总部只负责集团的财务管理、资产运营、投资决策和实施监控等，以及对外部企业的收购、兼并工作。下属企业负责完成集团规定的财务目标。许多以收购、兼并为主要目标，且行业涉猎复杂的集团公司采用此类模式。GE公司也是采用这种管理模式，这种模式可以形象地表述为“有头脑，没有手脚。”财务管