The world is a much simpler place if you can just coast through it, without having to expend precious mental energy. In fact, it seems widely encouraged in many organizations: if we can prevent our employees from thinking too much, they will stay out of trouble. Unfortunately, to build insanely great software requires thought on many different levels, which doesn’t go well with prescriptive approaches.
You see all sorts of prescriptive approaches in software development, both large and small (this entry covers small, the next Snake Oil piece covers large). Small prescriptive manna floats down in many different guises, mostly in a good context like design patterns and best practices. Many developers take these nuggets out of context and start believing that this Prescription for building all types of things represents the One True Way (without bothering to apply additional thought). Don’t think that I’m denigrating design patterns – they are clearly a good thing, as a way to catalog common patterns. The problem comes in when they are used without thinking.
Here is a classic example that appears all over the Java code I see every day. Java doesn’t really have a
struct-type thing, which is just a holder for data. In Java, everything is a class, which is OK. Nevertheless, I see developers who just need to pass composite data around creating a Java class with accessors and mutators that won’t every be used for encapsulation. It has become a common prescriptive practice in Java to create the class, create private member variables, and generate getters and setters for them without remembering why you create accessors and mutators. If this class is never going to have any behavior attached to it, if it is a simple container for information, you don’t need the accessor/mutator pair or the private scoping – make them public. If you really need to add behavior later and/or encapsulation, you can refactor the class into a real class, not just a composite data type.The real sermon here is to think about why you create things, don’t just blindly create artifacts. Yes, encapsulation is generally a good thing, but isn’t required in every single thing that looks like a class – sometimes it’s really just a
struct. You must always be diligent about why you are creating what you create.
3 comments:
Why use a class at all? Dave has an interesting point about how coding in Ruby has changed how he does things in Java - he uses a Map for alot of things now Server Side interview: http://blogs.pragprog.com/cgi-bin/pragdave.cgi/Random/TSS.rdoc).
Yes, I understand there are reasons for doing it (like "the compiler makes sure I don't make a mistake"), but it's just another example of thinking for yourself instead of letting the books / professors think for you.
-Joe
I would agree with you if the "struct" thingy you describe were an static inner class. If it were floating around in a package, I might have a problem with that approach. Just like anything there are edge cases, and its important to not seperate the cultural forces from the technical ones. You may trigger unwanted cultural forces: Remember junior people will see code and ape it.
-- Colonel Nikolai
You have a good point -- a static inner class would make sense if the problem domain suggested some containership that was appropriate.
However, I never agree that you shouldn't do what is fundamentally the right thing because some junior person might ape it. That is coding from fear, not courage, and Mr. Beck tells us to always have courage!
Post a Comment