面向对象设计原则: 面向抽象编程而不是面向实现编程。
对扩展开放对修改封闭。
这两个原则都是需要我们能够提炼出抽象部分,并明确潜在的变化部分才能够对症下药的,我们不可能假设系统所有的地方都是潜在变化的,并创建抽象类留足扩展空间的,这样设计出来的系统是不可想象的,所以我么必须找到系统中相对稳定的部分,当然,全面的需求收集是不可能的,因为需求永远都在变化中,但是,在一段可预见的时间和版本控制上,我们必须假定系统的需求到某一个程度是应该封住并在假定的某些条件下是不再演化了的,如果不这样就不能停止开发也不能发布相关的版本,对一个系统来说,不可能所有的需求(业务)在一定时间内都在变化,总会存在着一些相对稳定的业务,如果对需求(业务)不做充分的收集和分析,又怎么能够抽象出系统相对稳定的部分和相对容易变化的部分,并做好相应的设计方案,封装变化点呢?所以对UP这个在需求的把握上我还是存在很多疑问,希望继续深入能找到答案。
也许使用UP过程的团队对正在开发的项目的业务领域有相当的经验,这样在需求收集不是很充分,分析不是很深入的情况下开始编码可能根据经验可以留出适当的扩展空间,在这里就彰显经验的重要性了,一个老到的系统分析和结构师会比较容易嗅出需求(业务)中比较容易变化的地方,桥过多了,路还走的少吗?这也可以解释一般的软件公司都会专注于某一块领域里的软件开发的原因,第一个是有沉淀下来的基础框架,第二就是经验了,第三:客户也比较容易开拓
![](https://i-blog.csdnimg.cn/blog_migrate/97335b9014faa8c94b0b16d893e467e3.gif)
在没有得到更好的答案前,我只能这么想:UP也好,瀑布也好都是软件工程的一种方法过程,不一定在所有的项目中都必须使用相同的软件工程方法,应该量体裁衣,寻找适合的方法即可,多一种方法只是多一种选择而已,软件工程没有银弹,当是可以有很多子弹。
对于UP还必须继续多看书。