问题描述
今天看了一个跟接口有关的例子针对接口编程能帮助达到面向对象开发和设计中"低耦合"的要求.举个例子:某公司有一台特殊打印机,还可以使用一年,一年后可能换为另一种打印机,这两种打印机都特殊而贵.所以现在的程序希望换了打印机后也少量修改就可用.方法:1,定义一个打印机接口.2,定义打印机类A,B,分别实现此接口.3,定义一个工厂类,在类中可选择返回由A实现的接口,或者由B实现的接口.4,在程序中使用打印机时,就可以使用工厂类来调用打印机,而不需要知道具体的是什么打印机.如果打印机换了,只需要修改工厂类就行了.如果有一千个地方都调用过打印机,就不需要一个一个修改.修改一个地方就行了.接口充当一个隔离层的作用.在面向对象的设计中,接口的作用非常重要,//定义打印机接口interfaceIprint{boolPrintData(stringdata);}//定义打印机类A,实现接口classPrintA:Iprint{publicvirtualboolPrintData(stringdata)...{//具体业务逻辑略}}定义打印机类B,实现接口classPrintB:Iprint{publicvirtualboolPrintData(stringdata)...{//具体业务逻辑略}}//定义工厂类classPrintFactory{publicIprintCreatePrint(){//返回一个由打机类A,或B实现的接口,比如returnnewPrintA();}}//通过工厂类,调用打印机privatevoidbutton1_Click(objectsender,EventArgse){PrintFactorymyFactory=newPrintFactory();IprintmyPrint=myFactory.CreatePrint();myPrint.PrintData("这样做很方便啊");}我自己将上面的例子改了一下，我觉得更好classPrintA{publicboolPrintData(stringdata){//具体业务逻辑略}}classPrintB{publicboolPrintData(stringdata){//具体业务逻辑略}}//定义工厂类classPrintFactory{publicboolCreatePrint(stringdata){PrintAaa=newPrintA();returnaa.PrintData(stringdata)；}//通过工厂类,调用打印机privatevoidbutton1_Click(objectsender,EventArgse)...{PrintFactorymyFactory=newPrintFactory();myFactory.CreatePrint("这样做很方便啊");}从上面的例子中，我自己觉得我自己做的不用接口还更好一点啊。更加方便一点啊。请问各位高手，接口在实际运用中的到底有什么作用，能不能用这个例子，来说明一下呢？我看过一些例子，但都是对怎么定义接口和怎么用接口的说明，我想知道接口在使用中到底有什么好处。
解决方案
解决方案二：
学习学习学习学习学习学习
解决方案三：
回帖是一种美德！传说每天回帖即可获得10分可用分！连续两周技术区参与者，每周额外可以获得88个可用分小技巧：教你如何更快获得可用分
解决方案四：
看看设计模式的规则你就明白了，工厂的责任和打印机的责任不同，不能把打印的责任交给工厂。这叫责任分离
解决方案五：
引用3楼shoushii的回复:
看看设计模式的规则你就明白了，工厂的责任和打印机的责任不同，不能把打印的责任交给工厂。这叫责任分离
嗯，尤其是设计模式前面的那几个原则。
解决方案六：
引用楼主weixing06的帖子:
classPrintFactory{publicboolCreatePrint(stringdata){PrintAaa=newPrintA();returnaa.PrintData(stringdata)；}
实例化一个打印机的时候就必须给出data参数才能实例化？并且“默认”打印了？你自己“觉得更好”，但是你肯定没有想得稍微远一点。实例化就是实例化，我宁愿“笨”一点。否则，反而弄巧成拙。
解决方案七：
引用楼主weixing06的帖子:
接口在实际运用中的到底有什么作用，能不能用这个例子，来说明一下呢？我看过一些例子，但都是对怎么定义接口和怎么用接口的说明，我想知道接口在使用中到底有什么好处。
举一个例子。你可以创建一个“电话机”类，然后有一天你想明白了一个创造，于是可以让你自己发明的电话机操作系统实现IPrint接口，于是你就发明了传真机。
解决方案八：
顺便说一下，“设计模式”的“原则”是很宽泛的，它想把什么都包括，就像“吃维生素治百病”一样。一般来说，模式只是你经验的后期结果，前期你会对模式胡乱使用。因此，暂时忘记模式，多多深入编程细节更重要。
解决方案九：
引用3楼shoushii的回复:
看看设计模式的规则你就明白了，工厂的责任和打印机的责任不同，不能把打印的责任交给工厂。这叫责任分离
引用5楼sp1234的回复:
引用楼主weixing06的帖子:classPrintFactory{publicboolCreatePrint(stringdata){PrintAaa=newPrintA();returnaa.PrintData(stringdata)；}实例化一个打印机的时候就必须给出data参数才能实例化？并且“默认”打印了？你自己“觉得更好”，但是你肯定没有想得稍微远一点。实例化就是实例化，我宁愿“笨”一点。否则，反而弄巧…
工厂制造打印机...不负责打印...面向对象要站在对象的立场上想问题而不是站在你自己的立场上去要求对象替你着想...
解决方案十：
其实GOF设计模式并没有去明确地去首先研究“责任”问题，他基本上是就事论事地研究编程问题，因此很容易被人误解为“以方便编写代码为目的的技术”。只有后来又看了GOF之后很多年出现的书籍的人，反过来把“职责”加入“模式”，努力想把设计模式提高为系统分析技巧的高度，好像设计模式中已经说明了系统分析的技术了。其实，我认为GOF的设计模式值应该作为编程经验总结，而非系统分析和设计的入门。
解决方案十一：
其实，许多人都不赞成不了解OO的人去先去看“设计模式”，大多数“过来人”都知道“应该学好OOAD”，用关于职责等类似的知识作为设计工具，而不是首先去学“设计模式”。
解决方案十二：
楼主的认识感觉太专注于,你看到的例子了,你看到的例子中,打印机只有一个printdata,而如果我还有一个ChangePaper呢,按你的做法,你的工厂类也就不是工厂类了,你的工厂类将与你的App高度耦合
解决方案十三：
引用10楼sp1234的回复:
其实，许多人都不赞成不了解OO的人去先去看“设计模式”，大多数“过来人”都知道“应该学好OOAD”，用关于职责等类似的知识作为设计工具，而不是首先去学“设计模式”。
支持
解决方案十四：
设计模式更有用应该是属于交流时的对细节的封装。比如有一个接口有一个方法叫排兵布阵，福拉多类实现了这个接口，在指挥中国队。后来足协想用别人dll中的杜伊类的排兵布阵，但它没有实现接口，那么足协对你的要求就应该是：为接口和杜伊类做一个适配器。简单一句话，你就知道怎么去做代码了。
解决方案十五：
面向对象啊