Breaking Up Classes
-
So it's really about how you've seen them used? Ok, well I hardly ever use a region inside a method, I think that's a bit crazy. There is one exception to this - when there is horrific yet necessary code, I may "region it out" of a method saying "Ugly Code - DO NOT TOUCH" or something similar :) I think I've only committed this atrocity once... I generally use regions to separate parts of the class, eg.
public class SomeClass : IUpdateable, IDrawable
{#region Private fields #region Constructor #region Properties #region Methods #region Static methods #region Event production #region Event consumption #region IUpdateable implementation #region IDrawable implementation // etc.}
It's usually pretty free-form my region-ising and its naming convention, but I tend to have the four: Private fields, Constructor, Properties and Methods in every class. For me it makes it easier when I go back to it to edit, for example, a method - I don't want to scroll or whatever, I just want to see the methods.
I've regioned some error-handling in some methods, but it's not a habit.
-
What should I use as a rule of thumb for being able to tell when it's time to break a large class into two? I know that a class should have only one responsibility, but sometimes it's hard to tell.
The difficult we do right away... ...the impossible takes slightly longer.
-
What should I use as a rule of thumb for being able to tell when it's time to break a large class into two? I know that a class should have only one responsibility, but sometimes it's hard to tell.
The difficult we do right away... ...the impossible takes slightly longer.
One of the goals of programming is clarity. Clarity facilitates software maintenance, and makes code more reliable since it's easier to spot errors. Another (sometimes contradictory) goal is efficiency. So, if your class split improves clarity or efficiency, it could be the right thing to do. One measure of clarity is the amount of interaction between the two split classes, called "coupling". If every method in one class depends on, and interacts with something in the other class, the classes are coupled, and this impairs clarity. E.g. to understand a method in one class, you constantly have to bring the other class up on the screen. This breaks your train of thought, and makes consequences of changes less clear. If the two split classes are independent, with little coupling, splitting them is probably the right thing to do. Small classes are easier to work with than large classes, so this improves clarity.
-
What should I use as a rule of thumb for being able to tell when it's time to break a large class into two? I know that a class should have only one responsibility, but sometimes it's hard to tell.
The difficult we do right away... ...the impossible takes slightly longer.
If you think you need to ask the question about a class, it is probably time to refactor it.
I wasn't, now I am, then I won't be anymore.
-
Class size doesn't really matter, well it sure isn't a primary concern. Object orientation should guide you. I'll assume it isn't a huge static class holding everything (as a VB module would). My advice would be you ask yourself a number of questions: 1. check the class name. Does it cover well everything inside the class? And would it be easy to come up with one or two new names that cover the content any better? 2. check your "executive summary" comment, which is supposed to describe at a high level what your class is offering. Does it exceed 5 lines of text (excluding the petty details that aren't executive at all)? Does the text suggest a split somehow? 3. look for inheritance. Are some parts of your class only relevant to some of its instances? If so, use inheritance. 4. look for properties and methods that may be relevant to other objects, i.e. that would have (potential) value when applicable to other objects. If so, consider aggregation. See e.g. the decorator pattern. 5. test yourself: without looking at the code, try and name all public properties and methods by heart. If you can't name half of them right away, you might be better of with a smaller class, if that were possible. After looking at it from those different angles, I think you should know what to do (and if you don't, it tells you it doesn't really matter). :)
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
-
I just realised that my mouse seems to automatically move into position ready to click "Good Answer" whenever I start to read one of your Answers. I wonder if my sub-conscience will ever be wrong...
return 5;
You can't hold me responsible for your actions, consciously nor otherwise. Just keep clicking whenever you feel an urge. :-D
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
