oops概念提供封装，继承，覆盖和重载之间的最大代码可重用性 [英] which oops concept offer maximum Code Reusability among Encapsulation, Inheritence, Overriding and Overloading

问题描述

你好，



任何人都可以告诉我哪个oops概念提供了最大的代码可重用性，因为我不确定Encapsulation，Inheritence，Overriding和Overloading ... ...？







先谢谢，

Gobind

解决方案

代码重用是OOP的一般目标，并且（理论上）OOP的所有三个支柱，即封装，继承和多态支持它。实际上代码重用几乎是一个神话：为了可重用，一个软件必须解决一个相当普遍的问题，并且要非常小心地编码（例如，通过设计模式来满足要求）。

< blockquote>除了解决方案1之外，我的答案主要在于我对该解决方案的评论。



我想重申一下：问题在于以下意义：它显然假设可以在一个或另一个组合中选择OOP概念，以获得最佳结果。实际情况并非如此。例如，您可以在泛型（非OOP概念，也可用于某些非OOP语言，例如Ada的第一版）和OOP的组合上构建一些设计。然后你真的有选择。



在OOP中只有一个选择：是否使用OOP（同样，不提及接口，多重继承以及委托，这真的给出了选择;让我们假设你有没有这些功能的OOP，只是为了讨论的缘故）。不使用纯OOP语言的OOP可能意味着不同的方法，但是当正式使用类而不以任何方式利用OOP功能时是可能的。怎么样？一个人只能使用静态方法，而不是虚拟方法，甚至不能使用实例非虚方法（在某些语言中，静态方法可以是抽象/虚拟方法，非常自然）。这将是100％相当于拥有旧的结构化语言而没有OOP的一瞥。即使使用继承，实例方法，它也不会使用OOP技术。最后，一些特别愚蠢的开发者甚至使用关键词虚拟，但并没有真正利用虚拟性。这些程序在逻辑上可以等同于删除了虚拟字样的相同程序。我真的看到了这样的事情。 :-（



当真正使用和利用后期绑定时，该技术使用OOP。也可以考虑使用带有或不带抽象/虚拟/覆盖的接口的替代方法OOP。但其他概念不是选择的主题。如果真正利用OOP权力，所有其他概念不是可选的，它们需要支持中心概念。没有任何后期绑定和/或多态，没有，比方说，封装和继承 - 否则就没有什么可以绑定了。



（顺便说一句，实际上可以利用OOP权力的人并不多了解可能性基于接口而不是基类的多态性。坦率地说，我后来得到的很多。）



这些考虑或许说明了OOP教学法的弱点。传统方法倾向于将所提到的概念视为平等，这对那些没有掌握主要思想的人产生了一些幻想。我可以观察到rve，这样的人甚至设法毕业并开始工作，不知道OOP如何工作，但能够告诉我们关于这些概念的正确的话语。这太可悲了。







我忘了解决一件事。 Overriding实际上是一个OOP概念。所谓的重载不是。第二个概念本身不应该有一个单独的名称。这是一个最糟糕和令人困惑的术语之一，误导了整个行业的太多人。



术语非常混乱：它几乎不能被称为超载 ，因为什么都没有加载。它仅仅意味着语法允许完全不同的形式上不相关的方法具有相同的名称。很琐碎的事情。编译器可以通过从调用代码推断出的配置文件来区分它们。或不;然后发出编译错误。 OOP不需要具有这个简单的功能。

-SA

hello,

can anyone please tell me which oops concept offer maximum code reusability as I'm not sure among Encapsulation, Inheritence, Overriding and Overloading......?



Thanks in Advance,
Gobind

解决方案

Code reuse is a general target of OOP and (theoretically) all the three pillars of OOP, namely Encapsulation, Inheritance and Polymorphism support it. Practically code reuse is almost a myth: in order to be reusable a piece of software must solve a rather general problem and be very careful coded (requiremts fulfilled, for instance, by a design pattern).

My answer, in addition to Solution 1, is mainly in my comment to that solution.

I would like to reiterate: the question is not really adequate in the following sense: it apparently assumes that OOP concepts can be chosen in one or another combination, for best results. This is not really the case. For example, you can build some design on the combination of generics (non-OOP concept also available in some non-OOP languages, such as first version of Ada) and OOP. Then you really have choice.

Inside OOP there is only one choice: to use OOP or not (again, not mentioning interfaces, multiple inheritance and also delegates, which really gives the choice; let's assume you have OOP without those feature, just for the sake of discussion). Not using OOP using a pure OOP language may mean different approaches, but is possible when one uses classes formally, not leveraging OOP power in any way. How? One can use only static methods, never virtual ones, not even instance non-virtual methods (in some languages, static methods can be abstract/virtual, quite naturally). That would be 100% equivalent to having old "structured language" without a glimpse of OOP. Even if one uses inheritance, instance methods, it does not make the use of the OOP technology. And finally, some especially silly "developers" even use the keyword "virtual", but not really leverage "virtuality". Such programs could be logically equivalent to the same programs with the words "virtual" removed. I really saw such things. :-(

The technology uses OOP when late binding is really used and leveraged. Alternative approach using interfaces, with or without abstract/virtual/override, can also be considered OOP. But other concepts are not the subject of choice. If OOP power is really leveraged, all other "concepts" are not optional ones, they are needed to support the central ones. There is no any late binding and/or polymorphism without, say, encapsulation and inheritance — otherwise there would be nothing to "bind".

(By the way, not many people who actually can leverage OOP power understand the possibility of polymorphism based on interfaces and not base class. Frankly, I got it much later myself.)

These considerations, perhaps, illustrate the weakness of OOP pedagogic in general. The traditional approach tends to tread the mentioned "concepts" as "equal", which creates some illusions in those who did not grasp the main idea. As I can observe, such people even manage to graduate and start working, having no idea how OOP works, but able to tell us "correct words" about those concepts. This is pretty sad.

[EDIT]

I forgot to address one thing. "Overriding" is really an OOP concept. So called "overloading" is not. The second concept does not deserve a separate name itself. This is one of the worst and confusing term which misleads too many people in whole industry.

The "term" is very confusing: it hardly could be called "overloading", because nothing is "loaded". It merely means that the syntax allows completely different formally unrelated methods to have the same name. Pretty trivial thing. A compiler can distinguish them by profile inferred from the call code. Or not; then the compilation error is issued. OOP is not needed to have this trivial feature.

—SA

这篇关于oops概念提供封装，继承，覆盖和重载之间的最大代码可重用性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！