Splitting objects into their most fundamental parts

Question

Not sure if the title captures what I'm trying to say here.

When designing in OO should I be splitting my objects up into their most specific areas - so if I have a factory object that deals with creating objects but later on i come across a way of creating objects for another purpose even though they may be the same objects is it worth creating a seperate fcatory or just add to the exsiting.

My biggest worry is bulking up classes with tons of stuff, or splitting objects and diluting my projects into a sea of classes.

Any help?

EDIT:

I guess on a side note/sub topic part of me wants to find out the level of granularity you should use in a program. Kind of, how low should you go?

Answer 1

My biggest worry is bulking up classes with tons of stuff, or splitting objects and diluting my projects into a sea of classes

This is a very valid point and in any even reasonably sized project, extremely difficult to get right up front especially because realistically, requirements themselves evolve over time in most cases. This is where "Refactoring" come in. You design based on what you know at any given point and try not too make too many leaps of faith as to what you think the system MAY evolve to.

Given that you know what you are building right now, you design your classes trying to make the best possible use of OO concepts - eg encapsulation / polymorphism. This is itself, like others have noted as well, can be notoriously difficult to achieve and thats where experience, both in designing OO systems as well as knowledge of the domain can really come in handy.

Design based on what you know --> Build It --> Review it --> Refactor it --> Re-design --> and it goes on and on..

Answer 2

Finding the correct level of detail and responsibility is what makes OOP design so difficult. We can help you with a specific case but not with anything this general. If there were algorithms or strict methodologies of how to solve this, everyone could be an OOP designer.

Answer 3

A rule of thumb I like for deciding "is this getting too big now?" is "can I explain the purpose of it concisely?" If you start having to introduce caveats and lots of weasel words to explain the functions of a component of your design (be it class, member variable, method or whatever) it might be a good indicator that it's getting too complex and should be split up.

Answer 4

In your specific case, if you already have a factory object then the DRY Principle (Don't Repeat Yourself) would say that it's a bad idea to create another factory that does the same thing.

Is this an actual problem that you face? Or merely a fear about how your code might grow in the future?

Answer 5

If you are using the same type of object to solve drastically different problems then you may need to redesign the class to focus on seperation of concerns. If you need a more specific answer, you will need to provide an example of a type of class that would need this functionality.

---

I might have worded things badly in the Q. I guess I wouldnt be repeating myself its just more of a case of where to put the code, it could be added to an exsiting factory that creates design objects for exporing data to excel spreadsheets. On the other hand I could see it could also have its own factory for importing excel data. Both factories would produce the same objects but the inner workings are completely different. –

If you aren't doing or plan on doing any class abstraction (subclassing or using interfaces) you may not need to use the factory pattern at all. The factory pattern is generally best suited for supplying objects of a base class type or that implement a specific interface.

Answer 6

Both factories would produce the same objects but the inner workings are completely different.

Not sure if I've understood you correctly, but this sounds like a candidate for the AbstractFactory pattern.