Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

What do I need to consider to determine which design I choose when I have the following scenario?

There are two cases to considerer;

  • Given T a generic class, I have to do something with multiple T's (Iterating each one of them).
  • In other cases, with the same T, I have to process just once.

In both cases, independent of what is T and how I'll need to process it, the class that comprises T will behave exactly the same way, therefore, I don't need to worry about implementation details.

There are 2 possible solutions, and I don't know what directions should I follow to decide between them.

  • Always consider as a List, this is for sake of simplicity, since there are no difference between a List of T and only T.
  • Use inheritance; the first child class will receive a List of T and work with it, the second, a single T and work with it.

Are there some good pratices or some article to help to decide such cases? I'm looking for something like this article, or your experience as well.


The class I'm design is not T, but its composer.

share|improve this question
Why can't you use a list of T everywhere? A single value of type T will be just a list of length 1. – Giorgio Jan 20 '14 at 11:32
Exactly, that's the question! – EProgrammerNotFound Jan 20 '14 at 11:33
Do you have any control over these T objects? Or might they be anything? – Bill Michell Jan 20 '14 at 11:35
But if you do not have any argument against my (rhetorical) question, you have your answer already. – Giorgio Jan 20 '14 at 11:37
@BillMichell They might be anything, they always implement the same interface that is the only thing its composer know. – EProgrammerNotFound Jan 20 '14 at 11:40
up vote 6 down vote accepted

If processing every instance of T is independent of processing the others, I'd just create a class that processes one T and then enwrap it with a class that "feeds" it with a sequence of Ts and just calls the first class in some sort of a foreach block.

I wouldn't use inheritance for that.

Simplified example (C#):

interface IFoo
    void DoStuff();

class FooProcessor<T> where T : IFoo
    public void Process(T item)

class MultipleFooProcessor<T> where T : IFoo
    // composition over inheritance - MultipleFooProcessor does not share any "genes" with FooProcessor, 
    // it just keeps an instance of it in a private field
    FooProcessor<T> processor;

    // we're passing a regular FooProcessor here. 
    // thanks to not using inheritance, we could eg. create an IFooProcessor interface
    // and pass a different implementation of IFooProcessor here, allowing for a more flexible design.
    // see: dependency injection, loose coupling
    public MultipleFooProcessor(FooProcessor<T> processor)
        this.processor = processor;

    public void Process(IEnumerable<T> sequence)
        foreach (T item in sequence)

    public void Process(T item)
share|improve this answer

If only the individual items T are being processed, without any relation to eachother, I would just create a single class that works on a single T. This keeps that class as simple as possible. Iterating over multiple Ts and applying the action on each one can be the responsibility of some other class. This way there is no reason to create a list object when working on an individual item, nor are there multiple classes which basically do the same thing.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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