lab3的一些感悟

菜鸟的复用程序编写的反思和总结

我一开始的思路：
因为在复用结构中存在很多的继承树等层级结构，我准备的是开始时便选择好复用结构，然后由抽象到具体的来实现每一颗继承树，在开始时便将各个具体类的公共部分进行收集然后构造出各个继承树。最后将各个继承树链接起来，于是大功告成。我觉得这可能是比较标准的编写复用程序的思路。
但是当我开始实施的时候，总是有种无从下手的感觉。每一部分有差异的地方，有共性的地方都进行的详细的归纳，并且在纸上也大概的画出了继承树的样子。并且对各个部分之间的委派进行了初步的设想。但是当我打开eclipse开始写代码的时候，发现真的无从下手。如果就针对一部分进行编写的话，由于各个模块之间并不是相互独立的，相互关联，我的模块需要提供多少功能，又通过什么样的方式和其他的模块进行沟通，所有的数据集合放在哪个板块里等一系列问题使得我写完最基础的数据类以后就不知从哪下手了。不知道要先写那里，要写成什么样子。于是计划失败，所以我开始向其他同学进行询问，也并未得到解决困惑的方法。当时我也不知道是那里不懂，也不知道想要知道什么。觉得大脑一片混乱。
最后实现的办法：
我放弃了一开始的思路，从头开始。仅仅从设计单个应用场景的方向入手。就航班的任务，从客户端开始写，客户端需要什么功能，如果这个功能没有便开始实现这个功能，当然在实现的过程中依旧按照委派等方式实现。需要什么些什么。从客户端开始写，让我对自己的程序有了更加清晰的设想，清清楚楚的知道我需要什么。就这样一边完善客户端一边实现服务端。慢慢的第一个场景的功能实现的差不多了以后。开始着手下一个应用场景的编写，然后运用之前总结的共性以及差异，再为第一个场景的各个具体类编写可以复用的父类，于是每一个板块的继承树也就出现了。借鉴在第一个场景中使用的逻辑，大同小异的套用在第二个场景中，慢慢的下一个应用场景也就开发完成了。
也许面向复用来编写程序就应该从上到下对程序的每一个部分都进行设计，对模块之间的链接等等一系列的问题都要进行很详细的设计，直到看到设计图就能想象出代码的时候才是写代码的时候。我的无从下手估计就是对整个项目的设计太过粗糙。但是作为新手，可能并不能有那么成熟的大局观。所以我认为刚开始的时候，不要从复用的角度去设计整个程序，而是先写出一个具体应用来，然后再考虑下一个应用，同时考虑是不是可以使用上一个场景中的某些功能、数据格式、接口等，再对第一个应用进行抽象、复用。这也许不能叫做面向复用的编写方式，顶多算是带着复用的思路来开发多个场景。虽然这不是最佳的方式，但个人认为这是对萌新较为友好的实现思路。等到编程经验更加丰富一些的时候也许能够针对需求设计出更加详细的方案，最终达到见设计即见代码的程度。