《 OO第三单元作业总结 》

一学期的Java课程就来到了尾声，作为Java小白的我来说，似乎还没有完全领悟Java的本身，只是大致学习了些皮毛。

0.前言

本次作业：《 OO第三单元作业总结 》

针对我们第三阶段的作业（ 共三次 ），发表总结性博客。这三次作业，难度很大！！（个人感觉）成绩分别为100、10、100。

对于这四周所学习到的，开始迈入Java面向对象特点的学习。

1.作业过程总结

①总结三次作业之间的知识迭代关系；

      这三次作业难度提升非常明显，大量的要求，让我有些懵逼。

      第一次是 雨刷程序功能扩展设计。

      雨刷器之前上课，老师有提到过，内容其实大多是简单的继承为主，但比较特殊的是介绍了一种开放封闭原则，   其核心思想是：软件实体应该是可扩展的，而不可修改。也就是，对扩展开放，对修改封闭的。开放封闭原则主要体现在两个方面：对扩展开放，意味着有新的需求或变化时，可以对现有代码进行扩展，以适应新的情况；对修改封闭，意味着类一旦设计完成，就可以独立完成其工作，而不要对其进行任何尝试的修改。 实现开开放封闭原则的核心思想就是对抽象编程，而不对具体编程，因为抽象相对稳定。让类依赖于固定的抽象，所以修改就是封闭的；而通过面向对象的继承和多态机制，又可以实现对抽象类的继承，通过覆写其方法来改变固有行为，实现新的拓展方法，所以就是开放的。“需求总是变化”没有不变的软件，所以就需要用封闭开放原则来封闭变化满足需求，同时还能保持软件内部的封装体系稳定，不被需求的变化影响。 

      

     这里的控制杆、刻度器、雨刷和处理器类都是继承了抽象的类，这样就可以达到开放封闭原则：利用多态在抽象父类设计函数，然后在每个子类完善具体函数方法。

     

      第二次作业是 统计Java程序中关键词的出现次数。

      这里我使用了枚举，叭关键词都专门放在里面，并设计了计数的方法。

 

       里面同样使用了正则表达式来进行判断，对注释、字符串等直接进行舍去。

       

      第三次 表达式求值。

     表达式求值关键也是在于正则表达式的运用，首先要判断出错误的输入，然后使用到了一个新的知识，逆波兰表达式——即后缀表达式。里面运用了list和stack，把表达式按元素一个个进行判断和录入，最后在按照规则求值。

     ②如何通过作业逐步理解面向对象的封装性、继承性与多态性三大技术特性；

     继承性和多态性主要是在雨刷器设计上面，其中开放封闭原则，使得在添加或者替换部件时，只需要添加代码，并不是在处理类上进行大量代码修改。分装性还是在每个类中属性的设置，避免外部直接修改内部属性的值，必须通过调用方法，使得私有属性更加安全。

     ③作业过程中遇到的问题及解决方法

     第一次作业：在雨刷器类设计上面，需要设计每个部件及处理类的抽象父类，便于进行修改和满足开放封闭原则。

     第二次作业：一开始思路出现了错误，导致在截止时只做出来了Wrong Format输出。后来进行代码重写后，发现关键词的计数和如何忽略注释及字符串是难点。

     第三次作业：逆波兰表达式的学习，正则表达式判断输入错误情况。其中逆波兰不是很明白其中的原理。

     ④每次作业花费的时间比例

     这三次作业中前两次均一直到截止时间才能够完成，第二次没有全部测试点通过，但结束后，仍有继续改进或重写代码，并自己找同学进行样例测试。第三次作业相对简单，接近一天的时间。

     ⑤对编程过程的严谨性的认识及教训

     渐渐适应了Java的简单编程语言习惯，但是在类属性方法的调用上仍会出现错误，包括类的设计和继承关系上，其中包含了多态性的体现。以后还需要多敲代码。

2.OO设计心得

     ①Liskov替换原则

     其核心思想是：子类必须能够替换其基类。这一思想体现为对继承机制的约束规范，只有子类能够替换基类时，才能保证系统在运行期内识别子类，这是保证继承复用的基础。在父类和子类的具体行为中，必须严格把握继承层次中的关系和特征，将基类替换为子类，程序的行为不会发生任何变化。同时，这一约束反过来则是不成立的，子类可以替换基类，但是基类不一定能替换子类。 
    Liskov替换原则，主要着眼于对抽象和多态建立在继承的基础上，因此只有遵循了Liskov替换原则，才能保证继承复用是可靠地。实现的方法是面向接口编程：将公共部分抽象为基类接口或抽象类，通过Extract Abstract Class，在子类中通过覆写父类的方法实现新的方式支持同样的职责。 
    Liskov替换原则是关于继承机制的设计原则，违反了Liskov替换原则就必然导致违反开放封闭原则。 
    Liskov替换原则能够保证系统具有良好的拓展性，同时实现基于多态的抽象机制，能够减少代码冗余，避免运行期的类型判别。

       ②依赖倒置原则

     其核心思想是：依赖于抽象。具体而言就是高层模块不依赖于底层模块，二者都同依赖于抽象；抽象不依赖于具体，具体依赖于抽象。 
     我们知道，依赖一定会存在于类与类、模块与模块之间。当两个模块之间存在紧密的耦合关系时，最好的方法就是分离接口和实现：在依赖之间定义一个抽象的接口使得高层模块调用接口，而底层模块实现接口的定义，以此来有效控制耦合关系，达到依赖于抽象的设计目标。 
     抽象的稳定性决定了系统的稳定性，因为抽象是不变的，依赖于抽象是面向对象设计的精髓，也是依赖倒置原则的核心。 
     依赖于抽象是一个通用的原则，而某些时候依赖于细节则是在所难免的，必须权衡在抽象和具体之间的取舍，方法不是一层不变的。依赖于抽象，就是对接口编程，不要对实现编程。 

     ③接口隔离原则

     其核心思想是：使用多个小的专门的接口，而不要使用一个大的总接口。 
     具体而言，接口隔离原则体现在：接口应该是内聚的，应该避免“胖”接口。一个类对另外一个类的依赖应该建立在最小的接口上，不要强迫依赖不用的方法，这是一种接口污染。 
     接口有效地将细节和抽象隔离，体现了对抽象编程的一切好处，接口隔离强调接口的单一性。而胖接口存在明显的弊端，会导致实现的类型必须完全实现接口的所有方法、属性等；而某些时候，实现类型并非需要所有的接口定义，在设计上这是“浪费”，而且在实施上这会带来潜在的问题，对胖接口的修改将导致一连串的客户端程序需要修改，有时候这是一种灾难。在这种情况下，将胖接口分解为多个特点的定制化方法，使得客户端仅仅依赖于它们的实际调用的方法，从而解除了客户端不会依赖于它们不用的方法。 
     分离的手段主要有以下两种：1、委托分离，通过增加一个新的类型来委托客户的请求，隔离客户和接口的直接依赖，但是会增加系统的开销。2、多重继承分离，通过接口多继承来实现客户的需求，这种方式是较好的。 

     ④类设计心得

     这几次大作业均是由我们自己设计类，我在设计的时候，根据前几次的给的UML类图，总结出的一些设计理念，尽量满足单一职责，并且让类更加丰富，不仅仅只是一两个类就解决一个问题。例如表达式求值：我就设计了测试类，表达式判断类，表达式处理类，表达式输出类。每个类都有相对应的职责。

3.测试的理解与实践

     ①测试对于编码质量的重要性

     因为在做正则表达式的题目时，会经常出现错误，正则的表达不严谨，会漏掉一些特殊情况。这时我还是选择的是重新创建一个类进行测试，这种方法没有效率，不够方便，所以不值得提倡。老师之前介绍过断言的简单使用，可以按这个方法，多在代码里添加测试。

     

     ②查阅资料，假设使用Junit进行程序的测试是否可行   

     是可行的，老师上课提到的JUnit类库里面有Assert类里面的assertEquals就是一个适合程序测试的方法。百度百科的解释是：单元测试（模块测试）是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。例如，你可能把一个很大的值放入一个有序list 中去，然后确认该值出现在list 的尾部。或者，你可能会从字符串中删除匹配某种模式的字符，然后确认字符串确实不再包含这些字符了。简单的说，单元测试就是对你程序中最小的功能模块进行测试，在c语言里可能是一个函数，java中可能是一个方法或者类。目的就是为了提高代码的质量。

4.课程收获

    总结这一学期来在OO方面的教训及收获

    接触到了面向对象的设计概念，对Java的基础知识有了一定的了解，包括老师最后几次课教的JavaFx，这些让我对Java的学习兴趣增加了不少。不过自己接触的题型还是偏少，有机会可以在其他网站上找一些题目来做做。还有就是一些做题思路上面和对类的设计，自己的确有了明显的进步，知道了该如何设计类，每个类都符合单一职责。

5.对课程的建议

     课程这学期基本就结束了，感谢蔡老师这一学期以来对我们的教学，虽然都只是网上授课，但还是可以感受到老师的上课热情的，包括会给我们一些答疑的时间。教材也发到手里了，希望自己可以抽时间好好阅读一下教材，跟着书再系统的过一遍知识，练一练课后的练习，争取对Java有更深的了解。