Programming for someone with blinders
One of your goals as a developer should be to make your code as readable as possible, both for yourself, and for the other developers you work with.
One great way to determine if your code is well written, is to ask yourself if the code you’re writing is readable by itself. Another developer should be able to jump into a module, and have a fairly easy time seeing what’s going on. They shouldn’t have to sift through thousands of lines of interweaved code to figure out what’s going on.
Of course, what I’m talking about is simply a test for the single responsibility principle. If you’ve written a huge "do it all" class with thousands of lines of code, you’re ensuring that you’re the only one that will be able to maintain it. That that type of code usually suffers from high coupling to the other modules in the program.
I used to organize code into classes based on the type of functionality being provided. I used them more as containers for related functionality. At the time, I didn’t see a reason to split it apart. I was very wrong.
In a recent article by Jimmy Bogard, he walks through creating classes with a separation of concerns. In the conclusion is my favorite part:
Now we have many more classes (4 vs. 1) and interfaces (3 vs. 0). For those who don’t like more classes, GET OVER IT.
That is an excellent point. Why should you be afraid of creating more classes and interfaces? It’s really not more code to write, in fact, it’s often less. Refactoring tools remove many of the obstacles of maintaining the interface, class, and method structure
When someone looks at your code and you have 4 classes instead of 1, and those classes are very specific and short enough to process by our tiny brains, it will be much easier to maintain and modify (or even better, extend).
Al said,
Wrote on July 23, 2008 @ 9:29 am
While I don’t think anyone should be scared of creating additional classes where required, you do have to be mindful of having too many classes, too many interfaces, to overly complex inheritance.
Being able to understand a given class is one thing, being able to understand the system and how/why it is constructed in a particular way is another thing entirely I think.
I know I’ve seen people walk into sections of a software stack that is deliberately heavily decoupled and flounder for quite a while - until they finally nut their way through it or seek help from a more senior programmer.
Remember, everything comes with a trade off.
Rex said,
Wrote on July 24, 2008 @ 2:39 pm
But what about job security…? JK
I really agree with you. Having an application split up into different classes really is the easiest way for me to understand it.
I’d much rather have different classes representing objects and an actual data access layer, etc, than having a Windows Form with 10,000 lines of code in it that does everything.
Romeo said,
Wrote on July 26, 2008 @ 3:07 am
I share your enthusiasm when it comes to being strict with coding standards, particularly with the readability of codes.
Some TLs who’d like code reviews, with this in mind, you’d have to worry less.
It’s basic OOP principle…”Separation of concern”.
Design your classes for their consumer said,
Wrote on August 11, 2008 @ 2:45 pm
[...] have a tendency to just focus on the class we’re currently working on. Of course I believe this is a good thing, because we all know the importance of focus. However, you should never forget the reason [...]
Bookmarks about Flex said,
Wrote on January 12, 2009 @ 5:45 am
[...] - bookmarked by 4 members originally found by cstarrett on 2008-12-17 Programming for someone with blinders http://www.ytechie.com/2008/07/programming-for-someone-with-blinders.html - bookmarked by 1 [...]