c#关于接口增加新方法问题
static voic Main(){
Console.WriteLine("Plesas select printer：");
string printerName = Console.Readline();
IPrint printer = null;
if(printerName == "HP")
{
printer = new HPPrinter();
}
else if(printerName == "IBM")
{
printer = new IBMPrinter();
}
printer.PrintPreview();
printer.Print();
}
--------------
public class HPPrint : IPrint
{
public void PrintPreview()
{
Console.WriteLine("this is HP Printer");
}
public void Print()
{
Console.WriteLine("this is HP Printer");
}
}
public class IBMPrint : IPrint
{
public void PrintPreview()
{
Console.WriteLine("this is IBM Printer");
}
public void Print()
{
Console.WriteLine("this is IBM Printer");
}
}
好上面代码不错了，但有一天突然需要加一个方法 size() 设置打印大小，正常想法是给接口增加一个方法，子类也去实现它。但如是子类数量很多时，这将是一个苦逼的工作。我想问一下如何处理这种情况，让增加新方法更容易，不用涉及其它子类。
--------------------编程问答-------------------- 我现在的问题就是上面描述的一样，一会这人说要加个方法，一会另一个人也要加个方法，继承接口已产生了很多类，方法一加其它人的代码就要变化，这让协同开发的人员很不方便，我也想过一些办法，比如产生几个 para1 para2这种可自义的参数，让它们自己实现放到这里面去。但这样问题又来了，就是定义不清楚需要程序定义者向大家完整解释才行，不然根本不知道这个方法在做什么,沟通成本大大增加。 --------------------编程问答-------------------- 没有办法，所以定义接口的时候要特别谨慎。
你看微软经常是 IWebBrowser2、IPersist2、IPersist3 IXXXn，如果你需要改动接口，为了保持向前兼容性，你只能再定义一个新接口。 --------------------编程问答-------------------- 另外，如果你是做细粒度的设计，你应该多用属性、事件，少用接口。 --------------------编程问答-------------------- 如果不是每个子类都必须增加一个实现,那为什么要为这个接口增加职责呢?
增加一个接口就是了(无论是另起炉灶,还是继承原来的接口),你需要谁去实现,就让谁去继承 --------------------编程问答-------------------- 同意4楼的，你可以再单独写一个接口让需要的类继承呀 --------------------编程问答-------------------- 既然接口一直变动,你写个虚基类就可以了,给个默认实现.所有子类继承这个基类,你在基类加办法随便加,子类要不要override是它自己的事了 --------------------编程问答-------------------- 继承一个抽象类定义共有方法 --------------------编程问答-------------------- 经常遇到的问题，学习了。 --------------------编程问答-------------------- 如果所有的子类类的实现都一样 你可以在基类中加这个方法 而不是加在接口里
如果不是所有的子类都需要这个方法，实现也不相同，可以再增加一个接口，让需要的类实现新接口就可以 --------------------编程问答--------------------
这也是我现在用的方法之一就是开新的接口，只是增加了代码量加大代码维护。程序我发现大多是这样开始都规划的不错，使用发现不是这么回事.接着变动开始了，东改西敲最后做不下去了，好开始重构吧。 --------------------编程问答-------------------- 写个虚基类,给个默认实现.所有子类继承这个基类,你在基类加办法随便加,继承抽象类定义的共有方法 --------------------编程问答-------------------- 发贴的时间就改完了,
如果真有什么方法,我到也想知道. --------------------编程问答-------------------- 个人感觉在接口中修改不如重新定义接口，修改后之前的东西难免不会受影响。怎么样都会加大代码维护。
菜鸟路过学习
--------------------编程问答--------------------
使用接口时以为可以像class一样地轻松继承，这必然感到“苦逼”！这也是我刚刚使用.net（2002~2004）的前几年的感觉。我其实那个时候对它不能像Eiffel一样支持多重继承比较不以为然。不过慢慢就习惯了。基本上，如果你需要扩展一个接口，你需要设计一个Version2之类地。比如原来有一个
public interface Ixxx如果你需要扩展（并且确定一段时间内只需要扩展）一个属性那么可以这样写
{
string Name { get; set; }
string MarkedValue { get; }
event Action NameChanged;
}
public interface IxxxV2: Ixxx
{
DateTime TheTime{get;set;}
}
注意，什么叫做扩展、什么叫做重新定义，我们肯定应该从设计上去找根源，要先“拔高一点”站在逻辑设计人员的高度，不要“俗气地”仅仅站在程序员的那种图省事的角度。
你对重构有着根本性的误解。如果你打开《重构--......》的书来看，你会看到很大的篇幅、很重的笔墨，甚至即使是其它篇章的每一部分的最后段都写着：需要测试驱动。
也就是说，重构是在维系以前的测试基本上全都通过的情况下，才重构。不是胡乱修改之前设计的接口。
所以修改，那个叫做制造代码“臭味”，而不是重构。 --------------------编程问答-------------------- 所以修改，那个叫做制造代码“臭味”，而不是重构 --> 仅仅随意去修改，那个叫做制造代码“臭味”，而不是重构 --------------------编程问答-------------------- 把重构当作儿戏、当作时髦的东西，对于初学者也许是很好玩儿的，但是对于负责任的开发人员则会是非常头疼。因为胡乱修改代码，会以“重构”当作借口。我们应该承认很多借口“重构”的人实际上是在用“一种臭味掩盖另一种臭味”。因此我们要注意重构是有条件的，需要你有很高的技术时才去重构，没有足够的技术时你只能小心翼翼地维系代码而不能重构。
参考：http://bbs.csdn.net/topics/390204077 --------------------编程问答-------------------- 不懂接口,就别用它
问题不是它产生的,就别指望它帮你解决问题 --------------------编程问答-------------------- 继承一个抽象类 别直接继承接口 --------------------编程问答-------------------- 为接口引入一个抽象版本，具体的实现类继承这个抽象类。
比如当你在原有的接口中增加一个新的方法时，抽象类增加实现此接口的抽象方法。这样你只需要在需要实现此接口的子类中override它，其他的子类也会受到影响。 --------------------编程问答--------------------
这种想法就是，我脚上长了一个鸡眼怎么办？很简单，做一个截肢手术就好了。 --------------------编程问答-------------------- ls 大师 都说的蛮有道理的 学习ing 3Q分享 --------------------编程问答-------------------- 这有何难，用扩展方法就行了，用不着那么复杂。 --------------------编程问答--------------------
--------------------编程问答--------------------
组合代替继承。http://www.cnblogs.com/x-xk/archive/2012/12/21/2823401.html
这里面引用了head first设计模式的第一个例子，很好的说明了这个问题。 --------------------编程问答--------------------
学习了，关注你了，希望能看到你更多的评论与分享。 --------------------编程问答-------------------- 接口并不是越多越好。。 定义一个抽象类可以解决许多问题。 --------------------编程问答--------------------
我不说话 ，只学习。。。 --------------------编程问答-------------------- 个人觉得更简单的方法是可以写一个主类MainPrint
所有子类继承接口的同时也继承这个主类
格式如下
HPPrint : MainPrint, IPrint
这样在MainPrint下定义的方法及属性都可在子类使用，并且不影响到接口结构。
当然你也可以部分子类继承MainPrint，部分不继承 --------------------编程问答-------------------- Visitor 访问者模式是解决这个问题的好办法，请查看。 --------------------编程问答-------------------- 不是接口的问题，是你的问题，其实你有解决方法，但是你过分追求完美化！你不可能做到完美。 --------------------编程问答-------------------- 再 声明一个接口，让需要的子类实现。 --------------------编程问答-------------------- adapter --------------------编程问答-------------------- 很好，这就涉及到设计模式的应用问题了 --------------------编程问答-------------------- 接口与具体类之间，放一个抽象类来解决
--------------------编程问答-------------------- 接口污染,就是指的你这种情况,这个时候分割接口来避免接口污染,简单说就是在声明一个接口,让需要实现的类实现;
public abstract class PrintBase:IPrint
public class HPPrint : PrintBase
public class IBMPrint : PrintBase
如果不想改代码,你就当初应该选择继承~~ --------------------编程问答-------------------- 牛掰，学习了 --------------------编程问答-------------------- 顶29楼,不过我对这个访问者模式存在看法,可能我还不能领悟它的精髓吧 --------------------编程问答-------------------- 呵呵，美工都会，难道程序员不会
美工写css，当多个dom需要一样的css他怎么办？当多个dom有一部分样式是一样的，还有一部分是不一样的他又什么办？当已经定义了样式1，却发觉这个场景需要根据细节做局部修改，他又怎么办？
太阳底下木新鲜事，接口或者样式不是无条件的，接口是有目标滴，围绕目标编写你的代码，而不是根本就不看目标，一上来就号称“面向接口” --------------------编程问答-------------------- 根据设计原则，是要依赖接口，而不是依赖实现，其另外一层意思就是依赖的接口是不能变化的，这就需要保证接口设计是合适和够用的，无论什么样的设计模式都无法解决接口变化的问题，这也是考验设计水平的地方。要不然人人都会设计模式了，难道说设计水平都会是一个水平吗？ --------------------编程问答-------------------- 适和够用的，无论什么样的设计模式都无法解决接口变化的问题，这也是考验设计水平的地方。要不然人人都会设计模式了，难道说设计水平都会是一个水平吗 --------------------编程问答-------------------- 除
补充：.NET技术 , C#
