|
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.
|
|
|
|
|
That's the question of the ages! I don't really have a good answer for you. One criteria is if the methods / fields / properties seem unrelated then group the related ones into separate classes.
"If your actions inspire others to dream more, learn more, do more and become more, you are a leader." - John Quincy Adams
|
|
|
|
|
Thanks. Does that imply that if they are closely related, then it doesn't matter how big the class gets?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
not necessarily, you just need to use a more refined meaning of "closely related"
"If your actions inspire others to dream more, learn more, do more and become more, you are a leader." - John Quincy Adams
|
|
|
|
|
Different developers will have different ideas so like most things I do, just make sure you have a good argument to do it so when other members question why you did it, you have an answer.
For me, I start looking at redesigning a class when its over 10,000 - 15,000 lines.
Architecture is extensible, code is minimal.
|
|
|
|
|
If I was in your place, I would consider this:
1. Can the methods and properties be re-grouped into smaller batches and they will still work independently.
2. If they cannot, can I see signs of possible parent child relationship? If yes: inheritance.
3. How the class used in the application?
If all you are concerned about is the size of class file, then partial class comes to rescue. Or else you can use regions and expand only the one you are concerned with.
|
|
|
|
|
i like partial classes. I hate regions.
"If your actions inspire others to dream more, learn more, do more and become more, you are a leader." - John Quincy Adams
|
|
|
|
|
Some classes are just going to be big, that's how it is sometimes. However, when we think about a 'rule' or a 'law' (in litigation or in engineering), we don't follow the rule blindly - we think "what is the law there to protect? What's its purpose?".
So, one of the golden rules "don't write mammoth classes" comes down to understandability, flexibility and separation of concerns (there are possibly more interpretations). That being the case, if your class is readable, fairly flexible and has a clear single purpose, then you've satisfied the underlying reasons for the rule - even if the class happens to have 2000 methods.
If you really think it's not achieving this, maybe only in terms of readability, then you could use partial classes[^]; you could restructure the class internally, maybe to use some encapsulated classes (you can't mention refactoring without mentioning Martin Fowler[^]); you could come to terms with the size  Really, it's up to you if it's working or not.
Last but not least, I think the greatest invention in C#-land was the #region directive[^] - in a huge class, this is invaluable!!
EDIT: d@nish already beat me to partials and regions! damn... I thought I was so original 
|
|
|
|
|
I agree with all that you say, but I have to say I hate regions. Partial classes are better. Just my opinion, personal preference...
"If your actions inspire others to dream more, learn more, do more and become more, you are a leader." - John Quincy Adams
|
|
|
|
|
Interesting though, is it just an inexplicable idiosyncrasy or do you have an explicit reason? It's just I've never known people to use partial classes except in conjunction with code generators.
EDIT: Modified to question as according to Manfred partial classes are not a joke 
modified on Thursday, January 27, 2011 6:58 PM
|
|
|
|
|
I'm not quite sure why you marked your reply as a joke. If I'd see anybody on my team distribute a class into partials because it "got to big" I would not be "amused" to say the least.
|
|
|
|
|
It was marked as a joke because initially I was just going to post a crying face, joking that I was deeply offended by Ahmed's pure hatred for regions. Then I was curious, as I've never seen, nor thought to, separate a class into partials (except when using code generation, obviously).
Interesting, why are you so against partials?
|
|
|
|
|
I'm not per se against partials, but I do think the splitting of big classes into smaller pieces is an abuse of this otherwise great feature if the only intend is to get smaller code chunks.
In my opinion good/acceptable uses:
- Separation of generated and hand written code
- Separating the implementation of interfaces from "regular" class code especially when there are many interfaces to implement
- Splitting the implementation of a "big" class for disconnected teams (no access to a common source repository)
- Separate static stuff from instance stuff
Let me know your take on the usage scenarios.
Cheers!
|
|
|
|
|
Normally it would only be the first point you mentioned for working with code generation, but I like the idea of seperating out interface implementations! That's cool! Am I getting you right, so eg. An IList<t>, IEnumerable<t> (contrived):
Filename: MyList.IList.cs
public partial class MyList : IList<string> { ... }
Filename: MyList.IEnumerable.cs
public partial class MyList : IEnumerable<string> { ... }
Is this kind of what you mean (naming convention notwithstanding)?
Also, I think I may even adopt using partials for separating static and instance code. I normally use regions for that, but it still annoys me when I confuse them... Very interesting insight! Thank you, I'm glad I asked you that question 
|
|
|
|
|
You got what I was trying to say even though I'm not sure if you can write it that way. My take on this would be that you would have to mention all the implemented interfaces in every partial class definition, but to be really sure I would need to try your take on this in a real example.
|
|
|
|
|
Because regions are horribly abused and the break the natural collapsing of methods that the IDE does, making it harder to read code.
Because people abuse regions to "break-up" a very large functions into smaller pieces. If it needs a f***ing region, then put that section of code into another method! and if there are so many methods that you need to region-ize them, then put them into a separate file (partial class)!
aaaaaggghh!
"If your actions inspire others to dream more, learn more, do more and become more, you are a leader." - John Quincy Adams
|
|
|
|
|
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
}
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.
|
|
|
|
|
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.
|
|
|
|
|
Size of the class doesn't make any problem and the partial classes are not used for making small chunks of code as well.
In fact partial classes are used to eliminate the readability problem.
and my argument is this one that when we create new window form in visual stdio so the class is divided into two parts. In one part of the class the declaration initialization of different controls are performed and the second part is given to the user to use those controls.
now think if we have both the things in one class then it will be difficult to manage.
thanks
|
|
|
|
|
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.
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.
|
|
|
|
|
Size doesn't matter... well, not directly anyway.
How many people are working on the project? I prefer to keep files small to reduce the need for multiple developers needing to modify the same file at the same time (an ounce of prevention is worth a pound of cure). The goal, then is to split it up into functional sections, and I do like partial classes. At the extreme (and I know extremes) you can have one method per file, but even I don't go that far (yet). The next thing is to put overloaded versions of one method in one file. And you can put similar methods (like operators) in one file. Basically, I'd say that it's better to have too many parts than too few.
Some of my "largest" classes are Data Access Layers -- all the methods that access tables in a particular database. Unfortunately, with many, I started writing them before partial classes were introduced so each is in one big file  . More recent DALs I split into a section for each table. You could, instead, make a section for inserts, another for deletes, etc., but that doesn't seem right. It also doesn't seem right to develop separate classes for each table or action.
So if you have separate files for each table, you can assign Alice to work on Employee methods and Bob to work on Department methods, etc.
|
|
|
|
|
|
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.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
