面向对象设计 : Abstract class design vs Regular Inheritance

Question

为了好玩，我正在设计一个简单的系统来存储唱片(黑胶唱片)数据和一些其他与唱片相关的一般元素(唱片套、唱片清洁器等)。

由于 90% 的数据将是黑胶唱片，另外 10% 是其他项目，我考虑将它们分为两类:唱片和项目。请记住，虽然最终不同，但两者都是具有某些共同点的产品，例如价格、数量等。

我怀疑我是否应该创建一个抽象类，比如 Item，以及两个扩展 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 中的两个方法都定义为静态的？我并不总是要从对象访问该方法。

另一种选择是只有一个 Item 类和一个从 item 继承的 Record 类，但我已经到了一个似乎不正确的地步，尤其是在尝试获取详细信息时:

class Item {
   function getItemDetails($id, $type){
        if ($type == 'record') {
            // query record table using id
        }
        if ($type == 'nmproduct'){
            // query nmproduct table
        }
}

感觉不对，因为我认为去记录类获取记录详细信息会更合适，因为这些列与 nmproduct 中的那些列不同。在一个父类中这样做感觉违背了 OO 的目的。

或者我能想到的最后一个选项是一个单一的类项目:

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
     }
}

同样，最后一个选项感觉不对，因为太多不相关的东西会被浓缩在一个类中。记录属性(即 artist_id、number_of_discs 等)与 nmproduct 不同。

解决这个问题的最佳方法是什么？

Answer 1

还有另一种可能更可取的选择来实现多态性:组合。

但是在你们提供的选项中，我更喜欢第一个。但是让你的基类尽可能通用(因为它是你的基类，你不想缩小使用范围，因为你的基类太具体了):

第一个例子:

abstract class Item
{
  int Id;
  abstract Decimal GetPrice();
  abstract IItemDetail GetDetail();
}

由于在您的第一个示例中从数据库中获取数据是特定于类型的，因此最好将特定于类型的操作移动到类型本身(因此每个派生类型都必须实现其特定行为。这消除了类型检查)。正因为如此，在基类中使这些方法成为静态方法没有多大意义(与始终基于通用类型获取数据的情况相反)。但这是一个设计决定。

您的第二个示例 介绍了之前提到的那些讨厌的类型检查。它们使您的代码难以扩展且难以理解(例如可读性)。这是因为，如前所述，您将特定于类型的操作(不能泛化，例如模板)移动到不具备执行操作所需的所有信息的类型(可以是基本类型)中。此类型对对象一无所知。既不是类型也不是状态。在操作发生之前，此类型需要查询目标以获取所有信息:对象是什么类型？它处于什么状态？这就是为什么我们应用 Tell-Don't-Ask 原则和继承来摆脱这种情况。

第三个例子更像是一个静态帮助类。方法可以是静态的(并且在支持泛型或模板化时)，因为此辅助类型旨在对任何类型(或公共(public)基类型)进行操作。但同样，如果操作依赖于类型(如在您的示例中)，那么这将引入类型切换和状态检查，这距离编写可扩展/可维护代码是一大步。

您提供的第一个选项是最干净的。它允许多态性。而且它不违反Demeter 法则 或Open-Close。添加新类型(例如“电影”)是通过实现新的“项目”来完成的，这对于可扩展性非常重要。

但是有更多的可能性来实现你想要做的事情。我之前说过作文。但是封装呢？我们可以使用封装 来提取变化的部分。我们可以有一个单一的“项目”类型，它用于所有类型的项目并将类型特定的行为(我们的子类型实现唯一不同的行为，例如您示例中的数据库访问)提取到一个新类型中:

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 注入(inject)不同的组件。此示例使用了组合 和封装。 你会像这样使用它:

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”实现。