前五周学习内容小结

 （1）前言：

    在前五周的学习中，我们从一开始的雨刷问题到延续十周的课设，以及到正在进行的农夫过河的实验，从七大设计原则：“开-闭”原则、里氏代换原则、依赖倒转原则、合成复用原则、单一职责原则、迪米特法则、接口隔离原则到单例模式、桥接模式、建造者模式、工厂模式；对我来说，这些知识的灌输是突然的，也是有很大难度的，但是一路走来，挑战满满也惊喜不断，发现自己的潜力也意识到了自己的不足，现在由我来分别对前五周的学习做一个自我总结。

（2）设计与分析：

一、雨刷问题

       雨刷问题由简到繁，刚开始我们只是单纯的利用交互式菜单，完成司机对雨刷系统的控制及测试，刚开始也只用了一个类实行自己的程序，设计思路大概是输入司机所要调的挡（目标挡），然后通过显示升档降档的方式，将司机所要做的操作显示出来，并没有什么技术含量，类图如下：

 

       就非常简单的关系，只执行了一个类，而后来到了第二次雨刷问题，与第一次对比实现了相对于我自己来说巨大的进步，设计了实体类、业务类、与接口类，也较好的完成了各个类之间的关系，认识并遵从了单一职责原则（srp原则），一个类只干一件事，以下是我第二次作业的各个类：

 

        对比于第一次的单一类，明显第二次的类更加丰富以及分工明确，brush1是主类也就是实体类，Control类、Driver类以及Show类都是接口类，Dial类、Brush类、Lever类都是业务类，虽然对单一职责原则并没有做到十分的完善，但是也算是有所领悟。

        时间来到第三次雨刷问题，也就是对于第二次雨刷问题的进一步优化，增加了一个迪米特法则：只和朋友交流，不和朋友的朋友交流。优点是：降低耦合性。对于我们的程序，降低耦合性必要的，耦合性越低，对后续程序的删改便更有帮助，不需要有牵一发而动全身的紧张，而是各司其职，互不影响，以下是类图：

  

 

 

        这次类图明显对比于第一次是有了很大的进步，自身也很欣慰看见自己的进步，之后的第四、第五次实验更是嵌入了“开-闭”原则、里氏代换原则、依赖倒转原则以及合成复用原则，开闭原则：对扩展开放，对修改关闭。也是OOP七大原则里最重要的原则。里氏代换原则：子类可以扩展父类的方法，但不可以重写父类的方法，用于防止继承泛滥。依赖倒转原则：面向接口编程，不要面向实现编程，有利于代码结构的升级扩展。合成复用原则：先考虑用组合关系实现代码复用，其次才考虑用继承实现，作用依旧是降低代码耦合，显而易见，降低代码耦合对于我们的重要性。

        而后我还了解到MVC模式和单例模式。 MVC全名是Model View Controller，也就是模型(model)－视图(view)－控制器(controller)，主要就是一种业务逻辑、数据、界面显示分离的方法组织代码 ，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。

        雨刷问题总结：在雨刷问题的进行中，我学习到了OOP七大原则的用法以及MVC模式、单例模式，以及对于类的拓展和改善有了进一步的突破。

        不足：对于以上问题的了解并不是完全掌握。

二 、农夫过河

        农夫过河已经进行了两次实验，那就做一个简短的小结，关于农夫过河问题，实验是给了我们部分源代码，由我们来进行改进和完善，设计策略：

         首先四个业务类：Farmer类、Sheep类、Cabbage类、Wolf类，这几个类之间为了实现耦合性降低，我设计了一个Game类，降低耦合性的同时，又能很好的完成想要实现的任务，最后便是反复的调用。

         以下是农夫过河问题的类图：

三、PTA总结

        前五周我们一共进行了三次PTA的作业，对我来说最难的是第一次作业，因为三、四题的代码量较多，导致错误原因不明，调试无从下手，第二次、第三次则是进行了基础语法的练习，由于寒假的特训练习，显得相对得心应手，最值得一提的是第三次作业中的串口字符解析，题目都得看半小时，后来在写的过程中，一个重要的错误是循环中忘记将计数器sum清零，导致一直无法通过测试点，下面浅看一下代码吧：

 

        第一次所做的PTA作业是有一定难度的，主要是关于日期的计算，从DateUtil中调用Day类的方法，再继续从Day类中调用Month的方法，以下是我的类图：

四、最近学习的桥接模式总结

       对于桥接模式，我想大家一开始都是陌生的，听过老师讲解一遍后，我似懂非懂，便进行了自主学习，这也是我来到大学后明白的道理，自主学习的重要性，在学习桥接模式的过程中，我明白了桥接模式是将抽象和现实分离，使它们可以独立变化。它们是用组合关系代替继承关系来实现，从而降低了抽象和实现的这两个可变的维度的耦合，通俗的来讲，桥接模式具有抽象和实现的两个维度，例如老师在上课时提到的车和路的问题，该问题就是把车当成抽象，把路当成具体的实现，由于它将抽象和实现分离而不是像继承，所以运用该模式使之拓展能力变强，其细节对客户透明，但也有其缺点，那就是，由于聚合关系建立在抽象层，要求开发者针对抽象化进行设计与编程，增加了系统的理解和设计难度。

       桥接模式分为四个角色：（1）Abstraction（抽象类）（2）RefineAbstraction（扩充抽象类）（3）Implementor（实现类接口）（4）ConcreteImplementor（具体实现类）

        在桥接模式中也体现了很多面向设计程序思想，包括“单一职责原则”、“开闭原则”、“合成复用原则”、“里氏代换原则”、“依赖倒转原则”等。熟悉交接模式后，也有助于帮助我们形成正确的设计思想和培养良好的设计风格。

五、建造者模式的学习总结

       由于前面提到了桥接模式，在学习桥接模式的过程中，偶尔也会运用建造者模式，那么现在让我们谈谈建造者模式吧。建造者模式是指将客户端与包含多个组成部分的复杂对象的创建过程分离，客户端无需知道复杂对象的内部组成部分与装配方式，只需要知道建造者的类型即可。   一下是建造者模式的设计类图。   

 

        建造者模式分为抽象建造者（Builder）、具体建造者（ConcreteBuilder）、产品角色（Product）和指挥者（Director）。Builder类中一般声明两类方法，一类方法是BuilderX（），他们用于创建复杂对象的各个部件，另一类方法是getResult（），用于返回复杂对象。它可以是抽象类，也可以是接口。ConcreteBuilder类用于实现Builder接口；Product类中包含多种组成部件；Director类中运用constract（）建造方法调用建造者对象的部件构建与装配方法完成复杂对象的建造。

        建造者模式的优点是：客户端不必知道内部细节，将产品本身与产品的创建过程解耦，使得相同的创建过程可以创建不同的的产品对象。每一个具体建造者都相对独立，与其他的的具体建造者无关，因此恨意很容易增加新的建造者。可以更加精细的控制产品的创建过程；增加新的建造者无需修改原有代码，指挥者类针对抽象层编程，系统扩展方便。当然有利便有弊，建造者模式的缺点与桥接模式的缺点类似，都是内部结构复杂，容易造成系统的庞大，不便于修改。

        建造者模式和工厂模式的不同点：建造者（Builder）模式和工厂模式的关注点不同，建造者模式注重零部件的组装过程，而工厂方法模式更注重零部件的创建过程，但两者可以结合使用。

（3）踩坑心得

    在农夫过河实验中，我出现了一些错误，例如：

 

 

     于是我总结了一下一些我经常犯的错误：（1）没有正确的调用其他类里的方法（2）代码的不完整；（3）思路的混乱。在发现错误后，我经过不断地debug对错误进行改进，以及对类的知识的深入了解我得到了以下正确结果：

 

 

 

 

 

 

 

 

（4）总结

        以上便是我对前五周内容学习的总结，在前五周的学习中，我学习到了如何去设计类以及对错误示例的测试，我了解了如何去运用七大原则以及在何种情况下去运用设计模式，还了解到各个设计模式的优缺点，在每次的实验中，都能找到自己的不足，以及去想办法改进，在PTA的学习过程中，我学习到了如何去画类图以及对于格式的正确输出。在总结的过程中，我发现我对很多专有名词的运用并不熟悉，可能我知道我自己该干什么，但无法用专有名词去给他表达出来，自我觉得第一篇博客写的并不能让自己满意，也警醒了我在之后的学习中应该多注重这方面的学习。