在面向对象的开发中，主要遵循的有以下6个设计原则：
单一职责 ，开放封闭 ，里氏代换，依赖倒转，迪米特法则，合成/聚合复用
下面将具体介绍这些设计原则：
单一职责原则：就一个类而言，应该仅有一个引起它发生变化的原因
如果一个类的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱这个或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当发生变化时，这种高耦合会导致意想不到的变化
开放封闭原则:软件实体(类，模块，函数等等)应该可以扩展，但是不能修改
面对需求的时候，对程序的改动是通过增加新的代码来完成的，而不是通过对原代码的改变来完成，对于原代码的改变很麻烦，可能会导致意想不到的错误
开放封闭原则是面向对象设计的核心所在，遵循这个原则，实现了可维护，可扩展，可复用，灵活性好，开发人员应该进队程序中呈现出频繁变化的那些部分作出抽象，但是也不能可以地对每一个部分进行抽象，拒绝不成熟的抽象一样很重要
个人理解：简单工厂模式并不是属于23中设计模式之一，主要就是因为简单工厂模式不符合开放封闭的原则，在类里面增加switch...case语句，当有新的功能或者是类的时候，就要修改该工厂类，代码的可维护性减低了
里氏代换原则：子类型必须能够替换掉他们的父类型
只有当子类可以替换到父类，软件单位的功能不受到影响的时候，父类才能真正被复用，而子类也能够在父类的基础上增加新的行为
如果没有里氏代换原则，我们在开发的时候如果改变了子类的行为，同时对父类产生了影响，这样你要修改子类，也就必须要修改父类了。
依赖倒转原则：也叫依赖倒置原则，其内容如下：
A：高层模块不应该依赖底层模块，两个都应该抽象
B：抽象不应该依赖细节，细节应该依赖抽象
倒转，假如用户的需求需要改变，软件开发的时候你用的是db2数据库，但是最后要改为mysql数据库，由于高层的模块依赖的是底层的模块，这就使得底层模块也要做修改。但是如果高层模块依赖的是接口或者是抽象类的话，因为接口和抽象类是不变的，所以如果你要更改数据库的话，就不怕出现混乱，A和B两个说的都是这样的意思。因为依赖的是抽象类或者接口，有里氏代换规则可以知道，子类的变化对于父类造不成影响。
针对上面的例子，我们可以做一个抽象的数据库的类，让db2继承这个抽象类，加入现在要换为mysql数据库，只要让mysql去继承这个类就可以，不管用哪个数据库，我们都建立的是抽象数据类的引用，用它去指向你要访问的类就ok了
迪米特法则：如果两个类之间不必发生彼此直接通信，那么这两个类就不应当发生直接的相互引用。如果其中一个类需要调用另一个类的某个方法的话，可以通过第三者转发这个调用
对于这个原则，我是这样理解的，两个类之间相互知道了解，就是将一个类直接暴露给了另外一个类，这样子违反了信息的隐藏。如果多个类之间需要两两发生调用的话，那么就需要调用者知道被调用这的全部信息，这是我们可以通过一个中介来转发需要通信的两个类之间的请求，所有的类，只需要将自己暴露给中介就可以了，不需要给被调用者，这样做简化了代码，这也就是设计模式中的中介者模式
这样降低了类与类之间的耦合性，符合我们提倡的低耦合的观点，耦合性越弱，越有利于复用，一个处在弱耦合的类被修改，不会对有关系的类造成波及
合成/聚合复用原则：尽量使用合成/聚合，尽量不要使用类继承
这样的好处有助于保持每个类被封装，并被集中在单个任务上，这样类和继承层级会保持较小的规模，并且不太可能增长为不可控制的庞然大物
拿桥接模式来举例，加入不同的手机品牌，有不同的软件，每种软件都要安装在不同的手机上面，如果这个时候用继承的话，每个具体手机品牌继承抽象类手机品牌，然后在每个手机品牌下面都有每个软件的使用，这样一个软件被实现了很多次，每个手机品牌都可以对其实现，如果我们要新增加一个软件的话，每个具体的手机品牌就又要分别实现，这样违反了可维护性。
这时候我们可以让软件成为手机品牌的一个组成部分，他们之间的关系是组合关系，只需要写一个具体的软件抽象类，然后让每个具体的软件去继承这个抽象类，这个时候如果要增加软件实现类，只需要增加一个具体的实现类就可以了
以上是我学习《大话设计模式》对于面向对象设计所遵循的六个设计原则的总结，希望对您有用。