软件构造学习笔记5--可复用性与可维护性

在lab3中又一次体验了从0开始设计的感受，由于多了对可复用性和可维护性的要求，设计难度增加了很多，好在实验指导中提供了6种方案，启发了思路。鉴于装饰器模式中间逻辑相对复杂一点，觉得自己驾驭不了，一旦出错很难进行定位、修复，因此选择使用了第五种方案，委托的形式，又由于实际的需要对其稍作了一些修改，多了一层委托关系。主要是出于以下的想法，如果使用实验指导中给出的方案，则在修改位置等参数时，一个位置、两个位置、多个位置所需的参数不一样，若想统一传入，只能使用list传入，同时需要检查list中的位置数目与所需的是否一致，如果所有这三种类型的位置的内部实现都用list，那自然这样的传入不会引起很大的麻烦。但还是希望能找到一种方法，能够不用list传入，内部实现就根据个数而定，一个、两个位置的就使用单独的位置成员变量，对于多个位置的自然需要使用list。若想实现这样的R值，就需要解决位置的setter接口如何统一的问题。有一种方案是对每种数量的位置都专门设立一个改变位置的接口，但是这样就使得改变位置需要与位置数量相关联，并且又多出了很多类，故没有采取。最后采取的方案是，setter方法仍放在涉及位置数目的接口中，但初次创建涉及位置数目的接口时需先传入一个被委托的涉及位置改变的接口对象，这个对象只用于判断该位置是否可以被预设、被改变，并不做任何实际修改。这样的实现虽然解决了上述问题，但还是有所缺陷，多增加了一层委托关系，使得整个结构变得更加复杂。但想了很久也没有想到合适的方案，最后还是采用了最后一种。
对于可复用性和可维护性的体会，个人觉得，如果只是开发一个小的程序，只开发一方面的应用（比如只做航班应用），那么像这样划分很多维度设计很多接口带来的收益就相对小了很多，但也对未来可能的变化带来了一定的适应能力。对于开发大型的程序，或者涉及到多方面需求（比如实验中这种需要同时针对三个方面应用进行开发的），那么抽取共性，划分多个维度设计多个接口，虽然开始时工作繁琐，但是对未来可能的变化有很强的适应能力，且易于维护。互相之间还可以复用，有很大的益处。因此，实际设计中是否在开始时就要做很强的可复用性和可维护性的设计，应当取决于实际需求，具体问题具体分析，权衡其带来的收益（可复用性和可维护性主要带来的是未来的收益）与其提高的成本。