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

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

1.什么是设计模式？
在软件设计过程中,会反复出现一些问题,为解决这些反复出现的问题所提出的解决方案就是设计模式。设计模式在诞生初期,为锻炼软件设计人员的头脑,要求设计人员在特定情况下明确上下文表达,并能够提炼软件设计中反复出现的问题,并提出解决方案,然后对相应解决方案进行验证,确认解决方案的正确性。由于建筑行业的复杂性,会反复出现一些问题,因此设计模式最初从建筑设计领域诞生,随着计算机技术的发展,在计算机软件设计领域中也引入设计模式概念,来解决计算机软件设计过程中的问题,并提出相应的解决方案。设计模式应用在软件设计中,主要提供能够反复使用的解决方案,来解决软件设计中反复出现的问题,不同的设计模式有着不同的语境以及强度,强度是语境中的元素,语境是对设计模式使用的解释语言。在选择设计模式时,就需要充分考虑问题环境与所选择设计模式的语境以及强度是否能够匹配,如果两者相互匹配,就可以使用这一设计模式。

2.设计模式在软件设计中的应用现状
在当前软件开发过程中,对设计模式的应用通常有两种方式,一种是在设计与开发过程中应用设计模式,另一种是在开发过程中应用设计模式。随着信息技术的不断发展,软件设计中应用设计模式已经成为当前软件开发中的重点研究内容,需要注意的是,在目前软件设计中对设计模式的应用依然存在一定的问题,导致设计模式的应用效果不能充分在软件设计中发挥出来。一方面,软件设计人员在软件的开发设计过程中,对设计模式缺乏一定的了解,因此难以将设计模式融入软件设计中。另一方面,当前软件设计中对设计模式的应用并未建成相应的应用体系,编程设计人员在设计过程中缺乏体系指导,因此设计模式在软件设计应用中就很容易出现问题。

设计模式的选择策略
设计模式的选择
在对设计模式进行选择时,首先要考虑的是软件设计中可能发生变化的因素,然后要根据设计模式所解决问题的原理以及过程,结合软件实际问题进行考虑。一定要了解浏览模式的意图,对于存在相似性的设计模式一定要做好充分的研究,判断模式之间的区别以及关联方式。

设计模式的选择步骤
将待解决问题抽象化,然后科学划分类型。
根据问题的类型来选择相应的设计模式。
规划问题并匹配相应的设计模式。通过对比研究,找出待解决问题与设计模式之间的共性,充分考虑待解决问题与对应设计模式之间的融合度,若设计模式无法解决相应问题,返回重新设计。
为解决软件设计问题,可以对相应设计模式做出修改或扩展原有的结构。
设计并细分软件结构。
评估软件设计质量。
设计模式在软件设计中的具体应用
在软件设计中,设计模式的具体应用方式包括以下几方面:一是在查阅浏览设计中,编程人员能够更加深入了解相应的设计模式,选择合理的设计模式,能够更加充分地发挥设计模式在软件终端的应用功能;二是在对代码案例的深入研究过程中,编程人员通过对代码的详细研究,能够帮助编程人员更好地进行软件开发工作;三是明确参与者名字在应用中的意义,能够有效提升后续软件开发质量;四是定义类,设计模式可以重复高效利用系统中的相关代码,且通过对系统中类的定义,能够确保软件顺利运行。

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模式都是受保护变化模式的体现。