Given a class hierarchy like this one: a package tree would it be a good idea to have a class that helps in creating the objects? E.i. a class with methods that correspond to each class that can be created (method equals() returns a CompareCriteria eg). The advantage I see is that it would hide away the complex inheritance structure and dependencies would be reduced.
+1
A:
There are two or three patterns for object creation. The most common is the factory, which seems applicable in this hierarchy. I don't quite recall the other ones (nor how many there are), but I think another one is called prototype.
If you care about such things, get the book on design patterns.
Daniel
2009-07-27 19:31:40
The book that Daniel is referring to is Design Patterns: Elements of Reusable Object-Oriented Software (http://www.amazon.com/Design-Patterns-Object-Oriented-Addison-Wesley-Professional/dp/0201633612), sometimes called the Gang of Four (or GoF) book.
Thomas Owens
2009-07-27 19:33:06
+4
A:
Patterns for object creation include Builder, Factory, and Prototype. Wikipedia has a fairly detailed list.
pianoman
2009-07-27 19:35:33
@Jens Schauder - `koen` already sees some advantages to a creation pattern, and the package is clearly already available without an implementation of such a pattern. Everyone below is doing the same: pointing to general resources to direct the addition of this kind of pattern, since that's what the real question is.
pianoman
2009-07-27 20:07:21
+2
A:
They are actually a type of design pattern - creational patterns. Wikipedia has a reasonable description of these pattern types - which originate from the GoF book:
http://en.wikipedia.org/wiki/Creational_pattern
- Abstract factory pattern
- Factory method pattern
- Builder pattern
- Lazy initialization pattern
- Object pool
- Prototype pattern
- Singleton pattern
Jon
2009-07-27 19:37:37
+1
A:
The class hierachy says nothing about the need for a Factory Method or any other specialized way to create objects. What do you want to do with all these classes? Will it be difficult to use? Will it be difficult to extend?
Does creating a Factory or similar improve the situation?
If you can't make up your mind, create some examples of using the classes (realistic examples please) then refactor those to use you Factory.
After that exercise you should be able to decide for yourself. Or to come back with some more specific problems.
Jens Schauder
2009-07-27 19:59:26
A:
Doesn't seem terribly complicated. You might want to look into how you are going to do your Unit Testing before you choose--factories can make it really hard to properly inject mocks.
Also I haven't seen anyone else list Dependency Injection--I'd look into a DI toolkit as well because it will solve the unit testing problem and a few others associated with common building patterns. It looks like some of your classes build on others (like you might combine them to solve a problem), and DI helps with that a lot.
Bill K
2009-07-27 20:09:10