多重继承?

发布于 2025-01-06 11:19:09 字数 1267 浏览 0 评论 0原文

我在网上查找了可以帮助我解决令我困惑的设计问题的信息。我对复杂的继承情况很陌生,所以我的解决方案实际上可以植根于更好的设计。但在试图弄清楚我的设计应该是什么时,我一直认为我真的只需要继承 1 个以上的基类。

我的具体案例涉及资产和不同类型的资产。

资产开始...

每个物理设备都是一个资产
每个虚拟设备都是一个资产
每个服务器都是一个资产

每个物理服务器都需要既是物理设备又是服务器
每个VirtualServer都需要既是VirtualDevice又是服务器
每个 NetDevice 都是一个 PhysicalDevice
每个StorageArray都是一个PhysicalDevice

我猜的一个解决方案是为两个PhysicalServers复制Server代码,和VirtualServers但是,我觉得这违背了我想要做的事情,即继承。

它们需要是单独的类,因为每种类型都有属性和方法。例如,Server 将具有 OSCaption、内存、Procs 等。PhysicalDevice 将具有位置、串行、供应商等内容。VirtualDevice 将具有有一个 ParentDevice、State、VHDLocation 等。

如果继承是线性的,那么我会遇到无法准确描述这些类型的问题。

接口似乎很有趣。看来我可以将所有基类定义为接口,并根据需要在我的主类中实现它们。但是,我只是不确定如果我这样做会产生什么影响。

例如,类似... PhysicalServer : IAsset : IServer : IPhysical

我在深水中,所以我我真的只是在寻找建议或指导。

I have looked on line for information that would help me solve a design issue that is confusing me. I am new to complicated inheritance situations so my solution could actually just be rooted in a better design. But in trying to figure out what my design should be, I keep ending up thinking I really just need to inherit more than 1 base class.

My specific case involves Assets and different types of Assets.

Starting with the Asset...

Every PhysicalDevice is an Asset
Every VirtualDevice is an Asset
Every Server is an Asset

Every PhysicalServer would need to be both a PhysicalDevice and a Server
Every VirtualServer would need to be both a VirtualDevice and a Server
Every NetDevice is a PhysicalDevice
Every StorageArray is a PhysicalDevice

One solution I guess is to duplicate the Server code for both PhysicalServers, and VirtualServers however, I feel like this goes against what im trying to do, which is inherit.

They need to be separate classes because each of the types will have properties and methods. For instance, Server will have OSCaption, Memory, Procs, etc. PhysicalDevice will have things like Location, Serial, Vendor etc. And VirtualDevice will have a ParentDevice, State, VHDLocation etc.

If the inheritance is liner then i run into the problem of not being able to describe these types accurately.

Something that seems intriguing is Interfaces. It seems that i can define all base classes as interfaces and implement them in my main classes as needed. but, I am simply unsure of what the implications are if I were to do that.

for instance, something like... PhysicalServer : IAsset : IServer : IPhysical

I am in deep water so I’m really just looking for suggestions or guidance.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

捎一片雪花 2025-01-13 11:19:09

接口是确保跨类型契约完整性的适当方法,但最终可能会为每个实现提供重复的代码。

您的场景可能比继承(或其组合)更适合组合。

示例 - 继承 + 组合

public class PhysicalServer : Asset
{
    public PhysicalInfo PhysicalProperties
    {
         get;
         set;
    }
}

public class VirtualServer : Asset
{
    public VirtualInfo VirtualProperties
    {
         get;
         set;
    }
}

示例 - 仅组合

public class VirtualServer
{
    public VirtualInfo VirtualProperties
    {
         get;
         set;
    }

    public AssetInfo AssetProperties
    {
         get;
         set;
    }
}

然后,您可以将多态性/泛型添加到组合中,并创建类型的派生来表示更具体的需求。

示例 - 继承 + 组合 + 从通用类型继承的泛型成员

public class VirtualServer<TVirtualInfo> : Asset
   where TVirtualInfo : VirtualDeviceInfo
{
    public TVirtualInfo VirtualProperties
    {
         get;
         set;
    }
}

public class VirtualServerInfo : VirtualDeviceInfo
{
   // properties which are specific to virtual servers, not just devices
}

您可以通过无数种方法对此进行建模,但是借助接口、组合、继承和泛型,您可以想出一个有效的方法数据模型。

Interfaces are an appropriate way of ensuring contract integrity across types, but you may end up with duplicate code for each implementation.

Your scenario may lend itself better to composition than inheritance (or a combination thereof).

Example - Inheritance + Composition

public class PhysicalServer : Asset
{
    public PhysicalInfo PhysicalProperties
    {
         get;
         set;
    }
}

public class VirtualServer : Asset
{
    public VirtualInfo VirtualProperties
    {
         get;
         set;
    }
}

Example - Composition Only

public class VirtualServer
{
    public VirtualInfo VirtualProperties
    {
         get;
         set;
    }

    public AssetInfo AssetProperties
    {
         get;
         set;
    }
}

You could then add polymorphism/generics into the mix and create derivatives of types to represent more specific needs.

Example - Inheritance + Composition + Genericized Member that inherits from a common type

public class VirtualServer<TVirtualInfo> : Asset
   where TVirtualInfo : VirtualDeviceInfo
{
    public TVirtualInfo VirtualProperties
    {
         get;
         set;
    }
}

public class VirtualServerInfo : VirtualDeviceInfo
{
   // properties which are specific to virtual servers, not just devices
}

There are countless ways that you could model this out, but armed with interfaces, composition, inheritance, and generics you can come up with an effective data model.

戏舞 2025-01-13 11:19:09

使用混入。

您首先决定您希望对象的主要内容是什么。在你的情况下,我认为它应该是服务器。

public class PhysicalServer : Server

然后添加其他功能的接口。

public class PhysicalServer : Server,IAsset,IVirtualDevice

并且您可以向接口添加扩展方法。

public static int WordCount(this IAsset asset)
{
  //do something on the asset
}

这是一篇关于 mixins 的文章,以防我的答案太简单: http://www.zorched.net/2008/01/03/implementing-mixins-with-c-extension-methods/

Use mixins.

You first decide which is the primary thing you want your object to be. In your case I think it should be server.

public class PhysicalServer : Server

Then you add interfaces for the other functionalities.

public class PhysicalServer : Server,IAsset,IVirtualDevice

And you add extension methods to the interfaces.

public static int WordCount(this IAsset asset)
{
  //do something on the asset
}

Here's an article on mixins in case my answer is too simple: http://www.zorched.net/2008/01/03/implementing-mixins-with-c-extension-methods/

倾城月光淡如水﹏ 2025-01-13 11:19:09

C# 不支持类的多重继承(但支持接口的多个实现)。

您要求的不是多重继承。多重继承是指单个类具有多个基类。在您的示例中,每个类都继承自一个/零个其他类。 AssetServer 是最终的基类。因此,在 C# 中执行此操作没有问题,您只需定义 server 中常见的功能,然后在 VirtualDevicePhysicalDevice 中执行不同的操作。

然而,您最终可能会得到一个可能复杂的类层次结构,并且许多人会提倡组合而不是继承。在这里,您可以使用定义行为的接口和实现该接口的类来表示它们执行某些操作,但每个类可以以不同的方式实现接口方法。因此,您的PhysicalServer接口示例可能会受到鼓励。

C# doesn't support multiple inheritance from classes (but does support multiple implementations of interfaces).

What you're asking for is not multiple inheritance. Multiple inheritance is where a single class has more than one base class. In your example each class inherits from one/zero other classes. Asset and Server being the ultimate base classes. So you have no problem doing that in c#, you can just define the functionality common in eg server and then do different things in VirtualDevice and PhysicalDevice.

However you will end up with a possibly complex class hierarchy and many people would advocate composition over inheritance. This is where you'd have interfaces defining behaviour and classes implement the interface to say that they do something but each class can implement the interface methods differently. So your example for the PhysicalServer interfaces may be encouraged.

鸢与 2025-01-13 11:19:09

首先请记住,继承是您提到的此类问题的明显结果。每个班级确实有不止一种行为,每个人都会陷入这个陷阱。所以冷静点。你不是第一个,也不是最后一个。

你需要稍微改变一下你的想法,以打破常规。

您需要从未来“变化”的角度来看待它,而不是看分层的类图。类图可能不是层次结构的,而是需要表示“什么变化”和“什么保持不变”。据我所知,将来你可能会定义一个MobileDevice,VirtualMobileDevice。

在您当前的课程中,您似乎拥有 Vendor、Serial 等属性。 MobileDevice 中可能也需要这些,对吧?因此,您需要修改您的思维,真正考虑行为而不是具有层次意义的类。

反思一下,你正在走上多重继承的道路,这是非常危险和复杂的设计。这里的问题不是你思维过程的正确性。问题是你和某人在不久的将来对某些东西进行编码,使其变得复杂而无法修复。

由于这一原因,java 中不存在多重继承,以确保您不会以分层方式进行思考。

想想“工厂”(用于创建)、策略(用于通用功能/处理)。

编辑:

事实上,您还应该考虑以库的形式创建层,以便对处理的主要部分有完整的抽象和控制。无论您打算对资产/设备类做什么,都应该将其抽象到一个库中,该库可以通过更改进行保护。

To start with remember that inheritance is the obvious result of the kind of problem that you have mentioned. Every class does have more than one behavior and everyone falls into this trap. So chill. You are not the first nor the last.

You need to modify your thinking a bit to break away from the norm.

You need to look at it from the angle of what "changes" in future rather than look at a hierarchical kind of class diagram. A class diagram may not be hierarchical instead it needs to represent "what changes" and what "remains constant". From what I see, in future you may define a MobileDevice, VirtualMobileDevice.

In your current classes you seem to have properties like Vendor, Serial. These may be needed in MobileDevice too right ? So you need to modify your thinking to actually think of behaviors instead of classes that make hierarchical sense.

Rethink, you are going down the track of multiple inheritance, very dangerous and complex design. Its not the correctness of your thought process that is in question here. Its the question of you coding something and someone up ahead in the near future complicating it beyond repair.

No multiple inheritance in java is there for this one reason, to ensure that you dont think the hierarchical way.

Think "factories" (for creation), strategy (for common functionality/processing).

Edited :

Infact you should also consider creating layers in the form of library, so that there is complete abstraction and control on the main parts of your processing. What ever you intend to do with the Asset/Device class should be abstracted into a library, which can be protected by change.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文