熟悉GRASP原则，并撰写心得回答设计模式是怎样解决设计问题的？在实际编程中怎样选择设计模式？以及如何使用设计模式。

熟悉Grasp，并撰写心得回答设计模式是怎样解决设计问题的，在实际编程中是如何使用的？

Part1

Grasp介绍

GRASP，全称为General Responsibility Assignment Software Pattern，即通用职责分配软件模式，它由《UML和模式应用》(Applying UML and Patterns)一书作者Craig Larman提出。与其将它们称之为设计模式，不如称之为设计原则，因为它是站在面向对象设计的角度，告诉我们怎样设计问题空间中的类与分配它们的行为职责，以及明确类之间的相互关系等，而不像GoF模式一样是针对特定问题而提出的解决方案。因此GRASP站在一个更高的角度来看待面向对象软件的设计，它是GoF设计模式的基础。GRASP是对象职责分配的基本原则，其核心思想是职责分配(Responsibility Assignment)，用职责设计对象(Designing Objects with Responsibilities)。它包含如下9个基本特征或原则：

1、信息专家：将职责分配给拥有履行一个职责所必需信息的类，即信息专家。

信息专家模式是面向对象设计的最基本原则。通俗点来讲，就是一个类只干该干的事情，不该干的事情不干。在系统设计时，需要将职责分配给具有实现这个职责所需要信息的类。信息专家模式对应于面向对象设计原则中的单一职责原则。

  例如：常见的网上商店里的购物车(ShopCar),需要让每种商品(SKU)只在购物车内出现一次，购买相同商品，只需要更新商品的数量即可。如下图：

针对这个问题需要权衡的是，比较商品是否相同的方法需要放到那里类里来实现呢？分析业务得知需要根据商品的编号(SKUID)来唯一区分商品，而商品编号是唯一存在于商品类里的，所以根据信息专家模式，应该把比较商品是否相同的方法放在商品类里。

2、创造者

如果符合下面的一个或者多个条件，则可将创建类A实例的职责分配给类B：

B包含A；
B聚合A；
B拥有初始化A的数据并在创建类A的实例时将数据传递给类A；
B记录A的实例；
B频繁使用A。
      此时，我们称类B是类A对象的创建者。如果符合多个条件，类B聚合或者包含类A的条件优先。

3、低耦合

耦合是评价一个系统中各个元素之间连接或依赖强弱关系的尺度，具有低耦合的元素不过多依赖其他元素。此处的元素可以是类，也可以是模块、子系统或者系统。具有高耦合的类过多地依赖其他类，这种设计将会导致：一个类的修改导致其他类产生较大影响；系统难以维护和理解；系统重用性差，在重用一个高耦合的类时不得不重用它所依赖的其他类。因此需要对高耦合的系统进行重构。

类A和类B之间的耦合关系体现如下：A具有一个B类型的属性；A调用B的方法；A的方法包含对B的引用，如方法参数类型为B或返回类型为B；A是B的直接或者间接子类；B是一个接口，A实现了该接口。低耦合模式鼓励在进行职责分配时不增加耦合性，从而避免高耦合可能产生的不良后果。在进行类设计时，需要保持类的独立性，减少类变更所带来的影响，它通常与信息专家模式和高内聚模式一起出现。

4、高内聚

     内聚是评价一个元素的职责被关联和关注强弱的尺度。如果一个元素具有很多紧密相关的职责，而且只完成有限的功能，则这个元素就具有高内聚性。此处的元素可以是类，也可以是模块、子系统或者系统。

      在一个低内聚的类中会执行很多互不相关的操作，这将导致系统难于理解、难于重用、难于维护、过于脆弱，容易受到变化带来的影响。因此我们需要控制类的粒度，在分配类的职责时使其内聚保持为最高，提高类的重用性，控制类设计的复杂程度。为了达到低内聚，我们需要对类进行分解，使得分解出来的类具有独立的职责，满足单一职责原则。在一个类中只保留一组相关的属性和方法，将一些需要在多个类中重用的属性和方法或完成其他功能所需的属性和方法封装在其他类中。类只处理与之相关的功能，它将与其他类协作完成复杂的任务。

5、控制器

        一个控制器是负责接收或者处理系统事件的非图形用户界面对象。一个控制器定义一组系统操作方法。在控制器模式中，要求系统事件的接收与处理通常由一个高级类来代替；一个子系统需要定义多个控制器，分别对应不同的事务处理。通常，一个控制器应当把要完成的功能委托给其他对象，它只负责协调和控制，本身不完成太多的功能。它可以将用户界面所提交的请求转发给其他类来处理，控制器可以重用，且不能包含太多业务逻辑，一个系统通常也不能设计一个统一的控制器。控制器模式与MVC模式相对应，而MVC是一种比设计模式更加高级的架构模式。 

6、多态

        由条件变化引发同一类型的不同行为是程序的一个基本主题。如果用if-else或switch-case等条件语句来设计程序，当系统发生变化时必须修改程序的业务逻辑，这将导致很难方便地扩展有新变化的程序。另外对于服务器/客户端结构中的可视化组件，有时候需要在不影响客户端的前提下，将服务器的一个组件替换成另一个组件。此时可以使用多态来实现，将不同的行为指定给不同的子类，多态是设计系统如何处理相似变化的基本方法，基于多态分配职责的设计可以方便地处理新的变化。在使用多态模式进行设计时，如果需要对父类的行为进行修改，可以通过其子类来实现，不同子类可以提供不同的实现方式，将具体的职责分配给指定的子类。新的子类增加到系统中也不会对其他类有任何影响，多态是面向对象的三大基本特性之一（另外两个分别是封装和继承），通过引入多态，子类对象可以覆盖父类对象的行为，更好地适应变化，使变化点能够“经得起未来验证”。多态模式在多个GoF设计模式中都有所体现，如适配器模式、命令模式、组合模式、观察者模式、策略模式等等。

7、纯虚构

        纯虚构模式用于解决高内聚和低耦合之间的矛盾，它要求将一部分类的职责转移到纯虚构类中，在理想情况下，分配给这种虚构类的职责是为了达到高内聚和低耦合的目的。在实际操作过程中，纯虚构有很多种实现方式，例如将数据库操作的方法从数据库实体类中剥离出来，形成专门的数据访问类，通过对类的分解来实现类的重用，新增加的数据访问类对应于数据持久化存储，它不是问题域中的概念，而是软件开发者为了处理方便而产生的虚构概念。纯虚构可以消除由于信息专家模式带来的低内聚和高耦合的坏设计，得到一个具有更好重用性的设计。在系统中引入抽象类或接口来提高系统的扩展性也可以认为是纯虚构模式的一种应用。纯虚构模式通常基于相关功能的划分，是一种以功能为中心的对象或行为对象。在很多设计模式中都体现了纯虚构模式，例如适配器模式、策略模式等等。

8、中介

         “中介”顾名思义，就是这个事不能直接来办，需要绕个弯才行。绕个弯的好处就是，本来直接会连接在一起的对象彼此隔离开了，一个的变动不会影响另一个。就像前面的低耦合模式里说的一样，“两个不同模块的内部类之间不能直接连接”，但是我们可以通过中间类来间接连接两个不同的模块，这样对于这两个模块来说，他们之间仍然是没有耦合/依赖关系的。

9、受保护变化

         受保护变化模式简称PV，它是大多数编程和设计的基础，是模式的基本动机之一，它使系统能够适应和隔离变化。它与面向对象设计原则中的开闭原则相对应，即在不修改原有元素（类、模块、子系统或系统）的前提下扩展元素的功能。开闭原则又可称为“可变性封装原则(Principle of Encapsulation of Variation, EVP)”，要求找到系统的可变因素并将其封装起来。如将抽象层的不同实现封装到不同的具体类中，而且EVP要求尽量不要将一种可变性和另一种可变性混合在一起，这将导致系统中类的个数急剧增长，增加系统的复杂度。在具体实现时，为了符合受保护变化模式，我们通常需要对系统进行抽象化设计，定义系统的抽象层，再通过具体类来进行扩展。如果需要扩展系统的行为，无须对抽象层进行任何改动，只需要增加新的具体类来实现新的业务功能即可，在不修改已有代码的基础上扩展系统的功能。大多数设计原则和GoF模式都是受保护变化模式的体现。

Part2

关于设计模式解决设计问题和实际中使用设计模式的心得：

        本学期软件构造课程即将结束，12周的课程主要从模块化软件构造、软件构造的质量目标、面向可复用性的软件构造、面向可维护性软件构造、面向对象的软件构造和面向健壮性的软件构造几大方面进行了深度的学习，同时，我们也从适配器模式、装饰模式、外观模式、策略模式、模板模式、迭代器模式入手，对相关的设计模式进行了理解并完成了实验，总之，从课堂和实验中能感觉到个人的软件设计思维和对高效的软件工程设计模型方法的理解达到了一定的层次，软件构造课程对于当下正在学习spring、springboot框架，利用这些高效的框架练习商业软件项目的同学来说正好起到了很好的知识穿透学习作用，我们能从微观框架的设计和宏观代码编写、测试上更好地把握一个软件作品的设计，也更加深了对面向对象编程的理解，以下即是本人通过本次学习后关于利用设计模式解决问题的心得。

        首先，设计模式对面向对象设计过程中的相关问题是有多种解决方法的，我认为解决问题首先即是要根据问题本身寻找合适的对象，面向对象程序由对象组成，对象包括数据和对数据进行操作的过程。对象在收到客户的请求(或消息)后，执行相应的操作。客户请求是使对象执行操作的唯一方法，操作又是对象改变内部数据的唯一方法。由于这些限制，对象的内部状态是被封装的，它不能被直接访问，它的表示对于对象外部是不可见的。面向对象设计最困难的部分是将系统分解成对象集合。因为要考虑许多因素：封装、粒度、依赖关系、灵活性、性能、演化、复用等等，它们都影响着系统的分解，并且这些因素通常还是互相冲突的。面向对象设计方法学支持许多设计方法。你可以写出一个问题描述，挑出名词和动词，进而创建相应的类和操作；或者，你可以关注于系统的协作和职责关系；或者，你可以对现实世界建模，再将分析时发现的对象转化至设计中。设计的许多对象来源于现实世界的分析模型。但是，设计结果所得到的类通常在现实世界中并不存在，有些是像数组之类的低层类，而另一些则层次较高。

         其次，我们要确定对象的粒度，它的意思即是对象在大小和数目上变化极大，它们能表示下自硬件或上自整个应用的任何事物，因而我们常常无法有效的描述这个待确定的对象，而在设计模式中，外观模式就很好地描述了怎样用对象表示完整的子系统，享元模式描述了如何支持大量的最小粒度的对象，抽象工厂模式和建造者模式产生哪些专门负责生成其他对象的对象，访问者模式和命令模式生成的对象那个负责实现对其他对象或对象组的请求。

        第三点我们要指定对象接口，在面向对象系统中，接口是基本的组成部分。对象只有通过它们的接口才能与外部交流，如果不通过对象的接口就无法知道对象的任何事情，也无法请求对象做任何事情。对象接口与其功能实现是分离的，不同对象可以对请求做不同的实现，也就是说，两个有相同接口的对象可以有完全不同的实现。当给对象发送请求时，所引起的具体操作既与请求本身有关又与接受对象有关。支持相同请求的不同对象可能对请求激发的操作有不同的实现。发送给对象的请求和它的相应操作在运行时刻的连接就称之为动态绑定。动态绑定是指发送的请求直到运行时刻才受你的具体的实现的约束。因而，在知道任何有正确接口的对象都将接受此请求时，你可以写一个一般的程序，它期待着那些具有该特定接口的对象。进一步讲，动态绑定允许你在运行时刻彼此替换有相同接口的对象。这种可替换性就称为多态，它是面向对象系统中的核心概念之一。多态允许客户对象仅要求其他对象支持特定接口，除此之外对其假设几近于无。多态简化了客户的定义，使得对象间彼此独立，并可以在运行时刻动态改变它们相互的关系。设计模式通过确定接口的主要组成成分及经接口发送的数据类型，来帮助你定义接口。设计模式也许还会告诉你接口中不应包括哪些东西。设计模式也指定了接口之间的关系。特别地，它们经常要求一些类具有相似的接口；或它们对一些类的接口做了限制。

         第四点就要关注对象描述的实现，我们一般很少提及到实际上怎么去定义一个对象。对象的实现是由它的类决定的，类指定了对象的内部数据和表示，也定义了对象所能完成的操作。对象通过实例化类来创建，此对象被称为该类的实例。当实例化类时，要给对象的内部数据(由实例变量组成)分配存储空间，并将操作与这些数据联系起来。对象的许多类似实例是由实例化同一个类来创建的。新的类可以由已存在的类通过类继承来定义。当子类继承父类时，子类包含了父类定义的所有数据和操作。子类的实例对象包含所有子类和父类定义的数据，且它们能完成子类和父类定义的所有操作。这里就借用了抽象类，抽象类的主要目的是为它的子类定义公共接口。一个抽象类将把它的部分或全部操作的实现延迟到子类中，因此，一个抽象类不能被实例化。在抽象类中定义却没有实现的操作被称为抽象操作。非抽象类称为具体类。子类能够改进和重新定义它们父类的操作。更具体地说，类能够重定义父类定义的操作，重定义使得子类能接管父类对请求的处理操作。类继承允许你只需简单的扩展其他类就可以定义新类，从而可以很容易地定义具有相近功能的对象族。这方面我们要重点关注类继承与接口继承的比较和我们所作的是对接口编程而不是对实现编程这两个问题。

        第五点就要合理地应用复用机制，首先面向对象系统中功能复用的两种最常用技术是类继承和对象组合，类继承允许你根据其他类的实现来定义一个类的实现。这种通过生成子类的复用通常被称为白箱复用。术语“白箱”是相对可视性而言：在继承方式中，父类的内部细节对子类可见。对象组合是类继承之外的另一种复用选择。新的更复杂的功能可以通过组装或组合对象来获得。对象组合要求被组合的对象具有良好定义的接口。这种复用风格被称为黑箱复用，因为对象的内部细节是不可见的。对象只以“黑箱”的形式出现。继承和组合各有优缺点。类继承是在编译时刻静态定义的，且可直接使用，因为程序设计语言直接支持类继承。类继承可以较方便地改变被复用的实现。当一个子类重定义一些而不是全部操作时，它也能影响它所继承的操作，只要在这些操作中调用了被重定义的操作。但是类继承也有一些不足之处。首先，因为继承在编译时刻就定义了，所以无法在运行时刻改变从父类继承的实现。更糟的是，父类通常至少定义了部分子类的具体表示。因为继承对子类揭示了其父类的实现细节，所以继承常被认为“破坏了封装性。子类中的实现与它的父类有如此紧密的依赖关系，以至于父类实现中的任何变化必然会导致子类发生变化。对象组合是通过获得对其他对象的引用而在运行时刻动态定义的。组合要求对象遵守彼此的接口约定，进而要求更仔细地定义接口，而这些接口并不妨碍你将一个对象和其他对象一起使用。这还会产生良好的结果：因为对象只能通过接口访问，所以我们并不破坏封装性；只要类型一致，运行时刻还可以用一个对象来替代另一个对象；更进一步，因为对象的实现是基于接口写的，所以实现上存在较少的依赖关系，因此我们一般优先使用对象组合而不是类继承。其次我们要关注的是委托的使用，它使组合具有与继承同样的复用能力。在委托方式下，有两个对象参与处理一个请求，接受请求的对象将操作委托给它的代理者。它的主要优点在于它便于运行时刻组合对象操作以及改变这些操作的组合方式。

        第六点就是在设计过程中关联运行时刻和编译时刻的结构设计，个面向对象程序运行时刻的结构通常与它的代码结构相差较大，代码结构在编译时刻就被确定下来了，它由继承关系固定的类组成，而程序的运行时刻结构是由快速变化的通信对象网络组成，可见程序运行时刻和编译时刻的结构是存在很大差别的，很明显代码不可能揭示关于系统如何工作的全部。系统的运行时刻结构更多地受到设计者的影响，而不是编程语言。对象和它们的类型之间的关系必须更加仔细地设计，因为它们决定了运行时刻程序结构的好坏。

        总之，虽然在讨论设计模式的问题解决时我们可以从这六个方面深入分析，然而实际对于设计模式的使用过程中，我们要想学会灵活、科学地使用设计模式就更要深入地实验这些模式，体会不同模式之间应用场景地不同，设计模式地选择过程中，我们要理解好变化的设计思维，要积极地摆脱对特殊操作、软硬件平台、对象表示或实现和算法的依赖因素，积极理解低耦合、高内聚的思想，要结合设计目标对设计未来的变化都要充分地考虑，设计模式可以确保系统能以特定方式变化，从而帮助你避免重新设计系统。每一个设计模式允许系统结构的某个方面的变化独立于其他方面，这样产生的系统对于某一种特殊变化将更健壮。