Derik Davenport wrote:I tend to end up with a single motor object class with 25 "task" methods and another 10 or so "support" methods.
Derik Davenport wrote:As for me, I have one approach that I have found somewhat useful. I start by examining all of the variables (fields) in the class. If there is a subset of all the fields, that can be combined with a subset of methods that exclusively use those same fields, then the fields and the methods can be cleanly removed from the original class and placed into a new class, an instance of which is now owned by the resulting "original" class.
I am interested to learn how other programmers handle this.
And I think that is a good point. That class is huge. And yet, how could it be otherwise? Perhaps I am just being paranoid about how big my classes are. When I came from C, I found I could usually keep files (groups of related functions with shared (file scope) variables) to less than 500 lines or so. More than that and they start to get hard to edit. I have no idea how many lines are in String, but it might be 10 times that size. And what a pain it must be to trudge around in there and edit that thing.
Should we take String as an example or as a counter-example?
you can use a technique called 'lexical analysis':
I have always enjoyed the "thinking" aspect of writing programs. But there a few patterns that I keep seeing in my programs (like really large classes) and then I start to wonder if that is normal or if it is just that my thinking is in a rut.
programming is much more than coding: it's about thinking