Turning my inherited classes in an Abstract 'factory' C#

Question

Hi all, I'm not really pro and find my question quite hard to describe, so please ask if anything is unclear:

I have an abstract class called BaseDevice. Other devices, as Beacon and Transponder, inherit from BaseDevice. For example the Beacon, it has the BaseClass methods PLUS its own properties and methods. Let's say, the difference between these devices is that one has 2 LED's and one has a LCD

At the moment its not possible to make a device Transponder as well as Beacon (or i have to copypaste both into one new class, which is not wanted).

So, for example, I want to be able to make a Device say to it: "You have one LED", "You have 2 LCDs" or whatever. and all the methods and properties that come with it should be available. I still need to be able to see what device in my list of devices "Does he have one (or more) LED's"

Conclusion: I want to make turn my "Is A" into ""Has A" (as the Gang of Four recommend).

I have read once about the Factory Design Pattern which looked complicated. Would this be a good solution in this case?

Maybe I used some therms here that exceeds my knowledge, this project is the first one i used abstract classes etc. I'm really not that much of a Object Oriented Programmer. Design Patterns are quite hard for me to read, so answers that are easy to read are more than welcome.

Answer 1

To me this sounds like you need a Decorator.

In object-oriented programming, the decorator pattern is a design pattern that allows new/additional behaviour to be added to an existing object dynamically.

The decorator pattern is an alternative to subclassing. Subclassing adds behavior at compile time, and the change affects all instances of the original class; decorating can provide new behavior at runtime for individual objects.

The tricky part for you would be to define a common interface for all subclasses. If this is not possible, you can't use your objects polymorphically anyway.

Answer 2

I think what you need is some additional classes for the components of your devices. For example, if there's some behavior related to LED's and you find yourself copy/pasting this code, it is a strong sign that you need an LED class. This way you can have List<LED> field and Add(LED newLed) method which you can use on the concrete components. Essentially this is "Has A" relationship. You can have another class for LCD's, and now you can mix and match those things as you like in your concrete classes.