OOP 设计：抽象 class 设计与常规继承
OOP Design: Abstract class design vs Regular Inheritance
为了好玩，我正在设计一个简单的系统来存储唱片（黑胶唱片）数据和一些其他与唱片相关的一般物品（唱片套、唱片清洁器等）。
由于 90% 的数据将是黑胶唱片，另外 10% 是其他项目，我考虑将它们分成两个 classes：记录和项目。请记住，虽然最后不同，但两者都是具有某些共同点的产品，例如价格、数量等。
我怀疑我是否应该创建一个抽象 class，比如说 Item，以及两个 classes 扩展 Item：Records 和 NonMusicalProducts。像这样：
abstract class Item {
static function getItemPrice($itemId, $type='record'){
$result = 0;
// query record table if type is record, otherwise query nonmusicalproduct table
return $result;
}
abstract function getItemDetails();
}
鉴于记录：
class Record extends Item {
static function getItemDetails($id) {
// query DB and return record details
}
}
和 NMProduct
class NMProduct extends Item {
static function getItemDetails($id) {
// query DB and return NMProduct details
}
}
将NMProduct 和Record 中的方法都定义为静态的可以吗？我并不总是要从 object.
访问该方法
另一种选择是只有一个项目 class 和一个记录 class 将从项目继承，但我已经到了似乎不正确的地步，尤其是在尝试时获取详情：
class Item {
function getItemDetails($id, $type){
if ($type == 'record') {
// query record table using id
}
if ($type == 'nmproduct'){
// query nmproduct table
}
}
感觉不对，因为我认为转到记录 class 获取记录详细信息会更合适，因为这些列与 nmproduct 中的列不同。一次完成 parent class 感觉违背了 OO 的目的。
或者我能想到的最后一个选项是一个 class 项目：
class Item {
function getItemPrice($id, $type) {
// if type is record then query the record table
// if type is nmproduct then query the nmproduct table
}
function getItemDetails($id, $type) {
// if type is record then query the record table
// if type is nmproduct then query the nmproduct table
}
}
同样，最后一个选项感觉不对，因为太多 non-related 东西会被压缩在一个 class 中。记录属性（即 artist_id、number_of_discs 等）不同于 nmproduct.
解决此问题的最佳方法是什么？
还有另一个可能更可取的选择来实现多态性：Composition.
但是在你们提供的选项中，我更喜欢第一个。但是让你的 base classes 尽可能通用（因为它是你的 base class 并且你不想缩小使用范围，因为你的 base classes 太具体了）：
第一个例子：
abstract class Item
{
int Id;
abstract Decimal GetPrice();
abstract IItemDetail GetDetail();
}
由于在您的第一个示例中从数据库中获取数据是特定于类型的，因此最好将特定于类型的操作移动到类型本身（因此每个派生类型都必须实现其特定行为。这消除了类型检查）。正因为如此，在基 class 中将这些方法设为静态并没有多大意义（与始终基于通用类型获取数据的地方相反）。但这是一个设计决定。
你的第二个例子介绍了前面提到的那些讨厌的类型检查。它们使您的代码难以扩展且难以理解（例如可读性）。这是因为，如前所述，您将特定于类型的操作（不能泛化，例如模板）移动到不具备执行操作所需的所有信息的类型（可以是基本类型）中。此类型对对象一无所知。既不是类型也不是状态。在操作发生之前，此类型需要查询目标以获取所有信息：对象是什么类型？它处于什么状态？这就是为什么我们应用 Tell-Don't-Ask 原则和继承来摆脱这种情况。
第三个例子更像是一个静态助手class。方法可以是静态的（并且在支持泛型或模板化时），因为此辅助类型旨在对任何类型（或公共基类型）进行操作。但同样，如果操作依赖于类型（如在您的示例中），那么这将引入类型切换和状态检查，这距离编写可扩展/可维护代码是一大步。
你提供的第一个选项是最干净的。它允许多态性。而且它不违反 Demeter 法则 或 Open-Close。添加新类型，例如 "Movie"，是通过实现新的 "Item" 来完成的，这对于可扩展性非常重要。
但是有更多的可能性来实现你想要做的事情。我之前说过Composition。但是封装呢？我们可以使用 Encapsulation 来提取变化的部分。我们可以有一个 "Item" 类型，它用于所有类型的项目并将类型特定的行为（我们的子类型实现唯一不同的行为，例如您示例中的数据库访问）提取到一个新类型中：
class Item
{
// ctor
Item(IItemPlayer typeSpecificPlayer)
{
this.TypeSpecificPlayer = typeSpecificPlayer;
}
public void Play()
{
this.TypeSpecificPlayer.Play(this);
}
public int Id;
private IItemPlayer TypeSpecificPlayer;
}
interface IItemPlayer
{
void Play(Item itemToPlay);
}
class RecordIItemPlayer implements IItemPlayer
{
void Play(Item item) { print("Put the needle to the groove"); }
}
class MovieIItemPlayer implements IItemPlayer
{
void Play(Item item) { print("Play the video"); }
}
构造函数强制为 "Item" 类型的 Composition 注入不同的组件。这个例子使用了 Composition 和 Encapsulation。
你会像这样使用它：
var record = new Item(new RecordPlayer());
var movie = new Item(new MoviePlayer());
recordItem.TypeSpecificPlayer.Play();
movieItem.TypeSpecificPlayer.Play();
如果不使用 Composition，"IItemPlayer" 将成为关联的外部类型：
interface IItemPlayer
{
void Play(Item item);
}
class RecordIItemPlayer implements IItemPlayer
{
void Play(Item item) { print("Put the needle to the groove"); }
}
class MovieIItemPlayer implements IItemPlayer
{
void Play(Item item) { print("Play the video"); }
}
class Item
{
int Id;
Decimal Price;
IItemDetail Details;
}
并像这样使用它：
var record = new Item();
var recordItemPlayer = new RecordItemPlayer();
var movie = new Item();
var movieItemPlayer = new MovieItemPlayer();
recordItemPlayer.Play(record);
movieItemPlayer.Play(movie);
如果需要额外的变化，例如播放特定类型媒体的方法，我们只需添加一个新的 "IItemPlayer" 实现。
我会用不同的 getDetails 和 getPrice 实现创建 2 类：
interface Detailable {
public function getDetails($id);
public function getPrice($id);
}
class Record implements Detailable{
public function getDetails($id) {
// custom Record Details
}
public function getPrice($id) {
// custom Record price
}
}
class NMProduct implements Detailable{
public function getDetails($id) {
// custom NM Product Details
}
public function getPrice($id) {
// custom NMProduct price
}
}
然后将 NMProduct 或 Record 实例传递到构造函数中 Item:
class Item {
protected $_type;
constructor(Detailable $type) {
$this->_type = $type;
}
function getItemPrice($id) {
return $this->_type->getPrice($id);
}
function getItemDetails($id) {
return $this->_type->getDetails($id);
}
}
所以，真正的数据库查询是delegated从Item到具体实现，这对于NMProduct和Record是不同的。
就个人而言，您希望在一天结束时得到一个项目列表，而不考虑类型。所以你肯定希望有一个共同的基础 class - 这将允许你至少以一种基本的方式处理所有对象。
也考虑泛型来解决这个问题，如...
public class Item<T extends IHaveDetails> {
T details;
public Price getPrice() {
return details.getPrice();
}
public Details getDetails() {
return details.getDetails();
}
}
另一种方法是不同类型的组合——使用容器。本质上，您创建项目 class 以便它只有一个数据成员 - 按名称的详细信息映射。
然后您可以使用所需的任何详细信息填充地图。如果详细信息存储在相关的 table 中，每行一个详细信息，那么您可以使用一个简单的 class 存储任何类型的项目，其中包含任意数量的详细信息。考虑...
public class 项目{
private Map details = new HashMap<>();
public Detail getDetail(String name) {
return details.get(name);
}
public void addDetail(Detail detail) {
return details.put(detail.getName(), detail);
}
}
使用上面的 class 看起来像...
Item record = new Record();
record.addDetail(new NumericDetail("price", 10.00));
record.getDetail("price");
祝你好运！
您必须为此查看策略设计模式，因为您的场景完全适合它。
坦率地说，您的问题似乎与 OOP 无关，特别是多态性。
此外，从实体和数据访问设计的角度来看，这似乎也不对。
从多态的角度来看：显然，您应该定义一个带有抽象成员的基class。两个具体的 classes 都应该派生自抽象基础 class 并且应该覆盖抽象成员。没有静态函数。
在你这样做之前，你需要决定这是否有意义。 Record 和 NMProduct 是一回事吗？实际上我会说是的，因为它们都是您可以在商店出售的东西。 Item 是一个好的通用名称吗？也许不吧。不过不管我怎么想，这个问题你还是要最后说了算。
如果它们在概念上不是同一回事，也许甚至继承也没有多大意义。然后将它们分开并复制方法名称。重点是——继承不应该仅仅用于重用。如果 2 个或更多事物（具体 classes）是同一概念事物（基础 class）的不同种类，则应使用继承。
从实体和数据访问的角度来看：实体不应该查询数据库。存储库应查询数据库并提供实体实例。实体应该允许您使用它，而不管它是如何存储、检索、持久化、序列化等的。存储库应封装 "HOW" 部分。
通常，当您继承了持久对象（例如实体，理想情况下是聚合根——但这不在本次讨论的范围之内）时，您也会继承类似的存储库。因此，您将有一个 ItemRepository、RecordRepository 派生自 ItemRepository，以及 NMProductRepository 也派生自 ItemRepository。 RecordRepository 和 NMProductRepository 只会分别检索 Records 和 NMProducts。 ItemRepository 将检索两者，并将 return 所有它们一起作为项目。这是合法且可能的，因为 Record 和 NMProduct 都是 Item。
我希望即使没有代码示例也很清楚。
为了好玩，我正在设计一个简单的系统来存储唱片（黑胶唱片）数据和一些其他与唱片相关的一般物品（唱片套、唱片清洁器等）。
由于 90% 的数据将是黑胶唱片，另外 10% 是其他项目，我考虑将它们分成两个 classes：记录和项目。请记住，虽然最后不同，但两者都是具有某些共同点的产品，例如价格、数量等。
我怀疑我是否应该创建一个抽象 class，比如说 Item，以及两个 classes 扩展 Item：Records 和 NonMusicalProducts。像这样：
abstract class Item {
static function getItemPrice($itemId, $type='record'){
$result = 0;
// query record table if type is record, otherwise query nonmusicalproduct table
return $result;
}
abstract function getItemDetails();
}
鉴于记录：
class Record extends Item {
static function getItemDetails($id) {
// query DB and return record details
}
}
和 NMProduct
class NMProduct extends Item {
static function getItemDetails($id) {
// query DB and return NMProduct details
}
}
将NMProduct 和Record 中的方法都定义为静态的可以吗？我并不总是要从 object.
访问该方法另一种选择是只有一个项目 class 和一个记录 class 将从项目继承，但我已经到了似乎不正确的地步，尤其是在尝试时获取详情：
class Item {
function getItemDetails($id, $type){
if ($type == 'record') {
// query record table using id
}
if ($type == 'nmproduct'){
// query nmproduct table
}
}
感觉不对，因为我认为转到记录 class 获取记录详细信息会更合适，因为这些列与 nmproduct 中的列不同。一次完成 parent class 感觉违背了 OO 的目的。
或者我能想到的最后一个选项是一个 class 项目：
class Item {
function getItemPrice($id, $type) {
// if type is record then query the record table
// if type is nmproduct then query the nmproduct table
}
function getItemDetails($id, $type) {
// if type is record then query the record table
// if type is nmproduct then query the nmproduct table
}
}
同样，最后一个选项感觉不对，因为太多 non-related 东西会被压缩在一个 class 中。记录属性（即 artist_id、number_of_discs 等）不同于 nmproduct.
解决此问题的最佳方法是什么？
还有另一个可能更可取的选择来实现多态性：Composition.
但是在你们提供的选项中，我更喜欢第一个。但是让你的 base classes 尽可能通用（因为它是你的 base class 并且你不想缩小使用范围，因为你的 base classes 太具体了）：
第一个例子：
abstract class Item
{
int Id;
abstract Decimal GetPrice();
abstract IItemDetail GetDetail();
}
由于在您的第一个示例中从数据库中获取数据是特定于类型的，因此最好将特定于类型的操作移动到类型本身（因此每个派生类型都必须实现其特定行为。这消除了类型检查）。正因为如此，在基 class 中将这些方法设为静态并没有多大意义（与始终基于通用类型获取数据的地方相反）。但这是一个设计决定。
你的第二个例子介绍了前面提到的那些讨厌的类型检查。它们使您的代码难以扩展且难以理解（例如可读性）。这是因为，如前所述，您将特定于类型的操作（不能泛化，例如模板）移动到不具备执行操作所需的所有信息的类型（可以是基本类型）中。此类型对对象一无所知。既不是类型也不是状态。在操作发生之前，此类型需要查询目标以获取所有信息：对象是什么类型？它处于什么状态？这就是为什么我们应用 Tell-Don't-Ask 原则和继承来摆脱这种情况。
第三个例子更像是一个静态助手class。方法可以是静态的（并且在支持泛型或模板化时），因为此辅助类型旨在对任何类型（或公共基类型）进行操作。但同样，如果操作依赖于类型（如在您的示例中），那么这将引入类型切换和状态检查，这距离编写可扩展/可维护代码是一大步。
你提供的第一个选项是最干净的。它允许多态性。而且它不违反 Demeter 法则 或 Open-Close。添加新类型，例如 "Movie"，是通过实现新的 "Item" 来完成的，这对于可扩展性非常重要。
但是有更多的可能性来实现你想要做的事情。我之前说过Composition。但是封装呢？我们可以使用 Encapsulation 来提取变化的部分。我们可以有一个 "Item" 类型，它用于所有类型的项目并将类型特定的行为（我们的子类型实现唯一不同的行为，例如您示例中的数据库访问）提取到一个新类型中：
class Item
{
// ctor
Item(IItemPlayer typeSpecificPlayer)
{
this.TypeSpecificPlayer = typeSpecificPlayer;
}
public void Play()
{
this.TypeSpecificPlayer.Play(this);
}
public int Id;
private IItemPlayer TypeSpecificPlayer;
}
interface IItemPlayer
{
void Play(Item itemToPlay);
}
class RecordIItemPlayer implements IItemPlayer
{
void Play(Item item) { print("Put the needle to the groove"); }
}
class MovieIItemPlayer implements IItemPlayer
{
void Play(Item item) { print("Play the video"); }
}
构造函数强制为 "Item" 类型的 Composition 注入不同的组件。这个例子使用了 Composition 和 Encapsulation。 你会像这样使用它：
var record = new Item(new RecordPlayer());
var movie = new Item(new MoviePlayer());
recordItem.TypeSpecificPlayer.Play();
movieItem.TypeSpecificPlayer.Play();
如果不使用 Composition，"IItemPlayer" 将成为关联的外部类型：
interface IItemPlayer
{
void Play(Item item);
}
class RecordIItemPlayer implements IItemPlayer
{
void Play(Item item) { print("Put the needle to the groove"); }
}
class MovieIItemPlayer implements IItemPlayer
{
void Play(Item item) { print("Play the video"); }
}
class Item
{
int Id;
Decimal Price;
IItemDetail Details;
}
并像这样使用它：
var record = new Item();
var recordItemPlayer = new RecordItemPlayer();
var movie = new Item();
var movieItemPlayer = new MovieItemPlayer();
recordItemPlayer.Play(record);
movieItemPlayer.Play(movie);
如果需要额外的变化，例如播放特定类型媒体的方法，我们只需添加一个新的 "IItemPlayer" 实现。
我会用不同的 getDetails 和 getPrice 实现创建 2 类：
interface Detailable {
public function getDetails($id);
public function getPrice($id);
}
class Record implements Detailable{
public function getDetails($id) {
// custom Record Details
}
public function getPrice($id) {
// custom Record price
}
}
class NMProduct implements Detailable{
public function getDetails($id) {
// custom NM Product Details
}
public function getPrice($id) {
// custom NMProduct price
}
}
然后将 NMProduct 或 Record 实例传递到构造函数中 Item:
class Item {
protected $_type;
constructor(Detailable $type) {
$this->_type = $type;
}
function getItemPrice($id) {
return $this->_type->getPrice($id);
}
function getItemDetails($id) {
return $this->_type->getDetails($id);
}
}
所以，真正的数据库查询是delegated从Item到具体实现，这对于NMProduct和Record是不同的。
就个人而言，您希望在一天结束时得到一个项目列表，而不考虑类型。所以你肯定希望有一个共同的基础 class - 这将允许你至少以一种基本的方式处理所有对象。
也考虑泛型来解决这个问题，如...
public class Item<T extends IHaveDetails> {
T details;
public Price getPrice() {
return details.getPrice();
}
public Details getDetails() {
return details.getDetails();
}
}
另一种方法是不同类型的组合——使用容器。本质上，您创建项目 class 以便它只有一个数据成员 - 按名称的详细信息映射。
然后您可以使用所需的任何详细信息填充地图。如果详细信息存储在相关的 table 中，每行一个详细信息，那么您可以使用一个简单的 class 存储任何类型的项目，其中包含任意数量的详细信息。考虑...
public class 项目{ private Map details = new HashMap<>();
public Detail getDetail(String name) {
return details.get(name);
}
public void addDetail(Detail detail) {
return details.put(detail.getName(), detail);
}
}
使用上面的 class 看起来像...
Item record = new Record();
record.addDetail(new NumericDetail("price", 10.00));
record.getDetail("price");
祝你好运！
您必须为此查看策略设计模式，因为您的场景完全适合它。
坦率地说，您的问题似乎与 OOP 无关，特别是多态性。
此外，从实体和数据访问设计的角度来看，这似乎也不对。
从多态的角度来看：显然，您应该定义一个带有抽象成员的基class。两个具体的 classes 都应该派生自抽象基础 class 并且应该覆盖抽象成员。没有静态函数。
在你这样做之前，你需要决定这是否有意义。 Record 和 NMProduct 是一回事吗？实际上我会说是的，因为它们都是您可以在商店出售的东西。 Item 是一个好的通用名称吗？也许不吧。不过不管我怎么想，这个问题你还是要最后说了算。
如果它们在概念上不是同一回事，也许甚至继承也没有多大意义。然后将它们分开并复制方法名称。重点是——继承不应该仅仅用于重用。如果 2 个或更多事物（具体 classes）是同一概念事物（基础 class）的不同种类，则应使用继承。
从实体和数据访问的角度来看：实体不应该查询数据库。存储库应查询数据库并提供实体实例。实体应该允许您使用它，而不管它是如何存储、检索、持久化、序列化等的。存储库应封装 "HOW" 部分。
通常，当您继承了持久对象（例如实体，理想情况下是聚合根——但这不在本次讨论的范围之内）时，您也会继承类似的存储库。因此，您将有一个 ItemRepository、RecordRepository 派生自 ItemRepository，以及 NMProductRepository 也派生自 ItemRepository。 RecordRepository 和 NMProductRepository 只会分别检索 Records 和 NMProducts。 ItemRepository 将检索两者，并将 return 所有它们一起作为项目。这是合法且可能的，因为 Record 和 NMProduct 都是 Item。
我希望即使没有代码示例也很清楚。