We help IT Professionals succeed at work.

Design Pattern?

mrichmon asked
Medium Priority
Last Modified: 2013-12-03
We are trying to do the following.

We have a program where we want a "black box".  The black box will take in a Person object and return back a Result object.  

We can do this in several ways.  One method was to have every black box have a "RunTest" function.  It could be static class or a Singleton pattern.  If we go with instances then we do not ever need more than a single instance of a given black box, hence looking at the Singleton pattern.

However, here is where we hit a problem.

We would like to enforce a few certain things in each black box.  For example, it must have a private function that loads settings from a config (xml) file.  

Therefore an interface will not work.

So, we thought that we could create a base class of BlackBox and have all actual black boxes inherit from that one.  However, we are not sure how this can be implemented without losing the ability to restrict to a single instance.

Is there any design pattern that addresses this issue.  Basically a black box that has a defined function signature, and some pre-defined settings/initialization actions, but that anything else that it does is up to the programmer.  Also a way to restrict to only one isstance if possible.

Watch Question

This is something I looked at, and then moved on from without really solving, so I'll put down what my thoughts were:

-Singleton's are made accessible through a static field or method. However, a static field or method cannot be abstract, so there isn't any real way of making the base of a singleton fully abstract.
-A non singleton class base can be turned into a singleton class.
-Interfaces are used to enforce public interaction with a class, they are no good for re-enforcing coding practice within a class across a team of developers.

So you end up with:
-Defining an interface, and enforcing it on an abstract base. This will define public interaction with the classes.
-Implementing singleton on each top level, sealed concrete implementation.
-Documenting the base class thoroughly to ensure that at all points in the future, any developer maintaining or using this class knows exactly how to do it.
-Abstraction and interfaces go only so far, after that documentation is the only way of enforcing your patterns.

The singleton has to be sealed anyway as the static singleton public field/property/method cannot know what higher level type to instantiate otherwise. The only way to pass that responsibility up is to use an abstract method, but then that has to be an instance method, not a static one, and we are back to square one: static methods cannot be abstract.

...that was where I got to.



I appreciate the comments.

I actually have found some ways to do the Singelton with inheritance - and also as a base static class.  Unfortunately the solutions were not very nice (i.e. one used a hastable of singlesons of the descendant types in the base class and then reflection)  Or the singleton could only ever BE of a singlle base type at any one time - so it wasn't really what I was looking for.

The singleton did not have to be sealed in either case since relfection could allow it to determine what type to instaciate, but it was messy.

I have been struggling with similar logic to yours.  However, it is not good enough in this case to rely on documentation.  It has to be enforced.

I am not bound to the singleton pattern, I am looking for any pattern that will fit the needs.  Our first thought was not even a singleton, but just a class with staticmembers/functions, but that cannot be abstract so doesn't work.  Then we looked at the singelton pattern.  The singleton looked intriguing, but based on the contrainst that we encountered - and you did too it seems - do that may not be the solution.

I am just looking for any ideas on how to implement this pattern/situation.  

For now we are doing:

Regular old base class.  Not restricting instances through C# mechanisms, but just in our own coding practice.  There really is no harm to have serveral of each black box, other than efficiency and memory that is redundant when there is no need.

Technically while we would prefer to have a static function called to "run" the black box, we will create an instance and call a member function.

So it works, but really  seems like this is a situation that others must have come accross so I am interested in what ended up being used and if ther eis a pattern for this type of situation.

Thanks for your comments
As an adendum then ...

"The rest of the changes to the class are meant to disallow sub-classing. Adding the sealed class modifier ensures that this class will not be sub-classed. The GoF Singleton pattern details the issues with trying to subclass a singleton and it is generally not a trivial matter. In most cases, it is very easy to develop a singleton without a parent class, and adding sub-classing functionality adds a new level of complexity that is generally not needed anyway. As complexity increases, so does the time required for testing, training, documenting, and so on. As a general rule, you never want to make any code more complicated than it absolutely has to be."


Well, if code has to be complex, it has to be complex. Frankly that didn't help, it didn't offer me a solution, but it did set me thinking. I have been playing this evening, since reading your question, with the idea of a "singleton factory" for "singletons". I can't find much about it, but the combination seems to have potential - have you already looked at this too? It sounds a bit like your hashtable of singletons. I suppose you maintained a type-unique hashtable?

The problem with singleton inheritance, as we have found, is that it pushes responsibility onto the subclasses, which is unenforceable.

The main reason, that I can see, for using a singleton is when there MUST be only one of a class. For example, I use singletons to broker web requests for my rich client applications. Background to this is that if you open up too many asynchronous web requests at the same time you exhaust the thread pool. As a result, I use a singleton registry to queue requests, only allow a few at a time, and serve waiting requests in some kind of priority vs time waiting order. In that way its a lot like the SqlConnectionPool which I am sure must also be a singleton.

So if you are trying this more for memory conservation than absolutely enforcing one class only per application space, then maybe you don't need a singleton BlackBox, but a singleton registry, or factory? Maybe this hands out objects from its internal collection: each object in this collection is of type BlackBoxBase, but the concrete type must be unique. That singleton class can then hand out the 'BlackBoxConcrete's (but only one of each type). Sounds similar to what you already came up with I guess.

Maybe, taking it further, instead of your clients interacting with the BlackBoxFactory, your BlackBoxes do that part - again in the vein of the SqlConnection. In this way, the factory is acting more like a registry for each type. The BlackBoxConcrete.Instance method says to the registry "get me based on my type" and off you go. Sounds even more like what you came up with. The difficulty is determining the type of a static class.

So then we move back to the private static variable in the base class ...

I'm afraid I can't for the life of me translate those into pattern parts. That's probably because its all too mixed up to have any.

But now it's starting to come together. We could go back to the singleton base class, but make _it_ maintain the registry _itself_?

Still too messy.

Are you using .NET 2.0? Maybe we could use generics to implement the singleton? Hmmmm, more waste paper coming up ...

Sorry for rambling. I have't really come up with much more. I think you are right to try and steer away from singleton in this case, but that's about the only conclusion I came to. Any implementation that I come up with, from factories to an internal registry, to using the stack to get the concrete type that is "calling" the Instance variable, simply adds complexity to the top level type, with no way of enforcing it. Concrete types can declare public constructors which mean that clients can ignore the singleton implementation. Factories can be bypassed. :-(

But maybe generics are the answer?


Not the solution you were looking for? Getting a personalized solution is easy.

Ask the Experts


I found a few articles, but they were more for creating a factory where the singleton was of different types, but always one regardless of type not one per type, which is what I needed.

The hashtable is not type unique - instead it is located in the base class and is of the base type, since a child type isA parent type (to use C++ terminlogy).  Then each sub class places their instance in base class's hashtable.  It wasn't pretty.

I thought about generics, but the type is defined pre-compile time so that doesn't quite fit either.

>>I'm afraid I can't for the life of me translate those into pattern parts. That's probably because its all too mixed up to have any.
I agree :o)

I don't mind the rambling - at least it means I am not missing something obvious since others (you) have also considered this and come up with similar conclusions.


Bear in mind that I am definately not a design patterns expert by any means. I am also self-employed, which means I don't have a team of design pattern experts to bounce things like this around with, and I am unfortunately self-taught.

Have you tried the http://www.experts-exchange.com/Programming/Software_Design/ forum? If you post there then you could create a 20 point link to this question.



Decided to accept with a C as I got no answer, but think the discussion is woth having in the knowledgebase and I appreciate the input I received.  :o)
Access more of Experts Exchange with a free account
Thanks for using Experts Exchange.

Create a free account to continue.

Limited access with a free account allows you to:

  • View three pieces of content (articles, solutions, posts, and videos)
  • Ask the experts questions (counted toward content limit)
  • Customize your dashboard and profile

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.


Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.