blocks|key|1632632|text|在少数情况下，我们不希望允许更改行为。例如，String类，Math。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1632633|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

There are a few cases where we dont want to allow to change the behavior. For instance, String class, Math.

blocks|key|1632672|text|这个问题同样适用于其他平台，比如C#+.NET。有些人(包括我自己)认为类型在默认情况下应该是最终的/密封的，并且需要显式地解封以允许继承。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1632673|通过继承进行扩展需要仔细设计，而不是简单地将类型保留为未密封的。因此，我认为允许继承应该是一个明确的决定。|1632674|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

This question is equally applicable to other platforms such as C# .NET. There are those (myself included) that believe types should be final/sealed by default and need to be explicitly unsealed to allow inheritance.

Extension via inheritance is something that needs careful design and is not as simple as just leaving a type unsealed. Therefore, I think it should be an explicit decision to allow inheritance.

blocks|key|1632684|text|我不同意。如果层次结构不好，面向对象的语言就没有存在的理由。如果您查看Microsoft和Sun的UI小部件库，您肯定会发现继承。根据定义，这些都是“糟糕的代码”吗？不，当然没有。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1632685|继承可以被滥用，但任何语言功能都可以被滥用。诀窍是学会如何恰当地做事情。|1632686|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I disagree. If hierarchies were bad, there'd be no reason for object oriented languages to exist. If you look at UI widget libraries from Microsoft and Sun, you're certain to find inheritance. Is that all "bad code" by definition? No, of course not.

Inheritance can be abused, but so can any language feature. The trick is to learn how to do things appropriately.

blocks|key|1632739|text|我不喜欢继承，因为总是有更好的方法来做同样的事情，但当你在一个巨大的系统中进行维护更改时，有时以最少的更改修复代码的最好方法是对类进行一点扩展。是的，这通常会导致一个糟糕的代码，但会导致一个可以工作的代码，而不需要首先进行几个月的重写。因此，给维修员尽可能多的灵活性是一种很好的方式。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1632740|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I don't like inheritance because there's always a better way to do the same thing but when you're making maintenance changes in a huge system sometimes the best way to fix the code with minimum changes is to extend a class a little. Yes, it's usually leads to a bad code but to a working one and without months of rewriting first. So giving a maintenance man as much flexibility as he can handle is a good way to go.

blocks|key|1418163|text|当然，有时候拥有非最终的具体类是有意义的。然而，我同意肯特的观点--我认为类在缺省情况下应该是final+(在C#中是密封的)，Java方法在缺省情况下应该是final+(就像它们在C#中一样)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1418164|正如Kent所说，继承需要仔细的设计和文档-很容易认为您可以只覆盖单个方法，但不知道在哪些情况下可能会从基类中调用该方法作为其余实现的一部分。|1418165|有关这方面的更多讨论，请参阅"How+do+you+design+a+class+for+inheritance"。|offset|length|1418166|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/453879/how-do-you-design-a-class-for-inheritance^0|0|0|E|17|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@$F|S|G|T|1|U]]|A|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]]]

There are certainly times when it makes sense to have non-final concrete classes. However, I agree with Kent - I believe that classes should be final (sealed in C#) by default, and that Java methods should be final by default (as they are in C#).

As Kent says, inheritance requires careful design and documentation - it's very easy to think you can just override a single method, but not know the situations in which that method may be called from the base class as part of the rest of the implementation.

See <a href="https://stackoverflow.com/questions/453879/how-do-you-design-a-class-for-inheritance">"How do you design a class for inheritance"</a> for more discussion on this.

blocks|key|1418219|text|有一个很好的理由让你的代码不是最终的。许多框架，如hibernate、spring、guice，有时依赖于它们在运行时动态扩展的非最终类。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1418220|例如，hibernate使用代理进行延迟关联获取。特别是当涉及到AOP时，你会希望你的类不是最终的，这样拦截器就可以附加到它上面。另请参阅question+at+SO|offset|length|1418221|entityMap|0|LINK|mutability|MUTABLE|url|http://www.hibernate.org/hib_docs/reference/en/html/persistent-classes.html|1|https://stackoverflow.com/questions/341624/aop-problem-running-spring-unit-tests^0|0|3|9|0|1X|E|1|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@$D|R|E|S|1|T]|$D|U|E|V|1|W]]|A|$]]|$1|F|3|-4|5|6|7|X|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|M]]|N|$5|I|J|K|A|$L|O]]]]

there a good reasons to keep your code non-final. many frameworks such as hibernate, spring, guice depend sometimes on non-final classes that they extends dynamically at runtime. 

for example, <a href="http://www.hibernate.org/hib_docs/reference/en/html/persistent-classes.html" rel="nofollow noreferrer">hibernate</a> uses proxies for lazy association fetching.
especially when it comes to AOP, you will want your classes non-final, so that the interceptors can attach to it.
see also the <a href="https://stackoverflow.com/questions/341624/aop-problem-running-spring-unit-tests">question at SO</a>

blocks|key|1418326|text|这里最好的参考资料是Joshua+Bloch的优秀书籍"Effective+Java“中的第15项，名为"Design+and+document+for+reference+or+else+prohibit+it”。然而，是否应该允许类的扩展的关键不是“它是抽象的”，而是“它的设计是否考虑到了继承”。有时两者之间存在关联，但第二个是重要的。举一个简单的例子，大多数AWT类都被设计为可扩展的，即使是那些非抽象的类。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1418327|Bloch章节的总结是，如果祖先不是被设计为继承的，那么继承类与其父类的交互可能是令人惊讶和不可预测的。因此，类应该有两种类型:+a)设计为可扩展的类，并且有足够的文档来描述如何进行扩展；b)标记为final的类。(a)中的类通常是抽象的，但并不总是。为|1418328|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Your best reference here is Item 15 of Joshua Bloch's excellent book "Effective Java", called "Design and document for inheritance or else prohibit it". However the key to whether extension of a class should be allowed is not "is it abstract" but "was it designed with inheritance in mind". There is sometimes a correlation between the two, but it's the second that is important. To take a simple example most of the AWT classes are designed to be extended, even those that are not abstract.

The summary of Bloch's chapter is that interaction of inherited classes with their parents can be surprising and unpredicatable if the ancestor wasn't designed to be inherited from. Classes should therefore come in two kinds a) classes designed to be extended, and with enough documentation to describe how it should be done b) classes marked final. Classes in (a) will often be abstract, but not always. For

In java, is there ever a case for allowing a non-abstract class to be extended?

It always seems to indicate bad code when there are class hierarchies. Do you agree, and why/ why not?

Why avoid the final keyword?

Java

在java中，有没有允许扩展非抽象类的情况？当存在类层次结构时，它似乎总是指示错误的代码。你同意吗?为什么/为什么不呢？

问为什么要避免使用final关键字呢？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么要避免使用final关键字呢？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么要避免使用final关键字呢？
EN