这个问题适合哪种设计/设计模式？

Question

我之前发布了这个问题，但我猜它太啰嗦和无关紧要了。我的问题也像这个问题。第二个链接中的一个帖子说，下面代码的答案是一个设计问题，具体来说是“继承的错误使用”。因此，我想再次向StackOverflow专家确认这个问题，并查看这是否确实是一个“错误的继承”问题 - 更重要的是，如何修复设计。

像发帖人一样，我也对工厂方法以及如何应用它感到困惑。 看起来工厂方法是为多个具体类提供的，这些类具有与抽象基类完全相同的实现，并且没有添加自己的属性。 但是，正如您将在下面看到的，我的具体类建立在抽象基类之上，并添加了额外的属性。

我们构建的基类：

public abstract class FlatScreenTV
{
     public string Size { get; set; }
     public string ScreenType { get; set; }
}

扩展类示例：

public class PhillipsFlatScreenTV : FlatScreenTV
{
     // Specific to Phillips TVs. Controls the backlight intensity of the LCD screen.
     public double BackLightIntensity { get; set; }
}

public class SamsungFlatScreenTV : FlatScreenTV
{
     // Specific to Samsung TVs. Controls the time until the TV automatically turns off.
     public int AutoShutdownTime { get; set; }
}

假设有更多品牌的平板电视需要扩展类。然后，我们将它们全部放入一个通用列表中：

public static void Main()
{
     List<FlatScreenTV> tvList = new List<FlatScreenTV>();

     tvList.Add(new PhillipsFlatScreenTV());
     tvList.Add(new SamsungFlatScreenTV());
     tvList.Add(new SharpFlatScreenTV());
     tvList.Add(new VizioFlatScreenTV());

     FlatScreenTV tv = tvList[9]; // Randomly get one TV out of our huge list
}

问题：

我想访问这个变量所属的“原始”品牌电视的特定属性。我知道品牌是因为如果我调用tv.GetType()，它会返回正确的“原始”类型 - 而不是FlatScreenTV。但我需要能够将tv从FlatScreenTV转换回其原始类型，以便能够访问每个品牌的平板电视的特定属性。

问题＃1：如何动态地进行强制转换，而不是使用临时方法和巨大的if-else链来猜测“原始”类型？

在浏览类似的设计问题后，大多数答案是：你不能。有些人说要看工厂模式，而其他人则说要使用接口修改设计，但我不知道如何使用它们来解决这个问题。

问题＃2：那么，我应该如何设计这些类，以便在上下文中访问原始类型的特定属性？

问题＃3：这真的是不好的继承吗？

- Jason

---

你需要重新考虑你的方法，但是如果不知道在从列表中获取项目后将特定属性的值用于什么目的，很难说该如何处理。 - Evren Kuzucuoglu

Answer 1

您的设计违反了“Liskov替换原则”，换言之，处理FlatScreenTV列表中的项目的代码不应该知道或关心衍生类型是什么。

举个例子，您的代码需要创建一个自定义的遥控器GUI。只需知道每个电视机属性的名称和类型即可自动生成UI。在这种情况下，您可以像这样从基类公开自定义属性：

public abstract class FlatScreenTV
{
    public FlatScreenTV()
    {
        CustomProperties = new Dictionary<string,object>();
    }

    public Dictionary<string,object> CustomProperties { get; private set; }
    public string Size { get; set; }
    public string ScreenType { get; set; }
}

public class PhillipsFlatScreenTV : FlatScreenTV
{
    public PhillipsFlatScreenTV()
    {
        BackLightIntensity = 0;
    }

    // Specific to Phillips TVs. Controls the backlight intensity of the LCD screen.
    public double BackLightIntensity 
    { 
        get { return (double)CustomProperties["BackLightIntensity"]; }
        set { CustomProperties["BackLightIntensity"] = value; }
    }
}

public class SamsungFlatScreenTV : FlatScreenTV
{
    public SamsungFlatScreenTV()
    {
        AutoShutdownTime = 0;
    }

    // Specific to Samsung TVs. Controls the time until the TV automatically turns off.
    public int AutoShutdownTime 
    {
        get { return (int)CustomProperties["AutoShutdownTime"]; }
        set { CustomProperties["AutoShutdownTime"] = value; }
    }
}

如果你确实需要直接使用派生类型，那么你应该考虑转移到基于插件的架构。例如，你可以拥有这样的工厂方法：

IRemoteControlGUI GetRemoteControlGUIFor(FlatScreenTV tv)

它将扫描您的插件并找到知道如何为特定类型的FlatScreenTV构建UI的插件。这意味着，对于每个新添加的FlatScreenTV，您还需要创建一个知道如何制作其遥控器GUI的插件。

- Mark Heath

Answer 2

我可以提供部分答案：

首先，了解Liskov替换原则。

其次，您正在创建从FlatScreenTV继承的对象，但显然没有目的，因为您想通过它们的子类型（SpecificTVType）而不是超类型（FlatScreenTV）来引用它们 - 这是对继承的错误使用。

如果您的代码想访问特定类型的属性，则确实希望将此代码封装在该类型中。否则，每次添加新的电视类型时，处理电视列表的所有代码都需要更新以反映这一点。

因此，您应该在FlatScreenTV上包括一个执行x的方法，并根据需要在TV中进行覆盖。

所以基本上，在上面的Main方法中，您不应该认为我要处理TVTypeX，而是应始终引用基础类型，并让继承和方法覆盖处理实际正在处理的子类型的特定行为。

代码示例：

  public abstract class FlatScreenTV
  {
      public virtual void SetOptimumDisplay()
      {
         //do nothing - base class has no implementation here
      }
  }


  public class PhilipsWD20TV
  {
      public int BackLightIntensity {get;set;}

      public override void SetOptimumDisplay()
      {
          //Do Something that uses BackLightIntensity
      }

  }

- BonyT

---

谢谢，这绝对是一种新的方向和方法。但是唯一让我担心的是，如果我的基类中有数十个属性，而我的覆盖类并不使用其中大部分，那么留下空的覆盖方法是否会非常冗长（尽管我必须这样做）？但我想这是“正确”的做法？ - Jason

嗯 - 没有看到更多的代码很难评论，但我会建议将属性本地化到需要它们的类型中。如果在您的应用程序中设置属性值是有意义的，那么它需要在基础类型中。如果您可以提供一个方法，在不同的TVTypes上设置不同的属性，则只需在基类中实现该方法，并在子类型中实现特定的属性以及特定的重写方法即可。 - BonyT

@harry - 不，他不会这样做 - 这种方法的整个好处就在于此。 - BonyT

你如何建议将不同类型的实例放入单个集合中？ - harryovers

如果由于某些原因不希望向基类添加额外的行为，那么总是可以使用访问者模式。 - driushkin

Answer 3

工厂模式可能是最好的选择

- harryovers

---

正如我在帖子中所说的那样，工厂设计模式的实现似乎只有在一堆具体类完全遵循抽象类的实现并且不添加自己的额外属性时才兼容。而我的类却添加了额外属性。 - Jason

FlatScreenTV tv = tvList[9]; 如果(tv.GetType() == typeof(SamsungFlatScreenTV)) { (tv as SamsungFlatScreenTV).AutoShutdownTime = 100; }。这样做有什么问题吗？ - harryovers

因为我也说过，我不想用一个庞大的 if-else 阶梯“ brute-guessing” 原始类型。必须有更好的设计来自然地返回适当的类型。如果我需要这样做超过一次，我可不会去 if-else 所有 100 种不同的类型，对吧？ - Jason

一个简单的switch语句比一堆if和else更好。 - harryovers

是的，但这些解决方案并不能解决设计问题。在尝试解决设计问题而不仅仅是应用临时补丁的情况下，if-else/switch没有区别。 - Jason

Answer 4

工厂方法是为了多个具有与抽象基类[接口]完全相同实现且不添加自己属性的具体类而设计的。

更实际一些，工厂方法可以为您提供具体类的对象，其中具体类必须具有一些共同的方法和接口，但也具有一些特定的属性。

有时我使用一个方法，每次调用都创建相同的类对象，我需要多次调用它，有时我使用一个方法，创建几个不同的类对象，这可能会令人困惑，也许是另一个问题。

此外，当使用工厂模式时，您进一步评论了关于带有许多选项的switch语句。通常，您为具体类/具体对象提供标识符。这可以是字符串、整数、特殊类型ID或枚举类型。

您可以使用整数/枚举ID，并使用集合查找具体类。

- umlcat

Answer 5

你仍然可以利用工厂模式。在我看来，工厂模式的重点是将构建各种电视的繁重工作集中在一个地方。断言“工厂是为具有与抽象基类完全相同实现的多个具体类而设计”的说法忽略了多态性。

并没有规定说您不能使用工厂模式，因为子类声明了唯一的属性和方法。但是，您越能够利用多态性，工厂模式就越有意义。此外，作为一般准则，在从基类构建时需要更多复杂性时，使用工厂模式会更好，因为您正在“封装变化”-也就是说，由于不同的要求和固有的构建复杂性（这是一个设计分析决策），构建具体类可能会发生变化。而这种变化只存在于单个类-即工厂。

试试这个：在抽象类中定义所有内容，然后对于给定的电视子类，编写具体特定代码，对于那些不适用的代码，则编写一些标准的“我不做那个”代码。

以通用术语考虑电视机的所有功能：开启、关闭等。在基类中编写一个虚拟方法壳，用于处理电视机的所有通用功能 - 顺便说一下，这是模板方法模式的一个简单示例。然后根据需要在具体类中进行重写。

在基类中还有其他可以做的事情，使其更加灵活（这是一个技术术语，意思是“将子类引用为基类，但执行子类的操作”）。

• 定义委托方法（非常强大但未充分利用）
• 使用params[]来动态设置方法参数列表
• 创建属性委托
• 静态方法
• 声明属性和方法为“抽象” - 强制要求子类实现，与“虚拟”相对
• 在子类中隐藏继承的内容（通常使用“new”关键字来表明这是有意的）
• 如果构造参数数量或复杂度很高，请创建一个专门设计用于向工厂的构建方法传递配置的类。

    public class TVFactory {

    public TV BuildTV(Brands thisKind) {
        TV newSet;

        switch (thisKind) {
            case Brands.Samsung :
                Samsung aSamsungTV = new Samsung();
                aSamsungTV.BacklightIntensity = double.MinVal;
                aSamsungTV.AutoShutdownTime = 45;    //oops! I made a magic number. My bad
                aSamsungTV.SetAutoShutDownTime = new delegate (newSet.SetASDT);
                newSet = aSamsungTV;

                break;
            . . .
        } // switch
    }

    //more build methods for setting specific parameters
    public TV BuildTV (Brands thisKind, string Size) { ... }

    // maybe you can pass in a set of properties to exactly control the construction.
    // returning a concrete class reference violates the spirit of object oriented programming 
    public Sony BuildSonyTV (...) {}

    public TV BuildTV (Brands thisKind, Dictionary buildParameters) { ... }
}

public class TV {
    public string Size { get; set; }
    public string ScreenType { get; set; }
    public double BackLightIntensity { get; set; }
    public int AutoShutdownTime { get; set; }

    //define delegates to get/set properties
    public delegate  int GetAutoShutDownTime ();
    public delegate void SetAutoShutDownTime (object obj);

    public virtual TurnOn ();
    public virtural TurnOff();

    // this method implemented by more than one concrete class, so I use that
    // as an excuse to declare it in my base.
    public virtual SomeSonyPhillipsOnlything () { throw new NotImplementedException("I don't do SonyPhillips stuff"); }

}

public class Samsung : TV {
    public Samsung() {
        // set the properties, delegates, etc. in the factory
        // that way if we ever get new properties we don't open umpteen TV concrete classes
        // to add it. We're only altering the TVFactory.
        // This demonstrates how a factory isolates code changes for object construction.
    }

    public override void TurnOn() { // do stuff }
    public override void TurnOn() { // do stuff }

    public void SamsungUniqueThing () { // do samsung unique stuff }

    internal void  SetASDT (int i) {
        AutoShutDownTime = i;
    }
}

// I like enumerations. 
//   No worries about string gotchas
//   we get intellense in Visual Studio
//   has a documentation-y quality
enum Brands {
    Sony
    ,Samsung
    ,Phillips
}

- radarbob