java什么时候用abstract,关于java：我了解何时使用Abstract类或Interface

我希望验证我对何时/为什么使用抽象或接口的理解。

我的例子与人类有关。人可以是男人也可以是女人。一个人在生活中可以有不同的职业。所以我是这样使用它们的：

我将把这些职业作为接口来声明，因为它将建立一个关于一个人在这个职业中能做什么的契约。例子：

Interface SoftwareEngineer{

code();

}

Interface TruckDriver{

driveTruck();

}

Interface Pilot{

flyPlane();

}

我要宣布男人和女人是抽象的阶级，因为男人和女人都会选择这个人。

Abstract Man{

}

Abstract Woman{

}

号

用于定义一个人的类可以实现专业接口来定义该人可以做什么，并且该人将扩展抽象类来定义他/她是谁。

Class Mark extends Man, Implements SoftwareEngineer{

code(){

}

}

这就是我将如何解释一些关于接口和抽象差异的理解。但我想知道如何回答以下两个问题：

你不能实例化一个抽象类，那么如果你让男人和女人成为抽象的，那么你怎么能实例化这些类。那它怎么能用呢？

为什么你要把男人和女人抽象化，为什么你不能把它们作为一个界面。类将实现它们，而不是扩展它们。

这些是我自己问的问题。我可能在这里找不到什么东西。欣赏这个例子中的见解。

为什么Man是抽象类？Man和Woman应为具体类别。Mark不应该是一个类；相反，Human应该有一个name字段，Man的一个实例应该有一个名称"Mark"。

谢谢。。。我想看看在我的示例中是否可以使用任何抽象类，所以我使用了man。但这似乎不像你解释的那样有意义。在我的示例中，是否有任何抽象类可以用来解释某人？

我觉得你的声明是错误的。让我们以一个现实世界的场景为例，你不能说Man和Woman是未完成的事情，就像Human一样。你可以把Human作为抽象的男女可以延伸。

这个链接可以给你一些建议：stackoverflow.com/questions/16781329/&hellip；

你的意思是人类可以是抽象阶级，男人和女人可以是具体阶级？

谢谢，我的看法是，当你有一个共同的功能在不同的类之间共享时，你应该抽象类。如果抽象类只能有抽象方法，那么将其作为接口是有意义的。

我想引用这个链接中的一个注释：抽象类和接口之间有什么区别？

classes define what something is, interfaces define what something can do

号

记住这个概念，男人和女人定义了人的一切。而职业只是一个人的特征，对性别中立。这就是把它作为接口的原因。

现在回答你的问题：

1。你不能实例化一个抽象类，那么如果你让男人和女人成为抽象的，那么你怎么能实例化这些类。那它怎么能用呢？

山姆说，如果你要创造一个新的人，这些抽象类会很有帮助。山姆会有不同的行为。因此，通过有一个抽象类"man"，您可以向sam添加更多细节，同时保持"man"所需的基本最小细节。事实上，根据抽象类的定义，您可能已经为一些IT(man)函数实现了默认功能，当然，您可以为派生类(sam)重写这些功能。注意，接口不能有任何功能，它们定义的只是结构。我建议你把人类想象成一个抽象的类。

2。为什么你要把男人和女人抽象化，为什么你不能把它们作为一个界面。类将实现它们而不是扩展它们？

仅仅因为一个男人或女人不仅仅是一个特征，而且它将定义派生类中的许多组成部分。其次，由于接口特别关注一个特性，因此语言允许从接口进行多重继承。而一个人不能同时成为男人和女人。

总而言之，只要您的意图主要涵盖派生类的所有方面，就定义一个抽象类。以及各种不同类型可能共享的特性的接口。例如，所有可以读取的对象的IRead接口。现在，阅读不仅适用于男人或女人，它也可以扩展到小工具。

界面是与外界签订的合同，是你最好的一面。在某种程度上，它还允许您在Java中实现多重继承。

抽象类可以提供一组公共的功能，这些功能可以由它的所有子类共享，例如属性、字段等。

现在，让我们回顾一下您在文章中提供的示例。

如果一个男人或女人的实例不需要职业就可以存在，那么男人和女人就不需要成为抽象类。因此，它们可以是具体的类。

你也不想让男人或女人成为一个介面。这将避免类同时实现男人和女人的接口。

通过抽象类，男女类可以提供一组通用的功能。

名为mark的类不适合用于扩展人和实现软件工程师的具体类。可能是ManSoftWareeEngineer是个更好的名字(我知道这是主观的)。但是，Mark是ManSoftWareeEngineer的一个好名字。

这种情况通常属于Startegy设计模式。(建议为抽象子类的男/女提供公共抽象基类)。不要使用任何具体的基类。

在您的示例中，SoftwareEngineer(类的名称不能被标记，因为它可以是该类的对象)永远不能在运行时成为教授。事实上，马克可以成为，对吗？

一次假设一个职业的策略模式(同时对多个职业，我们需要修改模式impl)将使用人类类(m/w)作为上下文，教授/软件工程师作为具体策略。这个问题并没有就此结束，它会因为不同的职业而对不同的收入产生新的挑战，因为它会要求国家改变。但问题可以用策略作为基本模式来解决。