创建命名空间 ->类->嵌套类？或者

Question

我正在阅读有关创建类和嵌套类的内容，以确定什么是满足我的需求的最佳方法，但我找不到与我需要的类似的东西（或者无法理解它；））。

我会给你们一个（几乎）现实生活中的例子：

假设我拥有一家生产不同类型车辆的工厂。所以，我认为我的命名空间是 Factory 。

现在，假设这家工厂生产汽车、轮船和飞机。因此，我将使用这些名称将三个类添加到我的 Factory 命名空间中。

这是我理解其他方法的问题：

我在这三种类型的车辆之间有一些共同点。例如，他们都有一个发动机（可能是不同的马力或形状，我理解是发动机的属性，但他们仍然都有一个发动机）。此外，汽车和飞机都有门（有时船也有）。另一方面，它们也有一些独特的东西（例如，飞机有螺旋桨，可能有不同的尺寸或形状）。

有人可以描述一下我在代码中所说的内容，以便我可以理解它们之间的差异吗？

Answer 1

你的问题有点模糊。我不会尝试回答这个问题，而是回答两个相关的问题。

命名空间的用途是什么？

命名空间的主要目的是将类型声明组织成层次结构，以便用户可以轻松找到它们。

命名空间的第二个目的是提供一种消除名称冲突歧义的机制。也就是说，如果 XYZ Corp 有一个 Vehicle 类型，ABC Inc 有一个 Vehicle 类型，并且 PQR Ltd 希望同时使用 XYZ 和 ABC 的代码，则 PQR 程序员需要一种方法来告诉编译器实际上是哪种类型“Vehicle”指。

您建议将命名空间命名为“Factory”。这可能是个坏主意。工厂可能是一个类，而不是一个命名空间。工厂是一种事物，而不是一种组织事物的方式。我倾向于将我的命名空间命名为“Dementic.Manufacturing”并让它包含一个 Factory 类。现在，事情以两种方式组织：首先，由生产代码的公司 Dementic Incorporated 组织，以及由代码所涉及的内容（即制造）组织。而且您的任何竞争对手不太可能也会创建一个名为 Dementic.Manufacturing 的命名空间。

什么时候应该创建嵌套类型而不是顶级类型？

当嵌套类型是外部类型的实现细节时，创建嵌套类型。尽管偶尔会这样做，但通常认为创建公共嵌套类型是一种不好的做法。

一个常见的例子是枚举器类；它通常是可枚举集合的私有实现细节。

Answer 2

您可以将所有这些粘贴到您的 Factory 命名空间中。

车辆类将包含共享组件，并且您的特定车辆类型的类将从车辆类继承......这就是您要问的吗？

public class Engine
{
   public int HorsePower {get;set;}
}

public class Vehicle
{
    public Vehicle() { }

    public Engine Engine;
    public int Doors;
}

public class Airplane : Vehicle
{
    public Airplane () { }

    public string PropellerModel;
}

public class Boat : Vehicle
{
    public Boat () { }

    public string RudderModel;
}

Answer 3

如果您想尽可能通用，可以这样处理：

namespace Factory
{
    public interface IDoor { }
    public interface IEngine { }
    public interface IPropeller { }

    public abstract class Vehicle
    {
        public ICollection<IDoor> Doors { get; protected set; }
        public ICollection<IEngine> Engines { get; protected set; }
    }

    public class Airplane : Vehicle
    {
        public ICollection<IPropeller> Propellers { get; protected set; }
    }
}

然后让特定的具体类型为超类型属性提供相关集合。

这有点像黑客，但是用编程语言将任何现实世界的对象建模为类迟早会失败。

请注意，我也将引擎属性设置为一个集合。例如，这是为了支持 Prius 类，该类将有两个引擎。

另一种方法是根据接口定义车辆，有点像这样：

namespace Factory
{
    public interface IDoor { }
    public interface IEngine { }
    public interface IPropeller { }

    public interface IDoorProvider
    {
        ICollection<IDoor> Doors { get; }
    }

    public interface IEngineProvider
    {
        ICollection<IEngine> Engines { get; }
    }

    public interface IPropellerProvider
    {
        ICollection<IPropeller> Propellers { get; }
    }

    public abstract class Vehicle { }

    public class Car : Vehicle, IDoorProvider, IEngineProvider
    {
        public ICollection<IDoor> Doors { get; protected set; }
        public ICollection<IEngine> Engines { get; protected set; }
    }

    // And so on...
}

这种方法的优点是您不必在 Vehicle 本身上定义太多，但这也意味着您可以不容易在所有类中共享这些成员的定义。但是，这会阻止您在基类型上定义与具体类型不相关的成员。

Answer 4

您对名称空间的概念有误。命名空间与此无关。

我认为您还混淆了继承和工厂。同样，这些是非常不同的想法。

首先考虑使用提供对象基本结构的公共基类创建类层次结构，然后使用提供特定细节的专用子类。并且要小心不要使用继承，除非它确实有效。如果没有意义，请不要强迫您的模型采用继承层次结构。

然后您可以担心创建一个或多个工厂来创建这些对象的实例。

至于命名空间，命名空间只是一种以逻辑、有意义的方式将相关代码片段组合在一起的方法。您可能有一个工厂名称空间，但您也可以有一个“工厂”名称空间或“车辆”名称空间或与您的域相关的完全不同的名称空间。

Answer 5

由于提出问题的人实际上可能会从中获得一些价值，因此我的看法是：

如果您的软件以某种方式处理现实世界的对象，请不要尝试对代表应用程序核心的类集进行建模根据现实世界。相反，让软件的要求来指导您的对象的外观。

例如，这是一个订单管理系统吗？
在这种情况下，某些可订购商品具有与其直接关联的其他可订购商品可能更相关。对于一艘船，您可以订购某些零件、发动机等。也就是说，表达可订购项目之间的关系可能比将它们作为具体类型提供更重要。

例如，它是绘制新船、飞机、螺旋桨等的工具吗？然后一个更相关的基类可能是形状的基类。更多的是计算发动机的功率还是螺旋桨的效率？然后，您可能需要一些数学体的概念，并且需要定义不同对象之间的其他物理关系和特征。

最后，根据经验，您可以将继承视为一个有点被高估的概念，因为它是初学者在接触 OO 时首先想到的事情。自然界中重用的主要概念是组合——最终所有自然事物都是由具有非常清晰的接口的小项目组成的。理想情况下，您将尝试以类似的方式编写面向对象应用程序。

Answer 6

我宁愿选择 VehicleFactory 命名空间，将 Factory 作为一个类（有许多设计模式解决创建对象的问题，通常这需要是一个类，或者至少（通常在非客观编程中）函数。命名空间不会为您提供这个。