C# Different class objects in one list

Question

I have looked around some now to find a solution to this problem. I found several ways that could solve it but to be honest I didn't realize which of the ways that would be considered the "right" C# or OOP way of solving it. My goal is not only to solve the problems but also to develop a good set of code standards and I'm fairly sure there's a standard way to handle this problem.

Let's say I have 2 types of printer hardwares with their respective classes and ways of communicating: PrinterType1, PrinterType2.

I would also like to be able to later on add another type if neccessary. One step up in abstraction those have much in common. It should be possible to send a string to each one of them as an example. They both have variables in common and variables unique to each class. (One for instance communicates via COM-port and has such an object, while the other one communicates via TCP and has such an object).

I would however like to just implement a List of all those printers and be able to go through the list and perform things as "Send(string message)" on all Printers regardless of type. I would also like to access variables like "PrinterList[0].Name" that are the same for both objects, however I would also at some places like to access data that is specific to the object itself (For instance in the settings window of the application where the COM-port name is set for one object and the IP/port number for another).

So, in short something like:

In common:

• Name
• Send()

Specific to PrinterType1:

• Port

Specific to PrinterType2:

• IP

And I wish to, for instance, do Send() on all objects regardless of type and the number of objects present.

I've read about polymorphism, Generics, interfaces and such, but I would like to know how this, in my eyes basic, problem typically would be dealt with in C# (and/or OOP in general).

I actually did try to make a base class, but it didn't quite seem right to me. For instance I have no use of a "string Send(string Message)" function in the base class itself. So why would I define one there that needs to be overridden in the derived classes when I would never use the function in the base class ever in the first place?

I'm really thankful for any answers. People around here seem very knowledgeable and this place has provided me with many solutions earlier. Now I finally have an account to answer and vote with too.

EDIT:

To additionally explain, I would also like to be able to access the objects of the actual printertype. For instance the Port variable in PrinterType1 which is a SerialPort object. I would like to access it like: PrinterList[0].Port.Open()

and have access to the full range of functionality of the underlaying port. At the same time I would like to call generic functions that work in the same way for the different objects (but with different implementations):

foreach (printer in Printers)
    printer.Send(message)

Answer 1

a Pseudo-example using interfaces.

public interface IPrinter
{
   void Send();
   string Name { get; }
}

public class PrinterType1 : IPrinter
{
  public void Send() { /* send logic here */ }
  public string Name { get { return "PrinterType1"; } }
}

public class PrinterType2 : IPrinter
{
  public void Send() { /* send logic here */ }
  public string Name { get { return "Printertype2"; } }

  public string IP { get { return "10.1.1.1"; } }
}


// ...
// then to use it
var printers = new List<IPrinter>();

printers.Add(new PrinterType1());
printers.Add(new PrinterType2());

foreach(var p in printers)
{
  p.Send();

  var p2 = p as PrinterType2;

  if(p2 != null) // it's a PrinterType2... cast succeeded
    Console.WriteLine(p2.IP);
}

Answer 2

Create an interface (say IPrinterType) that holds your "common" methods and use this interface instead.

Answer 3

What you're looking for is an abstract base class, like so:

abstract class Printer
{
    public string Name { get; set; }
    public abstract string Send(string Message);
}

You then inherit from that class and implement your Send() function as desired.

You can use an Interface here, too. The difference is that an Interface can only specify what Properties, Methods and Events an inheriter must implement -- it does not implement any code itself. Which you use depends on what fits best with your application. You may well wind up doing both (creating an abstract class that implements an interface).