标签：总结 Control Java 原则 作业 至五周 雨刷 设计

时间如白驹过隙，眨眼间便已过去整整五周。在这五周的时间里，我们主要学习了Java的类设计的相关知识，具体内容包括类与对象的关系、对象交互的方式、类的继承与多态以及对象容器。

同时在课下，我们还进行了7次实验和5次作业，熟悉了面向对象设计中的五大基本原则和Java 中最简单的设计模式之一的单例模式。以下我将以时间顺序介绍每周的阶段性学习重点。

第一周：

在本周，我们主要学习了Java的基础语法和简单的类与对象的关系，为了让我们感受到面向对象的程序设计的优势，了解不同编程语言之间的差异性，本周的作业定为了“用三种编程语言设计汽车雨刷的操作系统”。

 作为初学者，我在使用Java编程时依然采用了以往的编成方式，以下是我的第一次作业中Java代码的类图：

可以看到，全程仅使用了一个类，所有预设功能功能都被涵盖在一个类中，程序臃肿而无序，不能称之为代码了，应该称之为垃圾才对。

第二周：

相较于第一周，本周学习的内容更多也更为专业。在本周，我们学习了类与对象的象征意义，同时接触到了面向对象设计的七大设计原则之一的单一职责原则（SRP），作为验收成果，本周作业便是依据单一职责原则重构第一周作业雨刷问题，采用面向对象技术，合理设计实体类、业务（控制）类、接口类及各个类之间的关系。

单一职责原则指的是：一个类只允许有一个职责，即只有一个导致该类变更的原因；也就是说，根据单一职责原则，一个函数（方法）只做一件事情。如果发现一个函数（方法）里面有不同的任务，则需要将不同的任务以另一个函数（方法）的形式分离出去。因此在本周的作业中，我将上周的作业代码中的各项函数都剥离出来，并分别设计了实体类Brush、Lever、Dial以及接口类Machine和业务类Control来承载它们。其中Machine类为驾驶员和主控系统Control类的接口，Machine接收驾驶员的操作，将驾驶员的需求传达给Control；Control接收到信息后，将下发相应的指令到Lever、Daily和Brush，实现驾驶员的需求。同时我将复杂的函数尽量拆解成了多个简单函数。以下是我该次实验最终代码的类图。

第三周：

在本周的学习中，我们主要学习了对象交互的方式、类的封装和迪米特法则（LoD），而本周作业同样是基于本周所学内容改进上周的雨刷系统的代码。

迪米特法则也叫做最少知道原则（Least Know Principle），一个类应该只和它的成员变量、方法的输入、返回参数中的类作交流，而不应该引入其他的类（间接交流）。也就是说，类与类之间不能再出现一个类直接访问其他类中的变量的情况，如上周的作业代码中，Control中的setLever等函数直接访问并修改Lever等类的参数的情况。而实现迪米特法则的方法便是将类封装，将属性私有化，使这些属性仅能通过预先设计好的getters和setters来访问或修改。以下便是我改进后的代码的类图。

第四周：

类的继承与多态、MVC模式、单例模式，相关实验：依据单一职责原则和迪米特法则重构第三周作业雨刷问题，要求设计必须符合MVC模式，且尝试嵌入单例模式

第五周：对象容器、开闭原则、里氏替换原则、依赖倒置原则、合成复用原则，相关实验：依据单一职责原则、迪米特法则、开闭原则、里氏替换原则、依赖倒置原则与合成复用原则重构第四次作业雨刷问题，需求变更为该系统可以适用多种雨刷系统，采用面向对象技术，再次合理设计实体类、业务（控制）类、接口类、各个类的抽象父类以及相互的关系

标签：总结,Control,Java,原则,作业,至五周,雨刷,设计
来源： https://www.cnblogs.com/3110321341chg/p/16098098.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。