OOP设计:抽象类设计与常规继承

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原则和继承来摆脱这个问题.

在第三个例子更像是一个静态辅助类.方法可以是静态的(当支持泛型或模板化时),因为此帮助程序类型适用于任何类型(或公共基类型).但同样,如果操作是类型相关的(如在您的示例中),那么这将引入类型切换和状态检查,这是编写可扩展/可维护代码的一大步.

您提供的第一个选项是最干净的.它允许多态性.并且它不违反得墨忒耳法或开闭法.添加新类型(例如"Movie")是通过实现新的"Item"来完成的,这对于可扩展性非常重要.

但是,有更多的可能性来实现你想要做的事情.之前我说过Composition.但封装怎么样？我们可以使用Encapsulation来提取不同的部分.我们可以有一个"Item"类型,它用于所有类型的项目,并将类型特定的行为(我们的子类型实现的唯一行为,例如您的示例中的DB访问)提取到一个新类型:

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"实现.