【OO多项式求导做业总结】

 OO-Part1-多项式求导

总的来讲，我对本身这三次做业的完成状况并不满意，首先，我仍然保持着C语言面向过程式的编码风格，这也致使我未能按时完成第三次做业，在此深入反省；其次，我未能意识到互测环节的重要性，正如讨论区大佬所说，“互测不是让你为了发现别人的bug而互测，而是为了让你在发现别人bug的同时，发现本身的bug并进行相应的修改，得以提高”；再次，心态和情绪管理不到位。在面对第三次做业“强迫”使用面向对象的时候，我未能及时寻找资料，而是怨声载道，自怨自艾，现在想来才意识到这是弱者才应有的态度。但愿我能从前三次做业中发现并总结本身的问题，在后续的挑战中迎难而上，抵达到昆仑课程的顶峰。

第一次做业：简单多项式导函数

用UML工具生成的类图：

 

 

因为当时没有及时总结面向过程式编程的弊端，我没有合理的划分类，更不用说了继承和接口的使用了。

如今想一想，其实幂函数自己就是一种因子，不必根据其结构划分五个求导方法，这种设计不知足高内聚低耦合的思想。而且，在类内没有对数据进行封装和隐藏，这也显然不符合OOP的思想。

公测

公测没有出现意外，笔者的程序在公测阶段没有出现除性能分之外的错误。

互测

总共被hack9次，类型基本上是格式判断的问题，对正则表达式进行了简单的修改后，顺利完成了合并修复。

hack屋内全部人共计18次，发现bug的主要问题在：对格式的判断和对单个数字的求导的处理不正确。

思考与感想

第一次做业的算法和工程方面的要求都不高，因此用面向过程的思惟也苟了过来。。。但其中发现了本身和同窗的一些共性的bug，也能够说是不够良好的编程风格：

一、试图用一个庞大的正则表达式判断格式，在浏览昂神的blog以后发现，我对正则表达式的使用存在必定的误解。正则表达式更多的用于相对简单且没有复杂的重复和嵌套的一些的模式匹配，以及其内部关键位置信息的提取。因此在第三次做

 

业中，很完美的限制了正则表达式的使用。

二、一个值得提高的点是关于数据容器的使用，数据的存储也是Java面向对象设计中的一个重要环节，是否能高效的组织数据极大程度上决定了一个程序是否能跑下去. 直接使用传统的固定大小数据容器显然没法知足需求,因此, 天然就想到了利用Arraylist, Hashmap之类的序列类容器.

第二次做业

在第一次做业的基础之上添加了三角函数因子

类图

 

在第二次做业中,我依旧没有领悟到面向对象的核心思想, 由于经过观察和必定的数学计算,我发现了全部的正确输入均可以转化为以下所示的统一形式.

coeff*x^a*sin(x)^b*cos(x)^c 

那么利用三个指数做为hashmap的索引，系数做为Hshmap的值组织数据既能够高效的组织数据，又能轻松的进行同类项合并。

不足：

没有体现面向对象的思想，思惟仍然束缚于面向过程式的编程，主要体如今：利用多个函数组合处理输入的多项式，设法将其化简为标准形式。

公测：

1.因为优化的问题，致使原先已经完成的数据处理出现了bug

2.正则表达式的使用出现了bug，【】内对字符的引用不该添加单引号。

思考与感想：

第二次做业相对于第一次做业难度上的递增较大，可是因为发现了三元组这一奇技淫巧，致使面向对象的思想仍是没能在脑海中创建起来，这是在写第二次做业中较为遗憾的地方，因此笔者在第三次做业中遇到了极大的困难。

第三次做业

这是什么鬼？这怎么写得出来？又要重构？！这设计根本没法实现啊？！

在拿到指导书左思右想了一天以后，我想到了利用分类的作法，即：将表达式分为【加减|乘|嵌套】三类，去完成此次做业；但开始码字伊始，就以为方案不可行，由于正则表达式不能嵌套定义，因此没法匹配出我设计中想要的信息，当时时间已经到了周日晚上，个人初步架构都没有创建起来，内心十分崩溃。

最终令我极为难以接受的失败终于降临了，我miss了第三次做业的ddl。

过后想一想，感受程序设计这活，一开始是不可能找到完美的解决方案的（最优解），然而此次做业的最优解也是存在的，即以下图所示。（虽然没有在ddl内完成做业，也不甘心被此次做业战胜）。

 JAVA设计模式——工厂模式

建立型模式是三大设计模式（建立型模式、结构型模式、工厂型模式）之一，另外两种为结构型模式与行为型模式。建立型模式一共分为五种模式：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。在第三次做业中主要采用了工厂模式，即：因子类这一工厂，能够生产出不一样类型的因子“产品”，每种产品保留了因子类的共性，同时也有自身的特性，如：求导方式，判别模式……

思考与感想：

2.对OO做业新的认识：

除了指导书的各类官方要求：讲究代码风格，设计层次以外，我还想谈谈OO做业的挑战性。

挑战点一：编写程序的挑战。解决从无到有的问题是咱们首先应该考虑的问题，任何一次OO做业都不可能一蹴而就，设想程序没法站立起来的状况下，还期望它能跑吗？因此应一步一步地由独立的单元搭建起整个工程，而不是成天对着设计纸上那几条算式疯狂抖腿抓头发…

挑战点二：要充分明确指导书的需求，掌握其中的重要细节和提示。这对后续的bug调试和互测中程序的防护十分重要。在第一节OO课上老师就强调过“道路千万条，条条皆安全”。在编写程序的时候就要注意到哪些是薄弱环节，如何增强它，如何保证它的鲁棒性，不会轻易被攻破。

挑战点三：OO做业不只是对面向对象能力的考查，也是对一我的性情的考验。在面对困难的时候，失败者老是设想“若是我作不出来的后果”，因而终日惶惶恐恐，什么也写不出来；成功者想的倒是“只要我认真去作，就必定能完成”。在如此短期内完成如此庞大的工程实属不易，保持一颗积极向上的心态，多构思，多实习，在不断尝试中提高本身的OO水平。

2.对OO新的认识：

通过第三次做业的挫折，彷佛对面向对象这个概念有了新的认识，借用何大佬在交流课上所提出的问题，“如何造一架飞机”？典型的面向过程思惟是：先设计图纸，而后一股脑的把整架飞机搭建出来，显然这是不可能完成的事情；然而若是用面向对象的思想，将其分而治之，先造机翼，再建机舱，再建控制台，起落架……最后把各类零件整合到一块儿，组成一架飞机。具体到第三次做业来讲，面向过程的思惟是一次性处理全部的输入数据，判断格式，构建数据容器存储数据，求导，相加，输出……繁冗的细节决定了面向过程思想必然不能解决问题；然而用面向对象的思想就应该是，因子分类：sin/cos/power/num/expre五个类，共同继承一个抽象类factor；项是由因子组成的链表；表达式当作是项组成的列表。如此层层递进，数据的存储将变得十分简便。

面向对象的编程思想不是一朝一夕能实现的，须要不断的动手尝试，阅读高质量的优秀代码，才能不断的提高。但愿与我有一样问题的同窗能再接再励，利用此次写博客的时间好好反思，好好整理心情，该出去踏青的时间就不要在学校里苦干写不完的做业，这样其实效率很低（我的亲测）。一次挫折并不影响昆仑历练的成功，不要被困难击退，重整旗鼓，迎难而上。