Opinions. I understand your class represents the functionality that you
need. I just made a funny observation that someone said to me a long
time ago. No need for you to take it personally.
Who said it was personal? I read your comment, and perhaps it was
funny to you, I heard that remark as a serious remark mentioned to novice
developers (not me) a lot, and not as a funny remark. That's also why I
mentioned the 'has to fit on screen', quote, which is funny today, but was
hard reality in those days.
Nevertheless, I read several comments in this thread about the
class that is 7000 lines long. My project explorer window class in LLBLGen
Pro is 3116 lines long. That's 3116 lines of eventhandlers, management
code for the form and its controls (treeview etc), a lot of context menu
manager routines and handlers and properties. NO Application logic
whatsoever, that's placed in an assembly in a lower tier. True, I could
have subclassed the treeview and place logic there. However that would add
ANOTHER layer to the event chain running from the treeview's context menus
to the main gui the project explorer is docked in. What fun
(and it
doesn't decrease complexity, which is the real reason a lot of lines is
not preferable: when you use a lot of classes you can abstract away some
code, however when abstracting away code snippet ABC increases complexity
because housekeeping event handlers have to be added, it doesn't help a
lot
)
Just an example how code can grow. Crying fool how crap a class
must be when it is 7000 lines long is moronic. Doing so shows you haven't
programmed complex gui's in .NET. True, when you want, you can group every
set of controls in a new control and hide the code in there, which will
lower the # of lines in the beginning, but will bite you in the foot when
overall application behaviour has to be kept in sync.
I'm sorry, but joking around about a guy's 7000 lines class is out
of order until you've seen the code yourself.
Or course, the 7000 lines of code is your code and you are the one that
has to work on it. I am glad it isn't me.
It wasn't me with the class of 7000 lines. However starting to
throw mud on the guy who had that class is zealotery: "Look, I know how to
design OO hierarchies, you're hierarchy stinks". As I said: measurements
of correct class size based on whatever measurement is pretty bogus: it's
one way or the other: a big class with not a lot of overhead code or a
large set of small classes with a lot of overhead code. What the most
optimal situation is between the two is not determinable by looking at the
class size, because what law proves that that measurement is the golden
rule? Nothing.
7000 is a lot of lines, however it can also have a lot of methods,
a lot of comments. I have classes which have a couple of thousand lines.
Most of these classes are not about a data element and the code targeting
that data element, but a group of functionality in one spot, like a
database driver or a main-form gui manager. Why would I have to chop it up
into more than one class? And better: what should be used as a dividing
rule what goes where? Chopping up classes can be good, but when there is
NO THEORY behind it, it's the most stupid thing a person can do: it will
increase the overhead in your application and if you're not careful it
will do that on a dramatic scale.
When you have a complex GUI which tries to keep everything in sync
(try to start thinking about the logic you need when you have an element
in your gui which name is shown in tabs, treeviews, controls, window
headers etc. that's eventhandler galore and a lot of code.) classes grow
out of proportion, classes can grow then beyond an amount of lines some
people find 'disgusting' or 'crappy design'. I can tell you: I've spend a
lot of time refactoring my GUI classes to make them smaller, however at
some point it isn't worth the effort, simply because chopping them up will
only create bigger classes.
Also, some program very verbose. I add a lot of commentlines, add a
lot of small methods and they all have XML comment tags, I also use a lot
of whitespace. This will add a lot of lines extra.
Don't forget that classes are logical, semantical boundaries of
code. It's simply stupid to divide a logical, semantical unit into two or
more classes simply someone says hte amount of lines is beyond a scale no-
one knows if its true or not. Again a reason why critizing a guy's 7000
lines class (which you do, don't forget that) is, sorry, a lame thing to
do, who says you are better than he is and your code is better than his?
Perhaps you would have ended up with also a 7000 line class as he did.
(imagine a form with a tabcontrol with a lot of tabs and a lot of code to
keep that working the way it should, that's a lot of overhead code you
can't abstract away).
Just a FYI.
FB
)