Breaking Up Classes
-
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?
-
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.
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.
-
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!
-
:(( 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 ;P
modified on Thursday, January 27, 2011 6:58 PM
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 fucking 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
-
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, IEnumerable (contrived):
Filename: MyList.IList.cs
public partial class MyList : IList { ... }Filename: MyList.IEnumerable.cs
public partial class MyList : IEnumerable { ... }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 :)
-
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, IEnumerable (contrived):
Filename: MyList.IList.cs
public partial class MyList : IList { ... }Filename: MyList.IEnumerable.cs
public partial class MyList : IEnumerable { ... }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 fucking 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 // 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.
-
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
-
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.
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 X| . 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.
-
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.
