• 面向对面程序设计第一单元作业总结


    面向对象程序设计第一单元总结

    代码量度

    在代码量度方面,我使用了PlantUML插件来手动绘制UML类图,并且使用Statistic插件进行行数统计,用MetricsReloaded插件来进行代码的复杂度分析。

    作业1

      首先,本次作业的逻辑结构相较于后两次作业来说是非常简单的,仅有x的多项式这一种形式,且避免了WF的出现,因而我们需要考虑的问题就仅仅是如何识别系数、指数,本题语境下的幂函数有哪些标准形式,比如,没有系数的形式,没有指数的特殊情况等等。由于本题的逻辑结构较为简单,因此,本次作业中我采用了有限自动机的思路进行读入和处理,使用了ArrayList的数据结构来存储基本项的系数和指数,并且能方便之后的合并化简。
      本题的类图如下,可以看出本题的逻辑结构是非常简单的,只需要一个主类和一个表示幂函数并方便输出的Term类

      接下来是本次作业的复杂度分析和行数统计等。

    作业2

      与第一次作业相比,本次作业的难度在于增加了WRONG FORMAT的判断,也即在进行表达式的解析之前先要进行一步表达式合法性的判断,同时增加了sin和cos两种不同的函数模式,对于表达式的解释也发生了变化,将因子分为常数,幂函数,三角函数三个部分,并且增加了因子与因子之间的乘法,面对这些变化,我们解析表达式时,对于基本的因子和项的解析模式需要改变。在本次作业中,我开始使用层次化的正则表达式来对因子进行匹配,同时,观察到每一个项都可以化简成为常数幂函数sin三角函数*cos三角函数的基本形式来进行格式化处理。
      本次作业的类图如下。

      本次作业的行数统计和复杂度统计如下。复杂度统计只保留了在main方法中计算过程内较为重要的方法等。

    作业3

      本次作业增加了函数的嵌套和带括号的表达式形式,同时大大增多了WRONG FORMAT的形式种类,在表达式的解析之前,我首先初步判断表达式空白符号使用的合法性,如果空白符号使用合理,则先把空白符号去除再进行解析,这样可以使表达式解析的过程变得更加方便。之后我还进行了对于表达式中每一项的基本模式的判断如果某一项不符合幂函数、常数、三角函数和括号中的表达式因子相乘的基本原则,也可以直接判断为WF。之后就开始解析的过程,本次解析过程我选择了逐字符解析的方式,对于运算符和运算的项目采用不同的存储方式,借鉴指导书中提出的表达式树,利用栈的数据结构实现存储,利用压栈的方式来确定计算式的根节点,进而递归进行计算,而在递归的过程中,我每一层都判断一次WF,直到达到最底层各种因子的基本形式。本次作业无论从数据结构还是表达式解析与计算都有了较大的难度提升,甚至输出计算结果也有着一些坑点,稍不注意自己输出的字符串也会出现WF的现象,本次作业我很遗憾地没有能够通过中测,也提醒了我要从开始就注意程序的架构设计与细节,避免多次重构。
      下面是本次作业的类图。

      本次作业的行数统计和复杂度分析如下,同上次作业,本次作业的复杂度分析只会保留重要的方法。

    bug分析

    第一次作业

      本次作业中我本人在设计程序的过程中发现对于多项式系数为1或者幂次为1的特殊情况处理不当,导致输出异常等现象,另外还有输入为常数0时输出格式错误,另外在互测阶段发现了自己有限状态机的设计出现了问题,有一些状态转移情况没有考虑完全,导致我的自动机跳转到了表示异常的状态。在互测时,我发现同学们的bug主要在于对特殊情况的处理。

    第二次作业

      本次作业中我出现的bug毫无技术含量,我在写代码时,手抖将String类的replaceAll方法写成了replaceFirst方法,我用replace方法来替换掉表达式中出现的多个+-号相连的情况,而由于我用错方法,面对一些出现了多个+-号相连的程序,我的解析方法会失效,进而出现bug。在互测阶段,我发现同学们的bug依旧集中于对特殊情况的处理,如0,以及幂函数三角函数的特殊形式等,并且在本次作业中,一些同学因为WF判断失误而出错。本次作业提醒我要养成良好的写代码习惯,同时要在本地做好充分的测试。

    第三次作业

      本次作业我用时比较短,在设计程序的时候出现了一些架构上的逻辑错误和手抖导致的逻辑错误等。在本次作业中,我对于表达式二叉树的计算过程的记忆有些模糊,导致进行压栈出栈的操作时出现了一些逻辑上的问题,另外,对于括号的识别与匹配也曾出现问题,最后采用了计数器计算括号的层数,实现正确匹配。但是由于本次作业可能出现的WF种类过多,所以在判断WF时也出现了一些bug,出现的原因也有不同,比如对matcher的使用的理解还不够熟悉以及对WF出现的情况没有考虑清楚等等。这里给我的启示是要努力提高程序的鲁棒性,尽量避免遍历所有WF情况的现象,从逻辑上解决WF问题。

    设计模式

      本单元主要涉及到工厂模式,工厂设计模式能极大的提高程序的可移植性,降低程序的耦合程度,避免在程序主要方法中直接创建新对象时“牵一发而动全身”的现象。在本单元的作业中,我构建工厂类时,主要依据表达式中的字符串来利用正则表达式判断因子或项的种类进行对象的创建。

    心得体会

      本单元的作业是我们采用OOP模式第一次实践过程,重点在于将思维模式从C语言的面向过程编程转移到面向对象编程,从之前的想到哪里写到哪里转变到写程序前先进行整体架构的设计再开始动笔。OO对于整体架构的设计有很高的要求。写出高内聚低耦合且结构清晰的代码无论是从方便他人阅读还是bug的角度都是很重要的,也是日后进行实际工程的基本功。而从小的方面来看,OO当中采用的数据结构和C语言中惯用的不太一样,本人在C语言编程时极为喜欢静态数组,因为简单方便而OO中,Java本身为我们提供了大量封装好的数据结构,如hashMap,ArrayList等,避免了静态数组的内存相关隐患,这一点值得我们注意。根据本单元作业中暴露出的问题,我应当作出相应的改进,在下一阶段的学习中,加强对Java中提供的各种数据结构的了解,能做到熟练应用,同时巩固基本的算法思想,对于栈的使用、树的使用等需要加以一定的巩固。并做到养成良好严谨的思维习惯,从写完代码再缝缝补补删删改改到争取做好架构一次性写出可读性强而结构清晰的代码。

  • 相关阅读:
    “Clang” CFE Internals Manual---中文版---"Clang"C语言前端内部手册
    LLVM每日谈之十七 LLVM/Clang的学习的思考
    Using Clang as a Library----Choosing the Right Interface for Your Application---翻译
    IT人员必备技能之Over the Wall.
    离散傅立叶变换之听声音破解电话号码
    Google Summer of Code: C++ Modernizer Improvements----Monday, November 18, 2013
    Design: cpp11-migrate
    C++11 迁移器的状态--2013年4月15日
    购物系统③完结篇
    (转)Eclipse中junit框架的使用——单元测试
  • 原文地址:https://www.cnblogs.com/Morpheus039/p/12535150.html
Copyright © 2020-2023  润新知