且构网

分享程序员开发的那些事...
且构网 - 分享程序员编程开发的那些事

是OOP&完全避免实现继承可能吗?

更新时间:2023-11-10 10:37:40

简短的回答:是的,这是可能的。但你必须是故意这样做的,而不是偶然的(使用最终的,抽象的和带有继承的设计等)。

Short answer: Yes it is possible. But you have to do it on purpose and no by chance ( using final, abstract and design with inheritance in mind, etc. )

长答案:

好吧,继承实际上不是代码重用,而是用于专业化类,我认为这是一种误解。

Well, inheritance is not actually for "code re-use", it is for class "specialization", I think this is a misinterpretation.

例如,从Vector创建堆栈是一个非常糟糕的主意,因为它们是相似的。或者来自HashTable的属性只是因为它们存储了值。参见[有效]。

For instance is it a very bad idea to create a Stack from a Vector, just because they are alike. Or properties from HashTable just because they store values. See [Effective].

代码重用更像是OO特征的业务视图,这意味着您的对象可以在节点之间轻松分发;并且是可移植的,并且没有以前编程语言生成的问题。事实已证明这一点很严重。我们现在拥有可以轻松分发的库;例如,在java中,jar文件可以在任何项目中使用,从而节省数千小时的开发时间。 OO仍有一些可移植性和类似的问题,这就是现在WebServices如此受欢迎的原因(就像之前的CORBA一样),但那是另一个主题。

The "code reuse" was more a "business view" of the OO characteristics, meaning that you objects were easily distributable among nodes; and were portable and didn't not have the problems of previous programming languages generation. This has been proved half rigth. We now have libraries that can be easily distributed; for instance in java the jar files can be used in any project saving thousands of hours of development. OO still has some problems with portability and things like that, that is the reason now WebServices are so popular ( as before it was CORBA ) but that's another thread.

这是代码重用的一个方面。另一个是有效的,与编程有关的那个。但在这种情况下,不仅仅是保存代码行并创建脆弱的怪物,而是考虑到继承的设计。这是前面提到的书中的第17项; 第17项:继承的设计和文件,或禁止它。参见[有效]

This is one aspect of "code reuse". The other is effectively, the one that has to do with programming. But in this case is not just to "save" lines of code and creating fragile monsters, but designing with inheritance in mind. This is the item 17 in the book previously mentioned; Item 17: Design and document for inheritance or else prohibit it. See [Effective]

当然,你可能有一个Car类和吨子类。是的,你提到的关于Car interface,AbstractCar和CarImplementation的方法是正确的方法。

Of course you may have a Car class and tons of subclasses. And yes, the approach you mention about Car interface, AbstractCar and CarImplementation is a correct way to go.

你定义了汽车应该遵守的合同,并说这些是我在谈论汽车时所期望的方法。具有基本功能的抽象汽车,每辆汽车都离开并记录子类负责处理的方法。在java中,你通过将方法标记为抽象来实现这一点。

You define the "contract" the Car should adhere and say these are the methods I would expect to have when talking about cars. The abstract car that has the base functionality that every car but leaving and documenting the methods the subclasses are responsible to handle. In java you do this by marking the method as abstract.

当你以这种方式进行时,脆弱类(或者至少是设计者)没有问题是有意识的还是威胁的)子类只完成设计者允许的那些部分。

When you proceed this way, there is not a problem with the "fragile" class ( or at least the designer is conscious or the threat ) and the subclasses do complete only those parts the designer allow them.

继承更多的是专门化类,以同样的方式卡车是Car的专用版本,MosterTruck是Truck的专用版本。

Inheritance is more to "specialize" the classes, in the same fashion a Truck is an specialized version of Car, and MosterTruck an specialized version of Truck.

它不会因为它有一个来自汽车而创建一个ComputerMouse亚类酶***(滚轮)就像汽车一样,它会移动,下面有一个***,只是为了节省代码行。它属于不同的域,它将用于其他目的。

It does not make sanse to create a "ComputerMouse" subclase from a Car just because it has a Wheel ( scroll wheel ) like a car, it moves, and has a wheel below just to save lines of code. It belongs to a different domain, and it will be used for other purposes.

防止实现继承的方法是从编程语言开始,你应该在类声明中使用final关键字,这样就禁止了子类。

The way to prevent "implementation" inheritance is in the programming language since the beginning, you should use the final keyword on the class declaration and this way you are prohibiting subclasses.

如果有意的话,子类化并不是邪恶的。如果做得不好,可能会成为一场噩梦。我会说你应该尽可能私密和最终开始,如果需要的话,可以让事情变得更加公开和可扩展。这也在演示文稿如何设计好的API及其重要性中进行了广泛的解释。参见[Good API]

Subclassing is not evil if it's done on purpose. If it's done uncarefully it may become a nightmare. I would say that you should start as private and "final" as possible and if needed make things more public and extend-able. This is also widely explained in the presentation"How to design good API's and why it matters" See [Good API]

继续阅读文章并及时和实践(和很多耐心)这件事情会更加清晰。虽然有时您只需要完成工作并复制/粘贴一些代码:P。这是好的,只要你尝试先做好。

Keep reading articles and with time and practice ( and a lot of patience ) this thing will come clearer. Although sometime you just need to do the work and copy/paste some code :P . This is ok, as long you try to do it well first.

以下是来自Joshua Bloch的参考资料(以前在Sun工作的Java核心工作谷歌)



[有效]
有效的Java。绝对是非初学者应该学习,理解和实践的***的Java书。必须有。

Here are the references both from Joshua Bloch ( formerly working in Sun at the core of java now working for Google )


[Effective] Effective Java. Definitely the best java book a non beginner should learn, understand and practice. A must have.

Effective Java



[Good API]介绍API的设计,可重用性和相关主题。
它有点冗长但值得每分钟。


[Good API]Presentation that talks on API's design, reusability and related topics. It is a little lengthy but it worth every minute.

如何设计一个好的API及其原因它很重要

问候。



更新:看一看在我发给你的视频链接的第42分钟。它讨论了这个主题:


Update: Take a look at minute 42 of the video link I sent you. It talks about this topic:

如果你在公共API中有两个类,并且你想让一个类成为另一个的子类,就像Foo是Bar的子类,问问你自己,Every Foo是吧?...

"When you have two classes in a public API and you think to make one a subclass of another, like Foo is a subclass of Bar, ask your self , is Every Foo a Bar?... "

在谈论TimeTask时,它在前一分钟讨论了代码重用。

And in the minute previous it talks about "code reuse" while talking about TimeTask.