PTA第二次博客作业总结

本次博客主要分析第五周至第八周的pta作业情况。

  本次共有8题作业,包括第四次的三题作业和第五次的两题作业,还有第六次作业的三题。

  首先第四次作业的三题:这次作业的难度来说第一题是比较难的,我也没有写出来,原因也会在此述说。先看后面两题,第二题是使用蒙特卡洛方法求圆周率,在做这题时,我首先上网搜了下什么是蒙特卡洛方法,对这种方法有了初步了解,这样再根据题目中给出的类图设计类就行了;第三题是图形继承,要求设计5个自定义类,其中四个类需继承父类Shape类,再按要求计算各项数值,例如周长,面积等,也属于比较简单的题目;再来看第一题,首先一看到这个题目就有点吓到了,因为我是那种学的不怎么好的学生,马马虎虎的那种,再看一下这个题目和类图,开始上手,发现我的思想根本就不能有任何方法,我在此时就发现了我写代码又很强的面向过程的想法,有可能还没有完全纠正过来。再来看第五次的作业,第一题又是图形继承类的,因为之前做了,有了基础。所以比较简单;第二题是多项式求导,相较于第一题来说,这一题是更有难度的,看到这题,首先想的是如何把它的系数和指数提取出来,之后再进行计算,基本思路就这样。之后是第六次作业,第六次有三次作业,其中第三题是附加题,求素数个数的题目,一开始我是采用最简单的方法,直接用比大小的方法来解,很显然,虽然可以计算出结果吗,但是明显不符合要求,所以就上网搜了下求素数的方法,简单分析了下,网上有很多快速求素数的方法,所以就参考了下;其他的两题都是图形类游戏,一个是图形排序游戏,一个是图形分组游戏,两题比较类似。

  这三次作业中最难的我觉得是水文数据那题,因为我毫无思路,是因为我的思想”守旧“吧,通过这题我就更加清晰了OO的设计理念,其实这题就是展现了面向对象的单一职责原则,我还是没有吃透这个原则,很明显,这题是每个类中的方法解决一个小问题,每个类、每个方法都是有自己的作用,在设计方法时,不用考虑其他方法时如何运行的,只需管好自己就行,我在看到这题时,想到了这里应该怎么办,那里又该怎么做,这里行不通又该怎么办,并没有一步步按照题目给的类图的来设计,导致我就陷入了面向过程的思想中,所以这是我在这题认识的面向对象的原则,这样我能深刻理解这一原则;还有就是求导的题目,这题与水文数据这题两题使用可较多的正则表达式,而且我在做的时候也是没有理解到单一职责原则,导致我一直没有写出来,之后过了蛮久之后终于把这题写出来了。这两题给我的感觉就是我们在面向对象设计的时候,不应该和面向过程那样只需解题,我们还需要学会设计,学会分析,面向对象需要的是设计前的想法,而不是设计中的想法,对此,我还需要多多学习。

  之后再来看图形类的题目,图形类的题目用到了继承和多态,在这里我感觉的就是父类制定的是一个模板,子类需要去按着模板来写,这是基本骨架,它允许你增加”肌肉“增加”肉度“去装饰自己,可以加一些自己的东西,但是你不能出了模板的范围或者说违反了父类的东西,这是不允许的;还有就是父类可以起到封装性的作业,当子类需要修改的时候,我们知道OO式不太支持修改代码的,所以我们在需要修改时,不能去对需要的这个子类修改,而是自己再加个子类,这样可以达到封装的效果。结合这几题,图形类中是有一个父类Shape类的,其他的像Rectanglel类、Triangle类、Circle类、Trapezoid类都是需要满足父类的,你可以重写父类的方法,可以增加自己的方法,而且这里使用的抽象类,就这个Shape类,更加的需要子类遵顼它的模板来展开。多态性我们可以很清楚的感受到,许多子类继承自父类,而且都一一不同。

  在这几次作业遇到到的最大问题就是单一职责原则的问题,很多时候我无法理解这个,老是会按照面向过程的思想想问题,这就需要我多多理解这个原则;还有一个问题就是正则表达式的学习,尽管说这里的题目只需简单的使用。但要符合题目要求的,还需要花费一番功夫,需要一个个去匹配。所以这几次作业给我印象深刻的就是水文数据检验的问题,让我感觉无从下手,这是最恐怖的,看来我又很深的面向过程的思想,需要大力的去改正。另外这几次作业花费的时间也是较前几次作业花费的时间多得多。

  OO设计心得:

在设计图形类的时候,面向对象的继承、多态、封装这三大特性在做题的时候很容易感受出来,我觉得继承就是子类照着父类的模板来写,可以增加,可以重写;多态则是可以很多个子类来继承父类,因为根本来说父类里面是包含这些个子类的一些相同的特性;封装性则是父类里的东西不能乱动,需要改变要再子类中改,最好是再设计一个子类。面向对象里的单一职责原则和开闭原则我算是在这次作业有了很深的认识,单一职责原则简单来说就是分工合作,将复杂问题简单化,很明显的数学思想。我感觉OO编程的这种设计理念和方法是很好的,可以让设计者能把问题对象化,把问题具体化,而不再是单单解决问题这么简单,它是从问题本身出发,这样解决问题来就比较简单了,不过这就要求我们需要对问题有个很深的认知,需要去深刻分析问题本身。

  我觉得Junit并不适合现在的我们,Junit是需要自己编写测试类代码的,这其实会大大增加学生的压力,而且要求编写代码之前先写测试类,否则编写的代码很不稳定,那么你需要同时维护测试代码和实际代码,这样会使得工作量大大增加,显然对于我们增加的就不是一点难度了,当然,偶尔用简单的还是行的。

  我在这几次收获最大的就是知道了自己的具体思维是怎样的,这让我由面向过程转到面向对象更近了一步。

  

猜你喜欢

转载自www.cnblogs.com/fuqijin/p/12813562.html