手机端网站开发价格,wordpress升级主题,永州企业网站建设价格,wordpress 替换googleapi面向对象设计原则是一组指导软件设计的原则#xff0c;其中GRASP#xff08;General Responsibility Assignment Software Patterns#xff09;是其中的一部分。这些原则帮助设计者确定类应该负责执行哪些职责#xff0c;以及如何分配这些职责。在下面的文档中#xff0c;…面向对象设计原则是一组指导软件设计的原则其中GRASPGeneral Responsibility Assignment Software Patterns是其中的一部分。这些原则帮助设计者确定类应该负责执行哪些职责以及如何分配这些职责。在下面的文档中我们将详细介绍九大GRASP原则并提供Java语言的代码示例以便更好地理解这些原则的应用。
1. Information Expert信息专家
原则 Information Expert原则建议一个类应该负责处理自身拥有的信息或者说一个拥有必要信息的类应该负责执行相关操作。
详细说明 Information Expert关注的是哪个类在执行一个操作时最具有相关的信息。如果某个类拥有完成某个职责所需要的所有信息那么它就是信息专家。这有助于确保每个类都在处理与自身职责相关的任务。
理解当我们不确定某个职责该分配给类A还是类B的时候我们可以遵循这个原则。这个设计原则和单一设计原则不同单一职责原则考虑的是单个类中的职责是否都属于一类职责。而信息专家模式考虑则是该把该同一类职责放进类A还是类B中。假设我们有一个长方形Rectangle类类中有width和height属性和一个Measure类我们应该把getArea()方法放进Rectangle中去还是将width和height参数传给Measure类在Measure中实现getArea()呢依照该准则既然Rectangle方法已经有了实现getArea()所必须的属性的话那么就把该把getArea()方法放进Retangle类中。同理如果有一个计算属性呢假设是长宽高比例widthHeightRatio的话也遵循该原则。
举例 考虑一个图书管理系统有一个Book类表示图书信息
class Book {private String title;private String author;// 构造函数、访问器和其他方法public void displayBookInfo() {System.out.println(Title: title , Author: author);}
}
在这个例子中Book类是信息专家因为它拥有并处理有关图书的信息。
2. Creator创建者
原则 Creator原则建议一个类应该创建与之关联或组合的类的实例。
如果符合下面的一个或者多个条件则可将创建类A实例的职责分配给类B
B包含AB聚合AB拥有初始化A的数据并在创建类A的实例时将数据传递给类AB记录A的实例B频繁使用A。
详细说明 Creator原则指导在哪个类应该负责创建与其关联的对象实例。这有助于确保对象的创建与其使用者解耦提高系统的灵活性和可维护性。
**理解**在面向对象的设计当中无法避免去创建对象。假设对象B创建对象A那么对象B就产生了与对象A的耦合。而这种耦合是无法消除的即使你将创建对象A的职责分配给对象C这种耦合还是存在的只是从对象B转移到对象C上系统内还是依然存在这个耦合无法避免。那么当我们无法消除耦合的时候我们应该考虑的是如何降低这个耦合的耦合度。这个原则给出了指导方针。以上的几个条件潜在的表明了其实B已经对A有了耦合既然B已经存在了对A的耦合那么我们不妨再将创建A的职责分配给他。这样分配的话系统内仅存在一个A与B的耦合。如果将创建A的职责分配给C的话那么系统内就会存在B与A(B包含A、B频繁使用A等条件)和C与A这两个耦合。
举例 考虑一个在线购物系统有一个ShoppingCart类和一个Order类
class ShoppingCart {public Order createOrder() {return new Order();}
}
在这个例子中ShoppingCart类是创建者负责创建与其关联的Order类的实例。
3. Controller控制器
原则 把接收或者处理系统事件消息的职责分配给一个类。这个类可以代表整个系统、设备或者子系统系统事件发生时对应的用例场景在相同的用例场景中使用相同的控制器来处理所有的系统事件。。
详细说明 Controller原则有助于维护系统的一致性和可扩展性。它指导在哪个类应该负责协调和控制系统的活动。
**理解**一个控制器是负责接收或者处理事件的组件对象。MVC模式中的C就是控制器模式。而一个控制器应该处理一类事件。例如我们项目中经常会有的UserController就承担添加用户删除用户的事件。一个子系统需要定义多个控制器分别对应不同的事件处理。一般来说控制器应当把要完成的功能委托给Service或者其他业务处理对象它只负责协调和控制业务流程尽量不要包含太多业务逻辑。
举例 假设有一个在线购物系统包含ShoppingCart和PaymentProcessor两个类。在这里Controller原则建议将购物车和支付的控制逻辑分配给一个独立的控制器类比如ShoppingCartController
4. Low Coupling低耦合
原则 Low Coupling原则建议尽量减少类之间的依赖关系。
以下是一些耦合关系的体现
A具有一个B类型的属性A调用B的方法A的方法包含对B的引用如方法参数类型为B或返回类型为BA是B的直接或者间接子类B是一个接口A实现了该接口。
详细说明 低耦合有助于系统的可维护性和可扩展性因为当一个类的改变不会影响到其他类时系统更容易进行修改和更新。
**理解**在以上的这些耦合条件中出现得越多代表耦合程度越高。这些条件简单笼统的来说就是A对B的“感知”。这种感知体现在对象属性、方法参数、方法返回值以及接口上面。高耦合的类过多地依赖其他类这种设计将会导致一个类的修改导致其他类产生较大影响系统难以维护和理解。在重用一个高耦合的类时不得不重用它所依赖的其他类系统重用性差。如何降低耦合的程度有以下一些方法尽量减少对其他类的引用提高方法和属性的访问权限尽量使用组合/聚合原则来替代继承。其实面向对象编程中的多态就是一种降低类型耦合的方法如果没有多态的话我们的方法需要知道所有子类类型而多态的话只需要知道父类即可。降低了类型耦合。
举例 考虑一个图书馆管理系统有一个Library类和一个Book类。使用聚合来减少类之间的依赖关系
class Library {private ListBook books;public void addBook(Book book) {books.add(book);}
}
在这个例子中Library类通过聚合的方式引入了Book类实现了低耦合。
5. High Cohesion高内聚
原则 High Cohesion原则建议一个类应该有高度相关的职责即一个类应该专注于一个功能领域。
详细说明 高内聚有助于确保一个类的方法和属性彼此关联从而提高类的可读性和可维护性。
**理解**很直观的例子就是如果类的功能都是高内聚并职责单一的类的复杂性就降低了复杂性降低导致维护的成本也就降低了。在传统的Dao设计模式当中我们应该尽量拆分细粒度职责单一的Dao供Service进行调用。在Service当中哪一类的数据操作调用哪一个Dao就显而易见并且单个Dao不会太过膨胀导致维护性变差。高内聚也代表了高隔离高隔离就意味着在修改某一个方法的时候不至于影响到太多其他类。 Springboot的三层架构就是高内聚的体现把不同的操作分给不同的文件使得内容专一 举例 考虑一个汽车管理系统有一个Car类
class Car {private Engine engine;private Transmission transmission;// 相关的汽车功能方法
}
在这个例子中Car类具有高内聚性因为它包含了与汽车相关的引擎和传动系统。
6. Polymorphism多态
原则 Polymorphism原则建议使用多态性来实现通用性和灵活性。
详细说明 多态性允许以通用的方式处理不同类型的对象从而提高系统的灵活性和可扩展性。
**理解**在面向对象的设计当中经常要根据对象的类型来进行对应的操作。假设我们有一个画图Draw类有多个图形类Rectangle、Circle、Square。如果要按照不同图形类进行绘制的话就需要在Draw类的方法中使用if-else的程序结构依次判断类型进行绘制。如果新增一个图形类的话就又需要对这段代码进行更改。这就违反了开闭原则。而采用多态的形式将绘制的具体步骤交给图形类的子类实现。就不用使用if-else的程序结构在新增图形类的时候也不需要修改Draw类。通过引入多态子类对象可以覆盖父类对象的行为更好地适应变化。策略模式、工厂方法模式就是关于多态比较好的例子。
举例 考虑一个图形绘制系统有一个Shape接口和具体的实现类
interface Shape {void draw();
}class Circle implements Shape {Overridepublic void draw() {// 绘制圆形的逻辑}
}class Square implements Shape {Overridepublic void draw() {// 绘制正方形的逻辑}
}
在这个例子中Shape接口和具体的实现类展示了多态的概念。
7. Pure Fabrication纯虚构
原则 原则建议可以创建一个不代表真实世界概念的类以实现低耦合、高内聚的目标。
详细说明 纯虚构的类可能不对应实际系统中的实体但它们有助于组织和分离系统的不同部分从而提高系统的可维护性。
**理解**在OO设计时系统内的大多数类都是来源于现实世界中的真实类领域模型。然而在给这些类分配职责时有可能会遇到一些很难满足低耦合高内聚的设计原则。纯虚构模式对这一问题给出的方案是给人为制造的类分配一组高内聚的职责该类并不代表问题领域的概念而代表虚构出来的事物。比较明显的一个例子就是适配器模式通过虚构出适配器这么一个概念来解耦两个对象之间的耦合。
适配器类举例
在适配器模式中适配器类是一个纯虚构类它没有对应于真实世界中的实体而是引入为了解决两个不同接口之间的耦合问题。
适配器模式的场景
假设有一个现有的系统其中包含一个接口 OldInterface而你引入了一个新的类 NewClass它实现了一个新的接口 NewInterface。现在你想要在系统中使用 NewClass但是由于 OldInterface 和 NewInterface 不兼容需要一个适配器来使它们协同工作。
适配器模式的类结构
OldInterface现有系统的接口。NewInterface新引入的接口。NewClass实现了 NewInterface 的新类。Adapter适配器这是纯虚构的类它的唯一目的是将 NewClass 适配到 OldInterface 中。
Java 代码示例
// 现有系统的接口
interface OldInterface {void oldMethod();
}// 新引入的接口
interface NewInterface {void newMethod();
}// 新的类实现了新接口
class NewClass implements NewInterface {public void newMethod() {System.out.println(NewClass implements NewInterface);}
}// 适配器类纯虚构的类目的是适配 NewClass 到 OldInterface
class Adapter implements OldInterface {private NewClass adaptee;public Adapter(NewClass adaptee) {this.adaptee adaptee;}public void oldMethod() {adaptee.newMethod();}
}// 客户端代码
public class Client {public static void main(String[] args) {NewClass newClass new NewClass();Adapter adapter new Adapter(newClass);// 使用适配器调用现有系统的接口adapter.oldMethod();}
}
在这个例子中Adapter 类是一个纯虚构的类它没有现实世界的对应。它的目的是通过调用 NewClass 的方法来适配 OldInterface从而使得现有系统能够与新的类协同工作解决了接口不兼容的问题。这就是纯虚构的一个实际应用场景。
许多项目都需要对数据库进行操作将系统中的一些对象进行持久化。信息专家模式给出的建议是将持久化的职责分配给具体的每一个模型类。但是这种建议已经被证明是不符合高内聚低耦合原则的。于是现在的做法往往会在项目中加入类似于DAO或者Repository这样的类。这些类在领域模型中是并不存在的。 纯虚构原则就是为了解决信息专家的弊端的。信息专家强调把功能放在一起那么假如有一个查询学生id的操作信息专家就是要求数据库操作代码放在学生类中那么我又要查询教师id又要把数据库操作代码写在教师类这样代码复用性不强纯虚构类就是提出一个虚构的dao来达到解耦消除冗余的作用 8. Indirection间接
原则 Indirection原则建议通过引入一个中介者或者通过委托来降低类之间的耦合度。
详细说明 通过间接方式减少类之间的直接依赖关系有助于提高系统的灵活性和可维护性。
理解“中介”简单来说就是通过一个中间人来处理一件事。本来直接联系的两个对象可以通过另一个中间对象进行交互这样做便实现了隔离和解耦一个对象的变动不会影响另一个对象仅会影响到中间对象。在设计模式当中的适配器模式桥接模式都采用了一个中间对象来进行解耦。
举例 考虑一个购物系统有一个PaymentGateway类
class PaymentGateway {public void processPayment(Order order) {// 处理支付逻辑}
}class ShoppingCart {private PaymentGateway paymentGateway;public void checkout() {paymentGateway.processPayment(this.order);}
}
在这个例子中ShoppingCart类通过间接的方式使用了PaymentGateway类来处理支付逻辑降低了直接依赖的耦合度。
9. Protected Variations受保护的变化
原则 Protected Variations原则建议保护系统的稳定性通过封装不稳定的因素。
详细说明 当系统中的某个元素类、模块等可能会发生变化时为了保护其他元素不受这个变化的影响我们应该定义一个稳定的接口。通过这个接口其他元素与变化点进行交互而不是直接与变化点的具体实现交互。这样如果未来变化发生我们只需要修改接口的实现而不影响其他部分的代码。
解决方案
识别不稳定的变化点 在设计中预先识别哪些部分可能发生变化哪些是相对稳定的。这可以通过对需求、技术选型等方面的分析来实现。定义稳定的接口 为变化点定义一个稳定的接口其他元素只与这个接口进行交互。这样即使变化点发生了变化其他元素也不会受到直接影响。通过接口扩展新功能 如果未来发生变化我们可以通过扩展接口来添加新的功能而不需要修改原来的实现。这种扩展性使得系统更容易适应变化。
示例
考虑一个文件读取的例子我们可以定义一个 FileReader 接口并有两个不同的实现类 PlainTextFileReader 和 BinaryFileReader。其他模块只需要与 FileReader 接口交互而不需要直接与具体的文件读取实现交互。如果未来需要支持新的文件类型我们只需扩展 FileReader 接口而不需要修改其他部分的代码。
public interface FileReader {String read(String filePath);
}public class PlainTextFileReader implements FileReader {public String read(String filePath) {// 读取纯文本文件的实现}
}public class BinaryFileReader implements FileReader {public String read(String filePath) {// 读取二进制文件的实现}
}
通过这样的设计我们保护了其他模块免受文件读取实现的变化的影响实现了受保护变化的原则。
设计模式
适配器
问题如何解决不相容的接口问题或者如何为具有不同接口的类似构件提供稳定的接口
解决方案通过中介适配器对象将构件的原有接口转换为其他接口
将一个类的接口转换成客户希望的另外一个接口Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
如何体现
使用多态和接口增加一层间接性对象
