This post originated from an RSS feed registered with Python Buzz
by Jarno Virtanen.
Original Post: Improper object oriented programming
Feed Title: Python owns us
Feed URL: http://sedoparking.com/search/registrar.php?domain=®istrar=sedopark
Feed Description: A weblog about Python from the view point of Jarno Virtanen.
I admit it: these "how-to-do-proper-oo-programming"
articles make me confused. Although I've been programming with classes
and tend to judge them as a nice abstraction mechanism for certain
problems, I still can't see the value of the "sophisticated object
oriented + patterns solution". It isn't obvious to me, at all, that
the last one would be the most maintainable solution. Sure, it might
be the most flexible solution —although the word "flexible" has
many interpretations too—, but adding flexibility comes with a
cost, too.
The example is relatively simple and having similar flexibility in a
larger scale program would make it huge, in lines of code, compared to
the hacker's solution. Lines of code is surely not a great measure of
maintainability, but say the hacker's solution of a larger program
would be 2000 lines of code and the sophisticated solution 8000
lines. Understanding and handling such amount of code would become a
big task as of itself.
What I would really like to see is a real experimentation of the
relative maintainability of the different approaches rather than just
proclaiming that the author's solution is more maintainable. This
would involve setting up groups that implement various maintainance
tasks for the different solutions and so forth. Fat chance seeing such
an experimentation.
In my humble opinion, the most significant hindrance to
maintainability in the real world is the lack of clarity in source
code and the lack of documentation in general. Extensive documentation
isn't always viable in software projects, but some descriptions of the
design decisions usually make the maintainance much easier. One of the
most recurring questions in my mind when inspecting someone else's
code is "why?". "Why does this code do this-and-that here?" The root
reason might not be possible to document at the time, it might just be
programmer's incompetence or ignorance. (I am of course guilty of
incompetence and ignorance too.) But descriptive documentation usually
exposes such cases as a side-effect; you get this "oh the programmer
meant to do that, but instead he did something else" feeling.
Previous Topic
