OOPS 中的类和绘制关系答案

【问题标题】：class and paint relationship in OOPSOOPS 中的类和绘制关系
【发布时间】：2012-05-16 16:39:48
【问题描述】：

这可能不是问这个问题的正确地方，因为我在一次采访中被问到这个问题，但我想了解它背后的 oops 概念。

有两个基类和一个派生类：

    class Car {}

    class Paint {}

    class Colors : Paint {}

所以问题是，将 Paint 作为不同的基类并将 Colors 作为 Paint 类的子类背后的面向对象概念是什么。

我的困惑是 Paint 是基类而不是 Car 类的属性。这里应用了 OOP 的概念。

【问题讨论】：

虽然其他人可能不同意，但我相信这里应用的“概念”被称为“糟糕的设计”。
我认为您的意思是“类和父对象关系”。 OOPS =“面向对象编程”。也许您的意思是 OOD =“面向对象的设计”。

标签： oop

【解决方案1】：

概念是有些人没有概念。首先，什么是“颜色”（不要用复数名称命名类）。颜色继承了 Paint 中的哪些行为？据我所知，什么也没有。我不知道 Colors 应该做什么。

颜色可以与画图互换使用吗？不是我能想象的。马上，它似乎是一个糟糕的类层次结构。

恕我直言，这个问题完全是假的。

【讨论】：

我告诉他这里面向对象的概念可能是 Car 类组成 Paint 类。将 Paint 类与 Car 分离也可以是封装，因为单独的制造商或汽车制造商将拥有自己的一组 Paint 类。但我真的不知道这个设计。

【解决方案2】：

出于某种原因，我想它被描述为：

"你有一个Car 类和一个Paint 类，而Paint 类是由Colors 子类化。”

我假设解释它的人并不意味着一个名为 Colors 的类。我想它更像是：

    public class Car
    {
    }

    public abstract class Paint
    {
        public abstract void PaintCar(Car car);
    }

    public class BluePaint : Paint
    {
        public override void PaintCar(Car car)
        {
            // apply blue paint to the car
        }
    }

    public class MatteRedPaint : Paint
    {
        public override void PaintCar(Car car)
        {
            // apply red paint to the car
            // use matte finish
        }
    }

这本身并不理想，但比您的问题所建议的要合理得多。

【讨论】：

【解决方案3】：

听起来他们在寻找关键词：继承

颜色继承自 Paint，对吗？

虽然如果 Paint 继承自 Color 会更有意义。

这可能是希望与您进行 OOP 讨论的开放式问题之一。

如果 Car HAS-A Paint 而不是 Car IS-A Paint，那可能是他们正在寻找策略设计模式：更喜欢组合而不是继承。但是这个例子有点推动它，因为它没有真正的意义。

他们可能一直在寻找的最后一件事是关于为什么您认为多重继承不好的讨论。你确实认为它很糟糕，对吧？ :)

【讨论】：