本单元采用了图模型解析UML。python
UML文件能够抽象为图、子图、边的逻辑结构。设计模式
在实现中,图的节点包括类、接口、属性,子图包括状态图、顺序图等。缓存
采用了三次遍历UML元素的方法建图,第一遍遍历建点,第2、三次遍历设置属性、连边,实现图对象的初始化。这里借鉴了一些python程序设计的思路,经过迭代器、选择器快速完成数据处理,实现起来代码编写效率比较高。网络
类、接口节点继承自可继承节点抽象类,实现了对继承的判断。数据结构
总流程为:架构
umlInteraction交互 - parser建图 - graph节点存储信息 & 定义查询方法 - umlInteraction交互并发
第三次第四次架构较为简单,这里主要借助JML规则、UML图的知识,对前两次做业的架构进行回顾。模块化
面向对象的第一步就应当是提取出对象概念,并找出继承、关联关系,进行封装。函数
在表达式求导做业中,对象概念的提取的原则是规则。对于初等函数,须要实现的求导规则为:学习
线性法则
乘除法则(莱布尼茨公式)
链式法则
特殊函数求导(幂函数、三角函数、对数函数、指数函数、....)
经过这些法则理论上生成任何初等函数的导数。即在初等函数范围内,求导规则具备完备性。
基于这种思想,结合表达式树模型完成了对象概念的提取。每个表达式树上的节点做为一个Item对象存在,同时表明一个基础的求导规则体。
对于化简,实现的部分规则为:
考虑到化简规则和求导规则的对应关系不清晰,所以单独创建了化简接口,在表达式树上经过递归访问接口方法实现化简。这种架构的不足之处在于,每个化简规则被分散在了多种表达式树节点上,不利于维护,而表达式树节点的分类是根据求导规则进行的。
一种改进方法是对节点对象添加运算规则,化简法则经过对运算规则的操做间接完成化简。
另外节点之间化简搜索空间很是大,可能还须要一些随机化方法完成化简,还应添加一些随机化的化简规则。
对于第二单元做业,电梯调度的对象概念提取的原则为状态。借助UML图的知识咱们能够看到,并发程序能够由时序图描述,而时序图中每个对象能够被视为一个状态机。状态机之间经过消息的传递完成并发任务。
所以,应当抽取了须要维护状态的概念做为对象。同时每一个对象的状态数目不宜过多,且内部联系紧密,外部联系疏松。这里抽取的三个状态为策略缓存、调度板、电梯状态。
同时,MainClass中的读取线程、Executor线程做为消息的发出者,负责保持对象间的协做运行。
第三次做业直接实现了提供的接口。社交网络使用的是图论模型,这里使用了点、点集合做为对象。
第四次做业UML文件解析,一样采用的是图模型。而这里使用的是查询的内容的逻辑结构为对象。包括类、接口、属性、状态图、顺序图等。
第一单元表达式求导课程中,第一次讨论了对象建立模式的问题。
这一单元主要的程序设计为:
表达式读取 --> 表达式元素对象 --> 调用元素求导方法 --> 调用元素输出方法
不过在一开始表达式读取模块中,使用了状态机模型,但实现的较为复杂,难以维护。在第二次、第三次做业中,参考了工厂设计模式。一个重要的改进就是强化了状态机模型和表达式元素对象之间的耦合关系。对于每一类表达式元素,采起独立的解析器,各个解析器分层解析。每个解析器相似于一个工厂。
这种方式的优点在于,较好地将需求中的概括定义和表达式元素对象的结构映射在了设计架构中。一个还应当改进的方面是循环依赖问题,能够经过抽象出统一的解析器接口,再对解析器对象进行组装来解决。相似于抽象工厂模式。
在第二单元做业中,采用了这种在再组装的策略。分别为执行器模块、调度器模块、策略模块、电梯模块。各个模块在MainClass完成对接,模块之间的实现细节对其余模块不可见。这样就避免了模块组装时产生的循环依赖问题,能够理解为全部模块都依赖于规则集合,而组装的过程又依赖于所有规则集合、模块实现集合。
抽象工厂模式/再组装的优点在于,采用了“模块化”的生产理念,各个部门在同一的规则下行事,部门与规则之间的联系强于部门之间的联系,避免出现部门之间的循环依赖,或者说互相扯皮、推卸责任、“抛皮球”状况的发生。
先进的社会是法治的。
而在第四次做业中,采用了三次遍历UML元素的方法建图,第一遍遍历建点,第2、三次遍历设置属性、连边,实现图对象的初始化。这里借鉴了一些python程序设计的思路,经过迭代器、选择器快速完成数据处理,实现起来代码编写效率比较高。
其实不管哪一种对象构建模式,都应遵循贴近实际、简洁易维护的原则。贴近对象数据结构,问题的逻辑结构,不要刻意迎合某个设计模式。无论黑猫白猫,能捉老鼠的就是好猫。
面向对象的方法是对事物刻画的一种方式。
从宏观层面上来看,世界的构造具备同构性。例如,地球绕太阳运动,而月球又绕地球运动。从科学的角度来看,这背后具备类似的物理原理和数学规则,能够经过数学方法进行抽象。
面向对象将这种规则化转化到了程序中,天然而然地诞生了抽象、分层、复用的特性。
科学的一个重要方法是“奥卡姆剃刀原理”。即“如无必要,勿增实体”。面向对象做为规则的描述体,也具备 “封装,继承,多态”的相似特色。“封装”对外部访问的限制,“继承”即对重复规则的限制,“多态”即对接口信息量的限制,同名接口能够处理更多信息。
面向对象也是工程学的协做方法。从工程化的角度而言,标准化是必不可少的部分。标准化意味着对产品、模块的行为有确切的约束,咱们只须要知道标准就能够进行协做,而无需知道对方的生产过程。
所以一个高效的程序应知足模块化、高耦合、低内聚的特色。
一个成功的面向对象的系统应是完备、简洁、高效的。