0

I have been learning a lot of inheritance in C#. But am wondering if there are other ways that can be cleaner for component based setups.

I have objects that are all pretty much the same but they have a unique behaviour tied to them, which i currently just override a virtual method.

So every new component i'm making a new class that inherits the Component base class.

Are there cleaner ways to do this in C# rather than have 15 scripts of a class of each component and their unique behaviour?

Pseudo example of the inheritance i have:

Base Class - Component
WaterPump : Component
   //unique behaviour moves water around a system
PowerGenerator : Component
   //unique behaviour creates power units and adds to the system
enter code here
WaterGenerator : Component
   //unique behaviour creates water units and adds to the system

....the list goes on

They have other unique behaviours beyond just simple add/create but just wanted to explain the situation. I have a lot of classes for every single type that requires unique behaviour.

It's starting to get a bit silly - but i don't know how to attach a behaviour to a component so i am not creating a new derived component every single time. Is there any design setup i can do that can improve this?

Improve this question
8
  • I'm confused by how PowerGenerator and WaterPump are seen as related. Seem pretty different to me. What do they have in common? What is the justification for giving them a common base class?
    – John Wu
    May 22, 2018 at 3:15
  • They are both components connected to a system. So they both have base class Component. But they have different behaviours, one generates units to the system (generators), the other moves units around the system (pumps) in this case electricity doesn't require a pump since it propagates instantly in my case. But water moves subject to the pump's information.
    – WDUK
    May 22, 2018 at 22:20
  • "They are both components connected to a system." Sorry, I am not sure what that even means. In software, pretty much everything is a component of something. What is the difference between Component and System.Object, in your solution?
    – John Wu
    May 22, 2018 at 22:26
  • What do you mean ? Think of a water system in real life. A tap is a component of the system just as much as the pump, but they have different unique behaviour that effects the system, tap removes the water from the system, the pump moves the water around the system. They are both components in said system. This is the same idea in my code - any entity in the system is naturally a component of the system, but has its own unique behaviour.
    – WDUK
    May 22, 2018 at 22:33
  • Not trying to be pedantic. I find that these design questions often resolve themselves when I force myself to be very specific, so there is a purpose to this madness. Now. The spigot on my house and the pump in your office are not in the same system, so that does not explain a relationship between types, only between certain objects. What do the types have in common? Does Component offer any common properties or methods? Or do you just need the capability of storing spigots and pumps in a single list, i.e. a List<Component>? Why is that better than using a List<object>, for example?
    – John Wu
    May 22, 2018 at 23:19

1 Answer 1

Reset to default
2

One way is by passing an instance of an object to the constructor of your component class. This instance contains the data and behavior that may vary, whilst the component class contains that which is common.

Your instances can either be classes with a common base class/interface, or delegates, even lambdas.

Improve this answer
6
  • But doesn't each unique behaviour then still need to be a derived from some base behaviour ? Does this really get around having lots of derived classes ?
    – WDUK
    May 22, 2018 at 22:39
  • Yes, you can use composition via fields or method arguments to vary behavior in the same way you use inheritance.
    – Frank Hileman
    May 23, 2018 at 0:00
  • In fact, inheritance is entirely unnecessary. It is a convenience. Inheritance allows you to share fields and code both, without writing explicit calls to a shared instance.
    – Frank Hileman
    May 23, 2018 at 0:02
  • Not sure i understand what you mean by compositions via fields. Can you show a pseudo example so i understand?
    – WDUK
    May 23, 2018 at 0:21
  • If i have a field Behaviour and apply say Generate : Behaviour Well each behaviour might need different arguements in its main run method so would i also then be constantly cast checking from component?
    – WDUK
    May 23, 2018 at 0:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.