敏捷思考 遵循与破坏"开闭原则"

使用敏捷方法“极限编程”确实有一条原则是“简单设计”，这个原则是说在设计的时候应该保持最简单，不要为未来可能发生的变化预留各种变化的空间。这个听起来是对设计模式的一种否定，其实不是，敏捷不与软件设计相冲突，敏捷崇尚的是重构，即需要的时候才用，按照楼主的例子，运用XP，很可能是这样的一种情况：开始的时候确实是方案一设计，当用于提出XML需求的时候，重构原有代码成方案二；如果客户始终不提出，那么最终就以方案一告终。

敏捷是淡化设计，但是并不反对和抵制设计，又怎么会冲突，它只是强调“需要的时候才要”。

这个帖子很好，正是我正在思考的问题。
其实对于开闭原则，是对修改的封闭是对扩展的开放，那么什么是修改呢？？对一个类文件增加了一个新的方法这是修改吗？修改是对原有设计的修改，原有代码受到影响，这才是修改，如果只是增加了一个方法原有设计未受一点影响这不叫修改。

对于增加保存用户到xml，我个人会把它看做新增的需求 而不是对原有需求的修改，因为原来的保存到数据库的逻辑一点都不动，并且一点都没有影响到其他代码，那么这只是修改了dao文件，对原有文件增加了新的动作或者逻辑而已，所以我会增加一个方法saveUserToXMl之类。

我不会建立一个接口，i因为使设计更加复杂呢
更不会采取ifelse方式这个明显就是代码的坏味。

OCP的修改不是针对代码级的，而是系统设计级上的，对原有系统不构成影响的修改就是扩展，原有系统对新增加的修改不会失去原有的功能和稳定性。
不过最好还是不修改原有代码类

其实你的做法只是把if else提到了外部，变成这样:

UserService
-----------------------
SaveUser(user,isXml)
{
if(isXml)
    DAO.saveUserToXML(user);
else
    DAO.saveUserTODatabase(user);
}

系统设计级别？系统不就是程序吗？程序不就是代码吗？

[quote="solonote其实你的做法只是把if else提到了外部，变成这样:

UserService
-----------------------
SaveUser(user,isXml)
{
if(isXml)
    DAO.saveUserToXML(user);
else
    DAO.saveUserTODatabase(user);
}

难道一定本要在service 判定存储方式吗？？？对于系统来讲难道，存储为xml或者使数据库中，不是客户端做的事情吗？？这个问题没有那么复杂，2个接口很清晰。

呵呵，其实我并没有说你的做法是错的，我只是说这和if,else写在DAO里是一样的效果，本质的问题在于这违反了OCP，当然，我们并不一定需要遵循OC原则，这要看你具体的要解决的问题,我举得例子并不是说这个场景要使用OCP，我只是想表达敏捷设计的OCP我觉得应该是这样做的，希望你能理解

[quote="solonote，我只是说这和if,else写在DAO里是一样的效果，本质的问题在于这违反了OCP，当然，我们并不一定需要遵循OC原则

呵呵，在调用的客户端也就是js或者jsp中，就可以判定是哪种存储方式了，没有必要写出if else 这样很可能是代码坏味，无论是在service还是dao中，这样完全避免if else。

通过我们的讨论。我更清晰了这样一个东西：
OCP只针对一个特定的对象，这只是一个if/else放在哪里的问题，我们始终逃不开判断哪一个具体实现对应哪一个业务。比如我们用第二种方式，扩展更多的DAO，并不需要改变Service。If/Else只是交给容器去做了，它或许不是那么明显，比如是一个配置文件，或者你说的js/jsp.
OCP的针对的就是一个依赖于抽象的对象，比如Service依赖于抽象的DAO接口，那么Service就可以被重用。而你是否值得这样做是谁也说不清的。遵循敏捷设计，在你中弹时，你可以考虑遵循OCP。
另外我们应当充分考虑遵循OCP所要付出的代价，If/Else还是要写的，只是挪了地方，或者换了方式，所以这种方式会明显增加系统的复杂性，付出更多的人力。遵循敏捷设计，我们一开始不必要做这样的过度设计。
这就又可以讨论到容器的作用，比如Spring，它让If/Else的规则定义变得非常简单，所以在这样的环境下用OCP成本相对是较小的，如果没有这样的容器环境，我们就应该更加注意这一点。

需求是什么？
不用SQL用XML？
那好办把注入的DAO换成对应的xml类型
只要改一个地方写一个类就结束了
由一个开关来决定用哪个DAO？
那也好办把开关改成XML
都不用编译
由客户决定用哪个方式存贮？
你疯了？数据完整性怎么保证？