创建命名空间 ->类->嵌套类?或者
我正在阅读有关创建类和嵌套类的内容,以确定什么是满足我的需求的最佳方法,但我找不到与我需要的类似的东西(或者无法理解它;))。
我会给你们一个(几乎)现实生活中的例子:
假设我拥有一家生产不同类型车辆的工厂。所以,我认为我的命名空间是 Factory
。
现在,假设这家工厂生产汽车、轮船和飞机。因此,我将使用这些名称将三个类添加到我的 Factory
命名空间中。
这是我理解其他方法的问题:
我在这三种类型的车辆之间有一些共同点。例如,他们都有一个发动机(可能是不同的马力或形状,我理解是发动机的属性,但他们仍然都有一个发动机)。此外,汽车和飞机都有门(有时船也有)。另一方面,它们也有一些独特的东西(例如,飞机有螺旋桨,可能有不同的尺寸或形状)。
有人可以描述一下我在代码中所说的内容,以便我可以理解它们之间的差异吗?
I was reading about creating classes and nested classes to determine what is the best approach for my needs, but I couldn't find something similar to what I need ( or couldn't understand it ;) ).
I will give you guys a (almost) real-life example:
Let's say I own a factory which manufactures different kinds of vehicles. So, my namespace would be Factory
I figure.
Now, lets say the factory manufactures cars, boats and airplanes. So I will add three classes to my Factory
namespace with those names.
Here is where my problem is with understanding the other methods:
I have some common things between the three types of vehicles. For example, they all have an engine (might be different HP or shapes which I understand are properties of the engine, but still they all have an engine). Also, cars and airplanes have doors (sometimes boats do too). On the other hand, they also have some unique things (airplanes have propellers for example that might come in different sizes or shapes).
Can someone please describe what I said in code so I could understand the differences between them?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(6)
你的问题有点模糊。我不会尝试回答这个问题,而是回答两个相关的问题。
命名空间的主要目的是将类型声明组织成层次结构,以便用户可以轻松找到它们。
命名空间的第二个目的是提供一种消除名称冲突歧义的机制。也就是说,如果 XYZ Corp 有一个 Vehicle 类型,ABC Inc 有一个 Vehicle 类型,并且 PQR Ltd 希望同时使用 XYZ 和 ABC 的代码,则 PQR 程序员需要一种方法来告诉编译器实际上是哪种类型“Vehicle”指。
您建议将命名空间命名为“Factory”。这可能是个坏主意。工厂可能是一个类,而不是一个命名空间。工厂是一种事物,而不是一种组织事物的方式。我倾向于将我的命名空间命名为“Dementic.Manufacturing”并让它包含一个 Factory 类。现在,事情以两种方式组织:首先,由生产代码的公司 Dementic Incorporated 组织,以及由代码所涉及的内容(即制造)组织。而且您的任何竞争对手不太可能也会创建一个名为 Dementic.Manufacturing 的命名空间。
当嵌套类型是外部类型的实现细节时,创建嵌套类型。尽管偶尔会这样做,但通常认为创建公共嵌套类型是一种不好的做法。
一个常见的例子是枚举器类;它通常是可枚举集合的私有实现细节。
Your question is a bit vague. Rather than try to answer it, I'll answer two related questions.
The primary purpose of a namespace is to organize type declarations into a hierarchy so that they can be found by users easily.
The secondary purpose of a namespace is to provide a mechanism for disambiguating name collisions. That is, if XYZ Corp has a type Vehicle and ABC Inc has a type Vehicle, and PQR Ltd wants to use code from XYZ and ABC at the same time, the PQR programmers need a way to tell the compiler which type "Vehicle" actually refers to.
You suggest naming your namespace "Factory". That's probably a bad idea. A factory is probably a class, not a namespace. A factory is a kind of thing, not a way of organizing things. I would be inclined to name my namespace "Dementic.Manufacturing" and have it contain a Factory class. Now things are organized in two ways: first, by the company, Dementic Incorporated, that is producing the code, and by what the code is related to, namely, manufacturing. And it is unlikely that any competitor of yours will also make a namespace called Dementic.Manufacturing.
Make a nested type when the nested type is an implementation detail of the outer type. It is generally considered a poor practice to make a public nested type, though it is occasionally done.
A common example is an enumerator class; it is usually a private implementation detail of a enumerable collection.
您可以将所有这些粘贴到您的 Factory 命名空间中。
车辆类将包含共享组件,并且您的特定车辆类型的类将从车辆类继承......这就是您要问的吗?
You could stick all these in your Factory namespace.
A vehicle class would contain shared components, and classes for your specific vehicle types would inherit from the vehicle class... is that what you're asking?
如果您想尽可能通用,可以这样处理:
然后让特定的具体类型为超类型属性提供相关集合。
这有点像黑客,但是用编程语言将任何现实世界的对象建模为类迟早会失败。
请注意,我也将引擎属性设置为一个集合。例如,这是为了支持
Prius
类,该类将有两个引擎。另一种方法是根据接口定义车辆,有点像这样:
这种方法的优点是您不必在
Vehicle
本身上定义太多,但这也意味着您可以不容易在所有类中共享这些成员的定义。但是,这会阻止您在基类型上定义与具体类型不相关的成员。If you want to be as generic as possible, you can approach it something like this:
Then have the specific concrete types provide the relevant collections to the supertype properties.
This is a bit of a hack, but modeling any real-world objects as classes in a programming language is going to break down sooner or later.
Note that I've made the engine property a collection too. This is to support, for example, the
Prius
class, which would have two engines.An alternate approach would be to define the vehicles in terms of interfaces, somewhat like this:
This approach has the advantage that you don't have to define much on
Vehicle
itself, but this also means that you can't easily share the definitions of these members across all of the classes. However, this prevents you from defining members on the base type that are not relevant to the concrete types.您对名称空间的概念有误。命名空间与此无关。
我认为您还混淆了继承和工厂。同样,这些是非常不同的想法。
首先考虑使用提供对象基本结构的公共基类创建类层次结构,然后使用提供特定细节的专用子类。并且要小心不要使用继承,除非它确实有效。如果没有意义,请不要强迫您的模型采用继承层次结构。
然后您可以担心创建一个或多个工厂来创建这些对象的实例。
至于命名空间,命名空间只是一种以逻辑、有意义的方式将相关代码片段组合在一起的方法。您可能有一个工厂名称空间,但您也可以有一个“工厂”名称空间或“车辆”名称空间或与您的域相关的完全不同的名称空间。
You have the wrong concept of what namespaces are. Namespaces have nothing to do with this.
I think you're also confusing inheritance and factories. Again, those are very separate ideas.
First think about creating your class heirarchy with the common base class that provides the basic structure of your objects and then the specialized subclasses that provide the specific details. And be careful not to use inheritance unless it truly works. Don't force your model into an inheritance heirarchy if it doesn't make sense.
Then you can worry about creating one or more factories to create instances of these objects.
As for namespaces, a namespace is just a way to group related pieces of code together in a logical, meaningful way. You might have a factory namespace, but you could just as well have a "factories" namespace or a "vehicles" namespace or something completely different which is relevant to your domain.
由于提出问题的人实际上可能会从中获得一些价值,因此我的看法是:
如果您的软件以某种方式处理现实世界的对象,请不要尝试对代表应用程序核心的类集进行建模根据现实世界。相反,让软件的要求来指导您的对象的外观。
例如,这是一个订单管理系统吗?
在这种情况下,某些可订购商品具有与其直接关联的其他可订购商品可能更相关。对于一艘船,您可以订购某些零件、发动机等。也就是说,表达可订购项目之间的关系可能比将它们作为具体类型提供更重要。
例如,它是绘制新船、飞机、螺旋桨等的工具吗?然后一个更相关的基类可能是形状的基类。更多的是计算发动机的功率还是螺旋桨的效率?然后,您可能需要一些数学体的概念,并且需要定义不同对象之间的其他物理关系和特征。
最后,根据经验,您可以将继承视为一个有点被高估的概念,因为它是初学者在接触 OO 时首先想到的事情。自然界中重用的主要概念是组合——最终所有自然事物都是由具有非常清晰的接口的小项目组成的。理想情况下,您将尝试以类似的方式编写面向对象应用程序。
Since the person asking the question might actually get some value out of it, here my take:
If your software deals in some ways with objects of the real world, don't try to model the set of classes that represent the core of your application according to the real world. Rather, let the requirements of the software guide as to how your objects will look like.
For example, is this an order management system?
In that case it may be more relevant that certain orderable items have other orderable items directly associated with it. For a boat you can order certain parts, engines, etc. That is, it may more important to express the relationships between orderable items instead of having them available as concrete types.
For example, is it a tool to draw new boats, planes, propellers, etc.? Then a more relevant base class maybe that of a shape. Is it more about calculating the power of an engine or the efficiency of a propeller? Then you may need some concept of mathematical bodies and additional physical relationships and characteristics need to be defined between the different objects.
Lastly, as a rule of thumb you can think of inheritance as a somewhat overrated concept in that it is the first thing that starters think of when touching OO. The predominant concept of reuse in nature is composition - ultimately all natural things are composed of small items with very clear interfaces. Ideally, you will try and compose your OO application in a similar fashion.
我宁愿选择 VehicleFactory 命名空间,将 Factory 作为一个类(有许多设计模式解决创建对象的问题,通常这需要是一个类,或者至少(通常在非客观编程中)函数。命名空间不会为您提供这个。
I would rather go for VehicleFactory namespace, Factory as a class (there are many design patterns addresing the problem of creating objects and usually this needs to be a class, or at least (usually in non-objective programming) function. Namespace won't provide you this.