I have a large class with lots of methods (25, interrelated of course). I'm not sure I should split it up and create a derivative and base class instead. I don't see any opportunity coming in the future for another class inheriting from the base. So what are the driving factors for breaking a large class down into smaller parts?
+1
A:
what are the driving factors for breaking a large class down into smaller parts?
You should do it when it makes logical sense to do it in terms of separate objects. If all those methods you've defined truly do operate on a single object and couldn't logically be thought of as pertaining to different objects, then keep them in one.
I'm not sure I should split it up and create a derivative and base class instead
Not sure what you mean here. You would derive from a base class when you need an object that inherits some behaviours from a base class but modifies or adds others, but want your base class to remain as it is as well. You don't inherit just to break up your code into manageable chunks.
thomasrutter
2010-08-05 03:28:44
+1
A:
"Large Class" is a classic "code smell". See here: http://sourcemaking.com/refactoring/large-class
When you have a large class, it may or may not mean you have a good candidate for refactoring. That's what a "code smell" is... It may be your code is fine, but only a good hard look at it can you be sure.
Follow the advice given in the article I've linked. Even thought it wasn't written for PHP, the concepts and strategies still apply.
Mike Sherov
2010-08-05 03:33:33
after attempting to break it down into 2 classes, the interdependence of the methods in the class cause a majority of the methods to be in the base class (20). although possible, it seems like splitting the code in 2 parts don't make sense at all. the usefulness of the advice in the link you provided appears questionable, or may not apply in all cases.
stillstanding
2010-08-05 04:04:11
@user, that's what I said. A code smell doesn't always mean you're wrong, and each case is different.
Mike Sherov
2010-08-05 11:01:25
@user, the advice comes from Martin Fowler's Refactoring, which is pretty much the bible on that subject. I'm sorry it wasn't useful in your specific case, but the advice isn't exactly questionable.
Mike Sherov
2010-08-05 11:03:42
any bible is fallible. we don't write code on faith alone. even software metrics are questionable.
stillstanding
2010-08-05 15:28:19
@stillstanding, absolutely. One of the main points Fowler makes is that he's often wrong and that the advice isn't always right. I wasn't saying it was INFALLIBLE, I was just saying that it isn't QUESTIONABLE. He's a reputable source, and the book is number 5 on StackOverflow's big list of programming books everyone should read: http://stackoverflow.com/questions/1711/what-is-the-single-most-influential-book-every-programmer-should-read/13332#13332
Mike Sherov
2010-08-05 16:24:18
+2
A:
Yes, with 20+ methods, break it up.
Sometimes it needs experimentation.
Another option is to look at how to reduce the number of methods. For example do you have the same method (by name) taking different number and/or types of parameters? In that case you might look at commonalities between those signatures. This leads me to another suggestion.
If you have a method that takes more than - let's say 4 - parameters, then look at them and maybe there is an option to turn them into a class by themselves. This can result in some of the functionality moving out into the new class.
Look at the number of fields (= member variables) in your class. Can you group the methods in such a way that they operate largely on a subset of those member variables? Maybe you can turn these methods and the values they operate on into a new class.
John
2010-08-05 04:46:02