关于继承的文体问题 [英] Stylistic question about inheritance

问题描述

假设我想定义一个表示表达式的类层次结构，用于在编译器或类似的东西中使用
。


我们可以想象各种各样的表达式，按其顶级

运算符（如果有）分类。因此，表达式可能是主要的（反过来，

可能是变量或常量），一元表达式（即应用一元的

的结果运算符到表达式），二进制表达式等等。


如果我在C ++中解决这样的问题，我会为所有
$ b定义一个基类$ b表达式，然后从

基类派生各种表达式类。但是，我不会期望创建

基类的对象，所以我会把它变成抽象的。


在Python中，我可以想象做同样的事情事情：


类Expr（对象）：

通过


类UnaryExpr（Expr）：

＃...


类BinaryExpr（Expr）：

＃...


等等。但是，虽然我没有选择C ++关于拥有一个

基类 - 如果没有它你就不能使用动态绑定 - 在Python中我确实有

那个选择。也就是说，我根本不需要基类，除非我想要b / b
想要进行所有派生类共有的操作。


当然，无论如何都有理由建立基类。例如，我/ b $ b可能需要它以便类型查询（例如isinstance（foo，Expr））可以工作。我的

问题是：当我现在不需要时，还有其他理由来创建基类吗？

解决方案

Andrew Koenig写道：

[snip]

当然，有理由无论如何都有一个基类。对于
的例子，我可能想要它，以便类型查询，如isinstance（foo，Expr）
工作。我的问题是：当我现在不需要它的时候还有其他理由来创建一个基类吗？

好​​吧，Python似乎在没有能力的情况下相处得很好

isinstance（foo，file_like_object）;最终可能会更好的结果为

吧。所以我会说你一般不应该这样做。当不同的类需要共享功能时，继承是

。

-

CARL BANKS

Andrew Koenig写道：

当然，无论如何都有理由拥有基类。例如，我可能想要它，以便类型查询，如isinstance（foo，Expr）工作。我的问题是：当我现在不需要它时，还有其他原因可以创建一个基类吗？

你通常会尝试避免类型查询，并且如果可能的话，依赖虚拟的

方法。应用程序似乎可以在不同的子类之间共享代码

，例如，

您可能能够定义


def Expr：

def __str __（self）：

返回''％s（％s）''％（self .__ class __.__ name __，

"，" .join（map（str，self.operands（）））


要求你只在子类中实现.operands（）。 />

如果你能预料到这样的常用代码，就可以更容易地立即添加

a基类。如果你想不出具体的

用例，有一个共同的基类没什么意义。


问候，

马丁

" Carl Banks"< in ********** @ aerojockey.com>在留言中写道

news：11 ********** ************@o13g2000cwo.googlegr oups.com ...

好吧，Python似乎相处得很好而没有能力做到
isinstance（foo，file_like_宾语）;
它最终可能会更好。所以我会说你一般不应该这样做。当不同的类需要共享功能时，继承就是
。

这就是问题所在：是否需要共享

功能，或者它们在概念上相关的方式可能导致以后分享功能的价值？

Suppose I want to define a class hierarchy that represents expressions, for
use in a compiler or something similar.

We might imagine various kinds of expressions, classified by their top-level
operator (if any). So, an expression might be a primary (which, in turn,
might be a variable or a constant), a unary expression (i.e. the result of
applying a unary operator to an expression), a binary expression, and so on.

If I were solving such a problem in C++, I would define a base class for all
expressions, then derive the various kinds of expression classes from that
base class. However, I would not anticipate ever creating objects of the
base class, so I would make it abstract.

In Python, I can imagine doing the same thing:

class Expr(object):
pass

class UnaryExpr(Expr):
# ...

class BinaryExpr(Expr):
# ...

and so on. However, although I don''t have a choice in C++ about having a
base class--you can''t use dynamic binding without it--in Python I do have
that choice. That is, I don''t need to have the base class at all unless I
want to have some operations that are common to all derived classes.

Of course, there are reasons to have a base class anyway. For example, I
might want it so that type queries such as isinstance(foo, Expr) work. My
question is: Are there other reasons to create a base class when I don''t
really need it right now?

解决方案

Andrew Koenig wrote:
[snip]

Of course, there are reasons to have a base class anyway. For example, I might want it so that type queries such as isinstance(foo, Expr) work. My question is: Are there other reasons to create a base class when I don''t really need it right now?

Well, Python seems to get along fine without the ability to do
isinstance(foo,file_like_object); probably better off in the end for
it. So I''d say you should generally not do it. Inheritence is for
when different classes need to share functionality.
--
CARL BANKS

Andrew Koenig wrote:

Of course, there are reasons to have a base class anyway. For example, I
might want it so that type queries such as isinstance(foo, Expr) work. My
question is: Are there other reasons to create a base class when I don''t
really need it right now?

You would normally try to avoid type queries, and rely on virtual
methods instead, if possible. It seems likely for the application
that code can be shared across different subclasses, for example,
you might be able to define

def Expr:
def __str__(self):
return ''%s(%s)'' % (self.__class__.__name__,
", ".join(map(str, self.operands()))

requiring you only to implement .operands() in the subclasses.

If you can anticipate such common code, it is easier to add
a base class right away. If you cannot think of a specific
use case, there is little point in having a common base class.

Regards,
Martin

"Carl Banks" <in**********@aerojockey.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...

Well, Python seems to get along fine without the ability to do
isinstance(foo,file_like_object); probably better off in the end for
it. So I''d say you should generally not do it. Inheritence is for
when different classes need to share functionality.

That''s really the question: Is it for when they need to share
functionality, or when they are conceptually related in ways that might lead
to shared functionality later?

这篇关于关于继承的文体问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！