blocks|key|1274529|text|在某种程度上，这是一个风格的问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1274530|这是一个常见的实践--但是也有人告诉您，任何方法都不应该有一个以上的实现。这些人声称，继承层次结构中的多个实现导致了很难调试的代码，因为您必须非常小心地确定实际调用该方法的哪个版本。|offset|length|style|BOLD|1274531|当这些方法被其他方法大量使用时，您可以很容易地松开大局--突然之间，预测某些代码所做的事情变得复杂起来--因为在某些子类中有很重的重写功能。|1274532|需要理解的关键是:对于类X中的某些方法foo()，使用“单一”@重写很好，而且很普通。但是在X的子类中再次重写相同的foo()+--这会很快导致各种问题。|CODE|1274533|换句话说，非抽象方法的重新实现应该小心进行。如果这会使您的代码更难理解，那么就寻找其他解决方案。比如:基类有一个固定的(最终)方法来做事情，这个方法调用其他抽象方法来完成它的工作。示例：|1274534|public+abstract+class+Base+{
++public+final+int+doSomething()+{
++++String+tmp+=+foo();
++++int+result+=+bar(tmp);
++++return+result+*+result;
++}
++public+abstract+String+foo();
++public+abstract+int+bar(String+str);|code-block|syntax|javascript|1274535|如前所述:在这里您可以看到implementation是“固定的”，因为doSomething()是最终的-但是所需的“成分”可以(必须)在每个子类中被覆盖。|1274536|entityMap^0|0|4|3|0|0|J|5|1M|5|0|0|0|D|E|10|D|0^^$0|@$1|2|3|4|5|6|7|X|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Y|8|@$D|Z|E|10|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|11|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|12|8|@$D|13|E|14|F|L]|$D|15|E|16|F|L]]|9|@]|A|$]]|$1|M|3|N|5|6|7|17|8|@]|9|@]|A|$]]|$1|O|3|P|5|Q|7|18|8|@]|9|@]|A|$R|S]]|$1|T|3|U|5|6|7|19|8|@$D|1A|E|1B|F|G]|$D|1C|E|1D|F|L]]|9|@]|A|$]]|$1|V|3|-4|5|6|7|1E|8|@]|9|@]|A|$]]]|W|$]]

To a certain degree this is a matter of style.

It is a common practice - but there are also people that tell you that any method should not have more than one implementation. These people claim that multiple implementations within an inheritance hierarchy lead to code that is hard to debug - because you have to be extremely careful to determine which version of such a method is actually called. 

And when such methods are used heavily by other methods you can easily loose the big picture - all of a sudden it becomes complicated to anticipate what some code is doing - because of heavy overriding in some subclasses.

The key thing to understand: a "single" @Override for some method <code>foo()</code> in class X is fine, and common, good practice. But overriding the same <code>foo()</code> again in subclassses of X - that can quickly lead to all kinds of problems.

In other words: re-implementing non-abstract methods should be done carefully. If it makes your code harder to understand then look for other solutions. Like: the base class having a fixed (final) method doing things - and that method calls other abstract methods to do its job. Example:

<pre><code>public abstract class Base {
 public final int doSomething() {
 String tmp = foo();
 int result = bar(tmp);
 return result * result;
 }
 public abstract String foo();
 public abstract int bar(String str);
</code></pre>

As written: here you can see that the implementation is "fixed" because <code>doSomething()</code> is final - but the required "ingredients" can (must) be overridden in each subclass.

blocks|key|1274606|text|在Java中重写非抽象方法是一个很好的实践吗？|type|blockquote|depth|inlineStyleRanges|entityRanges|data|1274607|是。(但是，请确保您没有违反Liskov+Substitution+Principle+(引用现有的帖子)，它告诉子类不应该破坏父类类型的定义。例如，重写于walk+()类的Animal方法应该执行(具有)步行的行为，它不应该执行飞行或其他操作。|unstyled|offset|length|style|CODE|1274608|我还建议通过固体原理来理解设计原则。|1274609|在概念上，b/w覆盖非抽象和抽象的方法会有什么区别。|1274610|AFAIK没有差别。但是，为了明确起见，抽象方法不包含任何实现，而且您的必须重写非抽象方法可以覆盖的位置。|BOLD|1274611|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/56860/what-is-an-example-of-the-liskov-substitution-principle|1|https://dzone.com/articles/the-solid-principles-in-real-life^0|0|E|T|26|7|2F|6|E|T|0|0|6|4|1|0|0|10|H|0^^$0|@$1|2|3|4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|10|8|@$E|11|F|12|G|H]|$E|13|F|14|G|H]|$E|15|F|16|G|H]]|9|@$E|17|F|18|1|19]]|A|$]]|$1|I|3|J|5|D|7|1A|8|@]|9|@$E|1B|F|1C|1|1D]]|A|$]]|$1|K|3|L|5|6|7|1E|8|@]|9|@]|A|$]]|$1|M|3|N|5|D|7|1F|8|@$E|1G|F|1H|G|O]]|9|@]|A|$]]|$1|P|3|-4|5|D|7|1I|8|@]|9|@]|A|$]]]|Q|$R|$5|S|T|U|A|$V|W]]|X|$5|S|T|U|A|$V|Y]]]]

<blockquote>
 Is it a good practice in Java to override a non-abstract method?
</blockquote>

Yes. (But, make sure, you are not violating <a href="https://stackoverflow.com/questions/56860/what-is-an-example-of-the-liskov-substitution-principle"><code>Liskov Substitution Principle</code></a> (referring SO existing post), which tells Child classes should not break the parent class type definitions. For example, <code>walk ()</code> method overriden from <code>Animal</code> class should perform (have behavior of) walking, it shouldn't perform flying or something else.)

I would also recommend to go through <a href="https://dzone.com/articles/the-solid-principles-in-real-life" rel="noreferrer">SOLID Principle</a> for understanding design principle. 

<blockquote>
 and what would be the difference conceptually b/w overriding
 non-abstract vs abstract methods.
</blockquote>

There are no difference AFAIK. But, just to be clear, abstract method doesn't contain any implementation and you MUST override where as non-abstract method can be overriden.

blocks|key|2966|text|重写相关子类中的非抽象方法，其中我希望具有更改逻辑-是的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2967|例如:如果考虑对象类中的toString()和hashCode()，那么这两种方法都是非抽象方法，但通常建议重写子类中的这些方法。|2968|因为如果我想要执行我的逻辑而不是超类逻辑，需要重写并使用它，因此建议在这种情况下重写。|2969|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Override the non-abstract method in the concerned subclass where i want to have alter logic - Yes 

For example : 
If you consider toString() and hashCode() in Object class both methods are non abstract methods but it is mostly recommend to override those methods in our subclasses.

Because if I want to execute my logic instead of super class logic need to override and use it, it is recommended to override in this type of situations.

blocks|key|1274685|text|覆盖非抽象方法是非常好的，并且通常是实践的，只要您不违反Liskov变换原理。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1274686|Liskov的原则对签名提出了一些标准要求|blockquote|1274687|子类型中方法参数的反方差。|unordered-list-item|1274688|子类型中返回类型的协方差。|1274689|子类型的方法不应引发任何新的异常，除非这些异常本身是由父类型的方法引发的异常的子类型。|1274690|除了签名要求之外，子类型还必须满足许多行为条件。|1274691|不能在子类型中加强先决条件。|1274692|后置条件不能在子类型中减弱。|1274693|超级类型的不变量必须保留在子类型中。|1274694|历史约束(“历史规则”)。对象仅通过其方法(封装)被认为是可修改的。因为子类型可能引入不存在于超级类型中的方法，因此这些方法的引入可能允许在超级类型中不允许在子类型中进行状态更改。历史约束禁止此操作。|1274695|只要该方法一旦被凌驾于合同之上，就不应对新的实施方法产生混淆。该方法的新实施仍应遵守与实施前相同的合同，才能被推翻。|1274696|entityMap|0|LINK|mutability|MUTABLE|url|https://en.m.wikipedia.org/wiki/Liskov_substitution_principle#Principle^0|S|A|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|17|8|@]|9|@$A|18|B|19|1|1A]]|C|$]]|$1|D|3|E|5|F|7|1B|8|@]|9|@]|C|$]]|$1|G|3|H|5|I|7|1C|8|@]|9|@]|C|$]]|$1|J|3|K|5|I|7|1D|8|@]|9|@]|C|$]]|$1|L|3|M|5|I|7|1E|8|@]|9|@]|C|$]]|$1|N|3|O|5|6|7|1F|8|@]|9|@]|C|$]]|$1|P|3|Q|5|I|7|1G|8|@]|9|@]|C|$]]|$1|R|3|S|5|I|7|1H|8|@]|9|@]|C|$]]|$1|T|3|U|5|I|7|1I|8|@]|9|@]|C|$]]|$1|V|3|W|5|I|7|1J|8|@]|9|@]|C|$]]|$1|X|3|Y|5|6|7|1K|8|@]|9|@]|C|$]]|$1|Z|3|-4|5|6|7|1L|8|@]|9|@]|C|$]]]|10|$11|$5|12|13|14|C|$15|16]]]]

Overriding a non-abstract method is perfectly fine, and commonly practiced, as long as you don't violate the <a href="https://en.m.wikipedia.org/wiki/Liskov_substitution_principle#Principle" rel="nofollow noreferrer">Liskov Subsitution principle</a>:

<blockquote>
 Liskov's principle imposes some standard requirements on signatures
 
 <ul>
 <li>Contravariance of method arguments in the subtype.</li>
 <li>Covariance of return types in the subtype.</li>
 <li>No new exceptions should be thrown by methods of the subtype, except where those exceptions are themselves subtypes of exceptions thrown by the methods of the supertype.</li>
 </ul>
 
 In addition to the signature requirements, the subtype must meet a number of behavioral conditions.
 
 <ul>
 <li>Preconditions cannot be strengthened in a subtype.</li>
 <li>Postconditions cannot be weakened in a subtype.</li>
 <li>Invariants of the supertype must be preserved in a subtype.</li>
 <li>History constraint (the "history rule"). Objects are regarded as being modifiable only through their methods (encapsulation). Because subtypes may introduce methods that are not present in the supertype, the introduction of these methods may allow state changes in the subtype that are not permissible in the supertype. The history constraint prohibits this.</li>
 </ul>
</blockquote>

As long as the method still abides the contract once overriden, there should be no confusion as to what the new implementation does. The method's new implementation should still abide the same contract as the implementation before it was overriden.

I have a situation where I need to modify the super class method to have a subclass specific logic, but the methods logic is same for all other subclasses. 

I have two options:

1) make the method abstract and for each except my concerned subclass repeat the same code.

2) Override the non-abstract method in the concerned subclass where i want to have alter logic. 

Is it a good practice in Java to override a non-abstract method? and what would be the difference conceptually b/w overriding non-abstract vs abstract methods.

Is it good practice to override non abstract methods?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

在我需要修改超类方法以具有子类特定逻辑的情况下，方法逻辑对于所有其他子类都是相同的。我有两个选择：1)使方法抽象，并对除我的相关子类之外的每个子类重复相同的代码。2)重写相关子类中的非抽象方法，其中我希望有alter逻辑。在Java中重写非抽象方法是一个很好的实践吗？在概念上，b/w覆盖非抽象和抽象的方法会有什么区别。

问覆盖非抽象方法是很好的做法吗？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问覆盖非抽象方法是很好的做法吗？EN