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

第三个例子更像是一个静态助手类。方法可以是静态的（当支持泛型或模板化时），因为此帮助程序类型适用于任何类型（或公共基类型）。但同样，如果操作依赖于类型（如在您的示例中），那么这将引入类型切换和状态检查，这与编写可扩展/可维护代码相距很远。

您提供的第一个选项是最干净的。它允许多态性。并且它不违反 Demeter法则或 Open-Close 。添加新类型（例如“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”实现。

Answer 2

我将创建两个具有不同的getDetails和getPrice实现的类：

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

因此，实际的数据库查询是从Item到具体实现的delegated，对于NMProduct和Record来说是不同的。

Answer 3

坦率地说，您的问题似乎与OOP无关，尤其是多态性。

而且，从实体和数据访问设计的角度来看，这似乎也不对。

从多态的观点来看：显然，您应该定义一个包含抽象成员的基类。这两个具体的类都应该从抽象基类派生，并且应该覆盖抽象成员。没有静态功能。

在执行此操作之前，您需要确定这是否完全有意义。 Record和NMProduct都是同一个人吗？我实际上会说是的，因为它们都是您可以在商店中出售的东西。 Item是一个好名字吗？也许不吧。但是不管我怎么想，您都需要对这个问题进行最后的决定。

如果从概念上说它们不是同一件事，那么甚至继承也没有多大意义。然后将它们分开并重复方法名称。重点是-继承不应仅用于重用。如果2个或更多事物（具体类）是同一概念事物（基类）的不同种类，则应使用继承。

从实体和数据访问的角度来看：实体不应查询数据库。存储库应查询数据库并提供实体实例。实体应该允许您使用它，而不管它是如何存储，检索，持久化，序列化等等的。存储库应封装“ HOW”部分。

通常，当您拥有持久对象（例如实体，理想情况下是集合根）的继承-但这不在本讨论的范围之内时，您还将对存储库具有类似的继承。因此，您将有一个ItemRepository派生的RecordRepository，ItemRepository和NMProductRepository派生的ItemRepository。 RecordRepository和NMProductRepository将仅分别检索Records和NMProducts。 ItemRepository将同时检索这两者，并将它们全部作为Item返回。这是合法的并且可能的，因为Record和NMProduct都是Item。

我希望即使没有代码示例，这也很清楚。

Answer 4

个人而言，一天结束时您想要拥有的是项目列表，而与类型无关。因此，您绝对希望有一个通用的基类-这将使您能够至少以一种基本的方式处理所有对象。

也考虑此问题的泛型，如...

contextMenus

另一种方法是使用容器进行不同类型的组合。本质上，您创建项目类是为了使其仅具有一个数据成员-按名称排列的详细信息映射。

然后使用所需的任何详细信息填充地图。如果详细信息存储在相关表中（每行一个详细信息），则可以使用一个简单类存储任何类型的项目，其中包含任意数量的详细信息。考虑...

公共类项目{ 私人地图详细信息=新的HashMap <>（）;

public class Item<T extends IHaveDetails> {
    T details;

    public Price getPrice() {
        return details.getPrice();
    }

    public Details getDetails() {
        return details.getDetails();
    }
}

}

使用上面的类看起来像...

 public Detail getDetail(String name) {
     return details.get(name);
 }

 public void addDetail(Detail detail) {
     return details.put(detail.getName(), detail);
 }

祝你好运！

Answer 5

您必须看到此的策略设计模式，因为您的方案完全适合其中。

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

5 个答案: