关于接口和工厂模式的一点疑惑

Question

    小弟自学JAVA一段时间了，现在有点问题有点搞不懂，挺困惑的，希望各位大虾们指点下：
    1：关于接口：
对于接口知道用，但是对于为什么用有点困惑，接口的使用好像说优点比较大的是低耦合，有点不是很明白，我看来接口最大的作用还在于向上转型，哪位给详细讲讲，再就是对于接口的应用与类的应用，在继承体系中选择接口还是类的继承有点困惑，在继承体系中，子类与父类很多地方是相似的如果选择实现一定功能的类和接口相比劣势体现在哪呢？通过继承貌似还可以少写不少代码，只把需要的方法重载下就行了，感觉也挺方便的
   2：关于工厂模式和向上转型
工厂模式中给不同的子类有一个产生对象的类，如果在继承体系中子类与父类的方法都一样只是实现上不同，通过向上转型那只有一个类负责产生对象即可吧
    高手们解答一下吧，有点转不过来了
    ps:对于程序的效率问题，现在感觉遇到一个瓶颈，能正确的完成需要完成的功能，但程序的效率有点偏低，再选择算法和方法时却不知道怎样去改进，不知道有什么还的方法提高一下呢，大虾们给点建议吧，小弟谢谢了哈

Answer 1

我来抛砖引玉吧
你说选择接口还是类来继承这个问法就有问题，接口跟类的作用是不一样的，比如
有个类叫：动物
有个类叫：鸟
有个接口叫：可以跑
有个接口叫：可以飞那关系就是鸟继承动物，实现可以跑和可以飞的接口为什么要用接口呢？比如你写一个程序，你处理的是所有会飞的东西，你不需要知道它是飞机还是麻雀，那你的方法可以这样写
     dealFly(Flyable f){}
Flyable 是个会飞的接口，麻雀和飞机都继承这个接口，但麻雀和飞机的飞法肯定不同，但你不需要管写麻雀这个类的同事可能在上海，写飞机这个类的同事可能在深圳，而你在北京，大家只需要面向接口编程，
这叫“关注分离”，每个人只需要做好自己的事

Answer 2

另外，java是单继承的，一个类只能有一个父类，那如果你想实现多继承怎么办？
接口是可以实现多个的，另外还有个内部类，可以用来解决多继承的问题

Answer 3

还有，代码的复用一般用“组合”而不要用“继承”来实现
关于这些问题可以看看《thinking in java》

Answer 4

我对这个的理解是这样的接口是对行为的封装。要封装的原因就是：需求的变化或者说行为的多样化（这是我自己琢磨出来的表达很山炮）其实接口反应的无非就是对象的行为特点。引入它的目的是为了使变化的部分隐藏，一旦需要修改，在使用方看来，是感受不到变化的。比如，物流公司，他对你表现出来的一个特点是：可以送货到目的地。或者说送货就是他的接口但是他是怎么做的呢？是汽车、火车、飞机还是骑自行车。你不用关心，如果他们的汽车坏了，换成自行车运送，对你来说没有影响.(当然这个例子比较牵强，因为时间没有考虑进去)可以说，物流公司把送货这个行为的实现方式隐藏在了自己内部。减少了用户所需要知道的知识（最少知识原则）。为熟么好多人说要少用抽象类呢？因为抽象类相对来说规定的更死一些。如果你要用抽象类来声明抽象方法，当多个抽象方法声明在一个抽象类里的时候，你会感到别扭，因为他们明显不是一个对象表现出来的行为。但是为了抽象方便，放在了一起。而问题远不止如此。因为你会发现这些抽象方法你的具体类需要全部实现，使用者使用你这具体类的时候，有些抽象方法其实你是不想让他知道的。比如：你有三个抽象方法
public abstract void method_1();
public abstract void method_2();
public abstract void method_3();
你的实现类，就要实现这三个方法。但是，某个程序要使用你的Jar,你给他提供的是方法1，方法2和3是不想让他看到的。这个时候你怎么办？如果用接口实现的话会不一样。你可以写多个接口比如：
public interface interface_1{       public void method_1();
}public interface interface_2{       public void method_2();       public void method_3();
}你的具体类实现两个接口，上面说那个程序要调用的时候，你给他返回的是 interface_1这个接口声明的对象。这个时候，他看不到其他方法了。
后面的问题稍晚些时候回复你

Answer 5

1、接口
   要弄清楚接口和继承的优缺点，就要知道，为什么java要使用接口。java中一个类只允许继承一个父类，这个时候如果要继承多个类的话不可能实现，用接口其实也就是弥补了这个缺憾。我们不能继承多个类，却可以实现多个接口。接口相比父类的缺点就是其内部方法都是空的。
2、关于低耦合，你说对了，接口确实能够降低耦合度。打个比方，有个方法a(B b);如果说，B是一个实体类的时候，那么每次调用这个方法就必须以B的实现类作为参数，或者使用其子类，B有修改时，可能就要影响到a方法的执行。如果说B是一个接口，那么我们不用去管调用方法时参数的具体类型，只要一个类实现了B这个接口。而且，这个b所属类型的具体实现的修改不会影响到a方法的调用。

Answer 6

3、工厂模式  用一个工程类可不可以就要看这个工厂类是怎么实现的，如果其中产生实例的方法返回的是new父类的话，那你说的那样是不可以的。因为这个类仅产生父类对象。
   除非工厂类使用反射机制，一个工厂就可以通吃所有的类了。

Answer 7

你所说的使用一个类来作为工厂的问题。不知道你是否在工作中写代码是MVC分层的。你觉得分层有必要吗？你这个问题可以变成，我为什么要MVC分层呢？JSP里一样可以启动事务调DAO啊.好好想想设计模式的目的是什么。你就知道为什么不用一个工厂类来做了。学了Java的语法，设计模式的思想，然后结合自己的实践，才会明白如何去运用。没有一定量的积累就去看书，看了也没什么大用。关键是多写代码，边写边想，不断调整。就好像外科医生，即使再优秀的学生，毕业后也不可能马上上手术台给人主刀，就算你读了再多的著作、门门满分，也没用。因为理论没有实践的支撑。我们做工作或者认识一个新事物，其实一般都是从这样的顺序的第一，它是什么
第二，我们怎么用
第三，它为什么是这样的Java语言基础是第一步
平时工作写代码是第二步
理论是第三步我不建议你，没有做第二步，就去做第三步。我们都学了UML，很少有软件学院不学这个。但是我们为什么要用UML？再延伸一步，我们为什么要去建模？为什么要用面向对象？怎么去建？什么是模？有几个人知道？老师貌似也很少讲。所以这事学到最后，记住几种图是什么样的，干什么的。就考试了。这学了和没学没什么区别。一不小心说多了关于代码的效率算法。我的意见是，你遇到效率问题的时候，首先要清楚效率低低在了哪段代码上。然后分析为什么低。再去想是否有优化的余地。你不知道怎么去改进我觉得更多的是因为你不知道上面这两个问题。关于调优，我也是菜鸟，没什么太多的经验。只会具体问题具体分析，而且很多时候分析的还不好至于总结出规律来，我估计你8-10年以后再问我，如果我资质好的话，可能能有点个人总结最后建议：写代码，多写。编写边思考。先抽空去读读《重构》这本书的前两三章看到自己的代码里有“坏味道”的时候，别着急找样例去改，先考虑自己是否可以解决这个问题。在解决问题的过程中遇到麻烦再去请教厉害的人。这样干2-3年，然后你在看设计模式，应该会有恍然大悟的感觉。