软件设计的臭味与原则

 

软件设计的臭味与原则

 

《敏捷软件开发》--- 关于设计 的总结：

       根据以前阅读的经验，传统的软件开发中，设计与实现是有明确的界限，先设计后实现，但在现实开发中，需求是在“实现阶段”频繁变化，我们的软件设计师之前所设计的软件能经得起这些变化吗？风险好像很大。而敏捷软件开发中，设计与实现没有明确的界限，边设计边实现，所做的设计只适用于当前的系统，够用就好。但不管是事先设计还是边设计边实现，需求的变化都将腐化我们的设计，慢慢散发出代码臭味。如：

 

n         僵化性 --- 设计难于修改

n         脆弱性 --- 设计易于遭到破坏

n         顽固性 --- 设计难于重用

n         粘滞性 --- 难于做正确的事

n         不必要的复杂性 --- 过分的设计

n         不必要的重复 --- 滥用鼠标进行复制、粘贴

n         晦涩性 --- 混乱的表达

 

为了是消除这些臭味，我们必须遵守一些面向对象的设计规则。规则如下：

 

n         单一职责原则 ---  一个类只有一个发生变化的原因

n         开放封闭原则 --- 软件实体（类、模块等）应该是可以扩展，但是不可修改

n         Liskov替换原则 --- 子类型必须能够替换掉他们的基类型

n         依赖倒置原则 ---

A、 高层模块不应该依赖于低层模块。二者都应该依赖于抽象。

B、 抽象不应该依赖于细节。细节应该依赖于抽象。

n         接口分离原则 --- 分离“胖”接口

疑问：

       软件工程范畴：

我在想，敏捷软件开发好像跟“不规范的软件公司”开发流程一样，边设计边写代码边需求？还是在原先“不规范的软件公司”发流程多了一份完整的规范？多了TDD…？

 

软件设计范畴：

就“单一职责原则”，换句话说，一个类应该只有一个“Public”方法？但现实开发中，如一个用户类“User”,通常会包含这些方法 “AddUser”、“Login”，“SelectUser”等方法。这不是破坏了类的内聚性？难要要把这些职责分离，分解成多个类？那类的数目将不是很多？

 

请指教。