模式在面向对象的方式

我有一个显示的API的概述对象，让我们说，城市：模式在面向对象的方式

/cities 
/city/{id}

的城市端点返回城市的概况（ID，城市名称，城市区域），而城市端点返回相同加上一些（人口，图像，缩略图...）。现在，在客户端模拟这种当我看到不同的选择：

有其中有一个城市的子类，增加了额外的属性的CityOverview类。
有一个City类，它具有CityOverview子类的所有属性，该子类隐藏所有额外属性（例如，在Java中，通过在所有获取者上为其所没有的属性抛出UnsupportedOperationException）。
让上述类没有继承关系。
有一个City类允许所有额外的属性为零。

上述许可和/或任何其他您可以想到的优点和缺点是什么？

来源

2016-01-13 bluehallu

我会选择3 - 有2个班级，不是继承关系。这是决定的原因 -

您需要使用api（例如杰克逊）对序列化的JSON进行反序列化。为此，您需要一个字段映射的POJO。因为，现在你有两个独立的类，你可以将不同的POJO映射到2个不同的API调用。它使代码更清洁。
继承不是一个选项，因为2个原因 - 1）。有一次，您的任何API调用都会为父项或子项带来数据。即根据您所做的API调用，任何一个的字段将始终为空。这是不必要的浪费。 2）。从OOP设计的角度来看，在城市呼叫中返回的数据对象是而不是是城市{id}呼叫中返回的数据的父级。所以，我们不应该在课堂设计中做到这一点。他们一起组成“城市”实体。

来源

2016-01-13 14:06:23

因此，我个人选择了目前的选择1，但这是我正在寻找的那种讨论。关于你的第一点，是的，我相应地发送父母或孩子的课程。这里没有真正的问题。第二点，我不明白。没有字段是空的，因为我只使用第二个端点上的子类。然后从选项3中获得什么？ – bluehallu

我认为我们差不多在同一页面上。唯一不同的是，在第二点我说CityOverview是“不是”城市的父母。就OOPS而言，City和CityOverview共同组成“城市”实体。然后，如果没有父子关系，而是两个类之间的“关联”，而CityOverview拥有城市的一个实例 - 这是第3点 - 但是既然您说City反正有CityOverview早些时候检索到的所有字段，那么我想第3点是不需要的。我将编辑解决方案以使其正确。 –

我认为如果OverviewCity和City之间没有太大的区别你应该只保留BE中的一个City类。

在你的/ cities api中，你可以通过你城市的完整列表。
客户端可以通过城市对象轻松创建城市列表，并在每个城市显示一些城市的细节（OverviewCity）。在后端我不认为有任何需要支持2个类。

来源

2016-01-13 20:22:50 chenop

我很清楚，后端不需要两个类，这是我很感兴趣的客户端。我在城市名单中没有详细信息的原因是为了提高效率，因为此响应可能会很大，否则我不想在客户端上删除额外的属性。 – bluehallu

模式在面向对象的方式

回答

相关问题