迪米特法则用简单工厂来创建对象和用new创建对象相比好处有哪些

什么阶段要做体系结构设计

系结构设计在信息系统规模不断扩大、复杂程度高的情况下做，体系结构模式对信息系统性能的影响越来越大不同功能的信息系统对体系结构模式有不同的要求，各种体系结构模式的信息系统在开发和应用过程中也有很大的区别。

选择和设计合理的体系结构模式甚至比算法设计和数据结构设计更重要。

面向对象设计的原则是什么？

SRP　单一职责原则 就一个类而言，应该专注于做一件事和仅有一个引起它变化的原因。

OCP　开放－－封闭原则 对于扩展开放，对于修改封闭。

LSP　里氏替换原则 子（继承）类能在程序中代替父类（C#：基类，Java：超类）。

DIP 依赖倒置原则 抽象不依赖于细节，细节应该依赖抽象。

（面向抽象编程，C#为面向接口编程）。

ISP　接口隔离原则 接口属于用户类。

（接口面用用户类，不用想着和自身层次、方法相关） REP　重用发布等价原则 重用的粒度就是发布的粒度。

（？这个没有具体的认识） CCP　共同封闭原则 对于需求的响应，一个包中的所以类，有一个共同的响应（改变），而对于包外是不造成影响。

CRP 共同重用原则 包中的所有类共同重用，就是要重用就全部重用。

ADP 无环依赖原则 依赖关系不要存在环。

ADP 稳定依赖原则 朝着稳定的方向进行依赖。

SAP　稳定抽象原则 包的抽象程度应该和稳定程序一致。

嵌入式系统在硬件设计，操作系统的选择，以及软件的设计要遵循哪些原则

要把软件做得非常灵活又要便于维护是一个很困难的事情。

灵活的软件他的结构就复杂，维护起来就困难。

有得必有失，关键就在于如何处理这两者，使得大于失。

软件的设计开发应遵循以下六大原则：

1. OCP

全称：“Open-Closed Principle” 开放－封闭原则

说明：对扩展开放，对修改关闭。

优点：按照OCP原则设计出来的系统，降低了程序各部分之间的耦合性，其适应性、灵活性、稳定性都比较好。

当已有软件系统需要增加新的功能时，不需要对作为系统基础的抽象层进行修改，只需要在原有基础上附加新的模块就能实现所需要添加的功能。

增加的新模块对原有的模块完全没有影响或影响很小，这样就无须为原有模块进行重新测试。

如何实现“开-闭”原则

在面向对象设计中，不允许更改的是系统的抽象层，而允许扩展的是系统的实现层。

换言之，定义一个一劳永逸的抽象设计层，允许尽可能多的行为在实现层被实现。

解决问题关键在于抽象化，抽象化是面向对象设计的第一个核心本质。

对一个事物抽象化，实质上是在概括归纳总结它的本质。

抽象让我们抓住最最重要的东西，从更高一层去思考。

这降低了思考的复杂度，我们不用同时考虑那么多的东西。

换言之，我们封装了事物的本质，看不到任何细节。

在面向对象编程中，通过抽象类及接口，规定了具体类的特征作为抽象层，相对稳定，不需更改，从而满足“对修改关闭”；而从抽象类导出的具体类可以改变系统的行为，从而满足“对扩展开放”。

对实体进行扩展时，不必改动软件的源代码或者二进制代码。

关键在于抽象。

2. LSP

全称：“Liskov Substitution Principle” 里氏代换原则

说明：子类型必须能够替换它们的基类型。

一个软件实体如果使用的是一个基类，那么当把这个基类替换成继承该基类的子类，程序的行为不会发生任何变化。

软件实体察觉不出基类对象和子类对象的区别。

优点：可以很容易的实现同一父类下各个子类的互换，而客户端可以毫不察觉。

3. DIP

全称：“Dependence Inversion Principle”依赖倒置原则

说明：要依赖于抽象，不要依赖于具体。

客户端依赖于抽象耦合。

抽象不应当依赖于细节；细节应当依赖于抽象；

要针对接口编程，不针对实现编程。

优点：使用传统过程化程序设计所创建的依赖关系，策略依赖于细节，这是糟糕的，因为策略受到细节改变的影响。

依赖倒置原则使细节和策略都依赖于抽象，抽象的稳定性决定了系统的稳定性。

怎样做到依赖倒置？

以抽象方式耦合是依赖倒转原则的关键。

抽象耦合关系总要涉及具体类从抽象类继承，并且需要保证在任何引用到基类的地方都可以改换成其子类，因此，里氏代换原则是依赖倒转原则的基础。

在抽象层次上的耦合虽然有灵活性，但也带来了额外的复杂性，如果一个具体类发生变化的可能性非常小，那么抽象耦合能发挥的好处便十分有限，这时可以用具体耦合反而会更好。

层次化：所有结构良好的面向对象构架都具有清晰的层次定义，每个层次通过一个定义良好的、受控的接口向外提供一组内聚的服务。

依赖于抽象：建议不依赖于具体类，即程序中所有的依赖关系都应该终止于抽象类或者接口。

尽量做到：

1、任何变量都不应该持有一个指向具体类的指针或者引用。

2、任何类都不应该从具体类派生。

3、任何方法都不应该覆写它的任何基类中的已经实现的方法。

4. ISP

全称：“Interface Segregation Principle” 接口隔离原则

说明：使用多个专一功能的接口比使用一个的总接口总要好。

从一个客户类的角度来讲：一个类对另外一个类的依赖性应当是建立在最小接口上的。

过于臃肿的接口是对接口的污染，不应该强迫客户依赖于它们不用的方法。

优点：会使一个软件系统功能扩展时，修改的压力不会传到别的对象那里。

如何实现接口隔离原则

不应该强迫用户依赖于他们不用的方法。

1、利用委托分离接口。

2、利用多继承分离接口。

5. CARP or CRP

全称：“Composite/Aggregate Reuse Principle” 合成/聚合复用原则 or “Composite Reuse Principle” 合成复用原则

说明：如果新对象的某些功能在别的已经创建好的对象里面已经实现，那么尽量使用别的对象提供的功能，使之成为新对象的一部分，而不要自己再重新创建。

新对象通过向这些对象的委派达到复用已有功能的。

简而言之，要尽量使用合成/聚合，尽量不要使用继承。

优点：

1) 新对象存取成分对象的唯一方法是通过成分对象的接口。

2) 这种复用是黑箱复用，因为成分对象的内部细节是新对象所看不见的。

3) 这种复用支持包装。

4) 这种复用所需的依赖较少。

5) 每一个新的类可以将焦点集中在一个任务上。

6) 这种复用可以在运行时间内动态进行，新对象可以动态的引用与成分对象类型相同的对象。

7) 作为复用手段可以应用到几乎任何环境中去。

缺点:

就是系统中会有较多的对象需要管理。

6. LOD or LKP

全称：“Law of Demeter” 迪米特原则 or “Least Knowledge Principle” 最少知识原则

说明：对象与对象之间应该使用尽可能少的方法来关联，避免千丝万缕的关系。

如何实现迪米特法则

迪米特法则的主要用意是控制信息的过载，在将其运用到系统设计中应注意以下几点：

1) 在类的划分上，应当创建有弱耦合的类。

类之间的耦合越弱，就越有利于复用。

2) 在类的结构设计上，每一个类都应当尽量降低成员的访问权限。

一个类不应当public自己的属性，而应当提供取值和赋值的方法让外界间接访问自己的属性。

3) 在类的设计上，只要有可能，一个类应当设计成不变类。

4) 在对其它对象的引用上，一个类对其它对象的引用应该降到最低。

还有个单一职责原则：

SRP简介（SRP--Single-Responsibility Principle）： 就一个类而言，应该只专注于做一件事和仅有一个引起它变化的原因。

所谓职责，我们可以理解他为功能，就是设计的这个类功能应该只有一个，而不是两个或更多。

也可以理解为引用变化的原因，当你发现有两个变化会要求我们修改这个类，那么你就要考虑撤分这个类了。

因为职责是变化的一个轴线，当需求变化时，该变化会反映类的职责的变化。

使用SRP注意点： 1、一个合理的类，应该仅有一个引起它变化的原因，即单一职责； 2、在没有变化征兆的情况下应用SRP或其他原则是不明智的； 3、在需求实际发生变化时就应该应用SRP等原则来重构代码； 4、使用测试驱动开发会迫使我们在设计出现臭味之前分离不合理代码； 5、如果测试不能迫使职责分离，僵化性和脆弱性的臭味会变得很强烈，那就应该用Facade或Proxy模式对代码重构； SRP优点： 消除耦合，减小因需求变化引起代码僵化性臭味

用简单工厂来创建对象和用new创建对象相比好处有哪些

设计模式做为程序员的“内功心法”，越来越受到 社区的重视，这种变化是很可喜的，Java社区走在了我们的前面，但这种状况 也许有一天会发生改变。

从追MM谈Java的23种设计模式 1、FACTORY—追MM少不了请吃饭了，麦当劳的鸡翅和肯德基的鸡翅都是MM爱吃的东西，虽然口味有所不同，但不管你带MM去麦当劳或肯 德基，只管向服务员说“来四个鸡翅”就行了。

麦当劳和肯德基就是生产鸡翅的Factory. 工厂模式：客户类和工厂类分开。

消费者任何时候需要某种产品，只需向工厂请求即可。

消费者无须修改就可以接纳新产品。

缺点 是当产品修改时，工厂类也要做相应的修改。

如：如何创建及如何向客户端提供。

程序代码 以下是引用片段： 以下是引用片段： public class Factory{ public String Boy = "boy" ; public String Girl = "girl" ; public People getPeople (String people){ if (people.equals("boy")){ return new Boy(); }else if(people.equals("girl")){ return new Girl(); } } } 2、BUILDER—MM最爱听的就是“我爱你”这句话了，见到不同地方的MM,要能够用她们的方言跟她说这句话哦，我有一个多种语言翻译 机，上面每种语言都有一个按键，见到MM我只要按对应的键，它就能够用相应的语言说出“我爱你”这句话了，国外的MM也可以轻松搞掂，这 就是我的“我爱你”builder。

(这一定比美军在伊拉克用的翻译机好卖) 建造模式：将产品的内部表象和产品的生成过程分割开来，从而使一个建造过程生成具有不同的内部表象的产品对象。

建造模式使得 产品内部表象可以独立的变化，客户不必知道产品内部组成的细节。

建造模式可以强制实行一种分步骤进行的建造过程。

3、FACTORY METHOD—请MM去麦当劳吃汉堡，不同的MM有不同的口味，要每个都记住是一件烦人的事情，我一般采用Factory Method模 式，带着MM到服务员那儿，说“要一个汉堡”，具体要什么样的汉堡呢，让MM直接跟服务员说就行了。

工厂方法模式：核心工厂类不再负责所有产品的创建，而是将具体创建的工作交给子类去做，成为一个抽象工厂角色，仅负责给出 具体工厂类必须实现的接口，而不接触哪一个产品类应当被实例化这种细节。

4、PROTOTYPE—跟MM用QQ聊天，一定要说些深情的话语了，我搜集了好多肉麻的情话，需要时只要copy出来放到QQ里面就行了，这就是 我的情话prototype了。

(100块钱一份，你要不要) 原始模型模式：通过给出一个原型对象来指明所要创建的对象的类型，然后用复制这个原型对象的方法创建出更多同类型的对象。

原始模型模式允许动态的增加或减少产品类，产品类不需要非得有任何事先确定的等级结构，原始模型模式适用于任何的等级结构。

缺点是每 一个类都必须配备一个克隆方法。