如何做扩展的设计？
0
悬赏园豆：50
[已解决问题]
解决于 2010-07-26 16:47
举个简单的例子，
有一个用户发布新闻的功能，
新闻实体
public class News
{
public string ID{get;set;}
public string UserID{get;set;}
public string Name{get;set;}
}
如果说用户发布一个新闻，则是调用逻辑类的AddNews()方法。
现在需要增加一个新需求，要控制用户发布新闻的数量。
最常规的做法就是在用户实体增加一个新闻数量的标记属性，在AddNews()里加入判断控制，同时每则增加一个新闻则改变新闻数量的标记。
我想请教的是：如何在一开始的设计中，就预留这种可能的扩展，在类的设计中应该怎么去做。能做到在新的需求中能最少的改变，实现最小的偶合。
盼高手指教，万分感谢！
问题补充：
忽然想到，能不能这样设计：
public interface INews
{
void AddNews();
}
public class NewsRules:INews
{
public virtual void AddNews()
{
HttpContext.Current.Response.Write("添加成功");
}
}
public class NewsFactory
{
public INews GetFactory()
{
return new NewsRules();
}
}
客户端调用：
INews cmd = new NewsFactory().GetFactory();
cmd.AddNews();
如果有新的需求增加，比如以上列举的需求：
增加
public class NewsRules2:NewsRules
{
public override void AddNews()
{
//逻辑判断是否能增加
base.AddNews();
//增加成功，修改用户的发布数量
}
}
修改NewsFactory的GetFactory方法为
public INews GetFactory()
{
return new NewsRules2();
}
客户端调用不需要修改。
向各位大大们请教一下，以上的设计在实际项目中有实用价值吗？会不会有过度设计的嫌疑？
或者有什么更好的方法，能指教一下吗，谢谢
最佳答案
0
定义一个明确的新闻发布的动作周期
比如
【检查是否允许发送】-【筛选细纹内容】-【发送新闻】
【检查是否允许发送】 这个可以定义成一个接口
之后就参考策略模式 可能你有好多策略 可选择可配置
收获园豆：15
其他回答(3)
0
程序永远都是为业务服务的，所以在搞清楚业务之前做代码很可能是不满足业务需求的，像上面所说的这种属于一个业务功能，也就是说这是需求的一部分，只能在设计之前就搞清楚，而后期去完善就只能去改原来的设计了。当然了，为了尽量降低后期维护的更改范围，可以这么做：设计一个类，属性中包含其他实例，具体有哪些实例是通过读配置文件，通过反射生成，这样方便扩展，但是在实际操作过程中，该原来的代码是难免的。
收获园豆：15
谢谢您的回答。 不过既然举了个例子，希望能在这个例子的基础上简单讨论一下。
个人感觉反射这个东东能不用则不用。
不知道你有没有看过业务流系统方面的资料，每一个业务流都有多个业务处理组成，之间通过逻辑判断连接，由于存在多种业务流，所以必须要求程序在每个业务上是松耦合的，说白了就是通过拖拽业务处理和逻辑处理就可以创建新的业务流（在项目审批流程中较为常见），如果哪天需要添加一项逻辑处理，只需加入相关.dll文件，然后通过系统配置一下，这个逻辑处理旧加入到了系统中，可以通过拖拽使用了。这个配置实际上操作是数据库表或一个配置文件。
0
接口的方法加两个参数.
public interface INews
{
void AddNews(ref News news,ref User user);
}
不要继承旧的操作类,继承接口
public class NewsRules2:INews
继承旧的类不利于维护工作,而且NewsRules2和NewsRules是同一层次的,使用继承会模糊该类的意义.
收获园豆：15
NewsRules2继承NewsRules是因为“添加新闻”这个逻辑是不会变的，NewsRules2可以复用这个功能，只是在其基础上再添加一些流程，比如判断，控制什么的
如果以后再增加一个需求NewsRules3，如果是在NewsRules2的基础上变化则还可以继承NewsRules2，不然直接继承NewsRules，其实这里只是把NewsRules当做一个最基类处理。
0
业务变动，添加类与方法，而不修改原有。
收获园豆：5
