子类父类实现同一接口

借问仁兄能不能详细解释呢？
interface A {
}
class B implements A {
}
class C extends B implements A {
}
子类已经继承了父类的行为。C 在这里implements A和不implements A有啥区别的呢？
个人觉得这里实现A接口，只能会是代码质量低下（代码读起来有点怪），举个例子

interface A {
	void f() throws Exception;
}
class B implements A {
	public void f() throws IOException {}
}
class C extends B implements A {
	public void f() throws Exception {}
}

如果只看接口A中抛出的异常是Exception，那C实现A接口，抛出Exception无可后妃。但这里C编译是通不过的，因为B已经改变了f的“异常范围”，所以个人认为，C的实现接口A是没任何意义的。。。。

不用测试，肯定是序列化了的。。。。因为B继承了A。。。复核“IS A”的定义

严重同；
变量，静态方法，似有方法都没有继承关系。何谈影响？

跪 求打击。。。

想想设计模式中，这么做的又几种？装饰器和代理都可以通过这种方式实现。楼主说的这样做法，可以用来解决动态增加功能和代理功能。

新手弱弱的问一句  如果B是abstract类  不是可以不完全实现接口A里的方法么？ 这样的话B可以作为接口A的修改和补充    某一C类需要B和A的完全实现  依我看来  单纯这两句看不出什么  争议性太大了 例如这样：

public interface A {
	void Atest1();
	void Atest2();
	void Atest3();
}

public abstract class B implements A {

	@Override
	public void Atest1() {

	}

	@Override
	public void Atest2() {

	}
	
	public void Btest1(){
		
	}
}

public class C extends B implements A {

	@Override
	public void Atest3() {

	}

}

按照Java语法没必要这样做的.
但这里所要表达的是,具体继承并不是用来设计目的，而是用来实现细节的，设计应该是基于接口展开.
好一些的做法是,B总应该是一个抽象类,用于对接口进行基本的骨架实现,C为具体类进行最终实现,C对接口A的实现过程中使用了便利类B。
接口A为外部类看到的功能接口，这里所想到表达的C是一个A类型,B只是C实现A过程中的一个步骤,这样接口,抽象类,具体类三位一体的将得到最好的设计.

最好的例子为Java Collection Framework的设计.

比起不懂为什么C要去实现A，如果能理解了基于接口的设计，这个也就不重要了.
下面的例子也使用相似的设计风格,相似度达到90%以上:Spring 的BeanWrapper功能组件设计.

 

public interface PropertyAccessor
{
}
public interface PropertyEditorRegistry
{
}
public interface ConfigurablePropertyAccessor extends PropertyAccessor,PropertyEditorRegistry
{
}
public interface BeanWrapper extends ConfigurablePropertyAccessor
{
}

public class PropertyEditorRegistrySupport  implements PropertyEditorRegistry
{
}
public abstract class AbstractPropertyAccessor extends PropertyEditorRegistrySupport implements ConfigurablePropertyAccessor
{
}
public class BeanWrapperImpl extends AbstractPropertyAccessor implements BeanWrapper  
{
}
/*
上面整个类结构的设计先忽略掉，仅关注接口PropertyAccessor,抽象类AbstractPropertyAccessor,具体类BeanWrapperImpl
下面是接口PropertyAccessor定义的完整方法
*/
public interface PropertyAccessor
{
	boolean isReadableProperty(String propertyName) throws BeansException;
	boolean isWritableProperty(String propertyName) throws BeansException;
	Class getPropertyType(String propertyName) throws BeansException;
	Object getPropertyValue(String propertyName) throws BeansException;
	void setPropertyValue(String propertyName, Object value) throws BeansException;
	void setPropertyValue(PropertyValue pv) throws BeansException;
	void setPropertyValues(Map map) throws BeansException;
	void setPropertyValues(PropertyValues pvs) throws BeansException;
	void setPropertyValues(PropertyValues pvs, boolean ignoreUnknown)
	    throws BeansException;
}
/*
仔细研究这个接口中的方法,可以发现两个setPropertyValue重载方法及三个setPropertyValues重载方法,
在这五个方法中除了setPropertyValue(String,Object)之外其余四个方法都可以建立在此方法基础上进行实现.
这也正是抽象类AbstractPropertyAccessor做的工作之一.
基础方法setPropertyValue(String,Object)留在具体类BeanWrapperImpl中进行实现.
*/

 

其实这样写并不是概念性的东西，而是有实际效果的。
在反射的时候，这样写可能就是不同的结果了。
比如在调用Class#getInterfaces()时，如果有接口A，实现类B实现接口A，类C继承B但是没显示implements A，有类D继承B并且implements A。
这个时候如果对C用getInterfaces()，是个空数组，对C用getInterfaces()就能得到A

在代码表现上，可以清晰的看到C类实现了A接口，而不需要通过基类B知道

按照Java Collection Framework的设计,如

    interface Map<K, V>{}

    abstract AbstractMap<K, V> implements Map<K,V>{}

    class HashMap<K,V>
    extends AbstractMap<K,V>
    implements Map<K,V>{}

AbstractMap充当骨架,实现某些共用的功能,Map接口充当标识,在这里抽象类AbstractMap在设计上应该不是一个纯粹的父类,HashMap is-a AbstractMap?这感觉不太妥.HashMap再implements Map接口,应该只是为了强化HashMap拥有Map这个标识,而不是让人觉得HashMap只是AbstractMap的一个子实现类.让人更容易将HashMap, LinkedHashMap, TreeMap之类拥有Map标识的类关联起来.这应该只是一种设计意图,在语法上其实是不必要的.
个人推断