我必须用最少一个抽象类和接口来做图表,我认为在这里实现接口类是个好主意。我的表是customer,它是抽象类。interface类显示了需要包含在这两种类型的customer中的方法。我的问题是,我是如何表示一个与interface类连接的抽象类的。我应该将customer类留空吗?使用抽象类的接口是错误的吗?这是我的图表:
6yjfywim1#
interface 不是一个 class . 以下是oracle教程中的定义:在java编程语言中,接口是一种引用类型,类似于类,它只能包含常量、方法签名、默认方法、静态方法和嵌套类型。方法体只存在于默认方法和静态方法中。接口不能示例化它们只能由类实现或由其他接口扩展。同一页提到,在软件工程中,有许多情况下,不同的程序员组必须同意一个“合同”,该合同详细说明了他们的软件是如何交互的。每个小组都应该能够编写自己的代码,而不知道另一个小组的代码是如何编写的。一般来说,接口就是这样的契约。因此,在 interface ,您应该放置您希望所有实现类都必须具有的方法签名(契约)。你的 abstract class 可以实现其中一些方法,这些实现作为子类(即 extend 这个 abstract class ). 此类可以为其子类继承其他成员。
interface
class
abstract class
extend
2lpgd9682#
既然您的问题似乎是关于uml建模的,我将提供一些额外的、更面向uml的信息:你的 «interface» 定义一个包含三个操作的契约(在java中,操作是方法)。这意味着实现这个接口的所有类都必须提供这三个操作。根据你的叙述,抽象类 Customer 实现接口。这应在带有“实现”依赖关系的图中表示,即从类到接口的带点线,带有一个纯空白箭头(注意:您的图表似乎显示了一个可导航的关联,这将具有完全不同的含义)但是实现不是继承:默认情况下,实现关系不会发生任何事情,您必须显式地为实现添加所有三个操作 Customer . 如果某些操作在这个级别上仍然是抽象的,则应将其标记为抽象的(即斜体)。您可以在的专门化(即继承类)中重新定义这些抽象操作中的任何一个 Customer .也就是说,抽象类只有在添加了一些值(例如为某些方法提供默认实现、添加了一些附加方法或属性)时才有意义。如果它只是一个空框,并且子类无论如何都必须实现所有内容,那么您可以从设计中删除抽象类:任何继承抽象类的类都将实现接口与抽象类关联的任何类都将与接口关联,接口将代表实现它的任何类。
«interface»
Customer
2条答案
按热度按时间6yjfywim1#
interface
不是一个class
. 以下是oracle教程中的定义:在java编程语言中,接口是一种引用类型,类似于类,它只能包含常量、方法签名、默认方法、静态方法和嵌套类型。方法体只存在于默认方法和静态方法中。接口不能示例化它们只能由类实现或由其他接口扩展。
同一页提到,
在软件工程中,有许多情况下,不同的程序员组必须同意一个“合同”,该合同详细说明了他们的软件是如何交互的。每个小组都应该能够编写自己的代码,而不知道另一个小组的代码是如何编写的。一般来说,接口就是这样的契约。
因此,在
interface
,您应该放置您希望所有实现类都必须具有的方法签名(契约)。你的
abstract class
可以实现其中一些方法,这些实现作为子类(即extend
这个abstract class
). 此类可以为其子类继承其他成员。2lpgd9682#
既然您的问题似乎是关于uml建模的,我将提供一些额外的、更面向uml的信息:
你的
«interface»
定义一个包含三个操作的契约(在java中,操作是方法)。这意味着实现这个接口的所有类都必须提供这三个操作。根据你的叙述,抽象类
Customer
实现接口。这应在带有“实现”依赖关系的图中表示,即从类到接口的带点线,带有一个纯空白箭头(注意:您的图表似乎显示了一个可导航的关联,这将具有完全不同的含义)但是实现不是继承:默认情况下,实现关系不会发生任何事情,您必须显式地为实现添加所有三个操作
Customer
. 如果某些操作在这个级别上仍然是抽象的,则应将其标记为抽象的(即斜体)。您可以在的专门化(即继承类)中重新定义这些抽象操作中的任何一个Customer
.也就是说,抽象类只有在添加了一些值(例如为某些方法提供默认实现、添加了一些附加方法或属性)时才有意义。如果它只是一个空框,并且子类无论如何都必须实现所有内容,那么您可以从设计中删除抽象类:
任何继承抽象类的类都将实现接口
与抽象类关联的任何类都将与接口关联,接口将代表实现它的任何类。