On a related subject ...
The concept of OO is designed with the assumption that it's good to couple data together with the functions that operate on it. This is the concept of a class. The idea is that the functions in the class have a close relationship to the data, and do all the tricky logic, while the outside world doesn't have to know about the details. This is the idea of modularization, which helps make sure that changes in one part of a system have minimal effects on other parts of the system.
It all goes wrong when class boundaries are defined incorrectly, and then classes need to rely excessively on data from each other. Then instead of boundaries that protect from details, we end up with boundaries that prevent proper usage.
In order to take full advantage of OO, it is imperative to continuously rearrange class boundaries, and maintain the close relationship between data and the code that operates on it. In fact I would go as far as to say this is what distinguishes good OO code from bad OO code. By default, all OO code tends to deteriorate, or increase in entropy precisely because data goes out of alignment with the code that operates on it. This is perhaps the biggest (and very much fair) criticism of OO-haters.
What I'm trying to arrive at here, is a way to automate, or semi-automate refactoring in order to take full advantage of OO.
"In order to take full advantage of OO, it is imperative to continuously rearrange class boundaries, and maintain the close relationship between data and the code that operates on it"
ReplyDeleteBut this is an admission that OO has failed, don't you think? If a design methodology /requires/ constant tinkering with already working code, perhaps it's time to walk away.
Walk away, man! Before it's too late... discover the wonderful functional world, where nothing is imperative :-)
be well
-h-
procedural still works fine for me :)
ReplyDeletealso, this entire blog IS a compilation of OOP failures :)
@corvuscorax: Walk away, you say? What language do they make you use where you work? :) OO is here to stay, and I do not my see my way out of it professionally, so I'm trying to find better ways to work within the system.
ReplyDeleteFunctional is cool, I love it in fact. If I only had 10% of the time to spend on it that I spend on C++ and C# at work, I would probably enjoy it even more.
@waker: We can argue about procedural vs. OO, you may be right, you may be wrong, but as I said before, OO is here to stay, so I write about what can we do within the system. This is a very practical question I have to answer every day. While I can fantasize about bigger and better solutions out there (or simpler and smaller ones), none of them are applicable within at least the next year on the project at work.
ReplyDeleteyou must fight the system!
ReplyDeleteYou can easily program in the functional style using both C++ (which is stated to be a multi-paradigm language, anyway) and C# ... if you don't believe me, read the book "Real World Functional Programming" which shows you how to do the same tasks in a functional style in both C# and F#.
ReplyDeleteAnd remember, dude: functional programming is a state of mind. So, how about getting with the program? Why don't you jump on the team and come on in for the big win?
be well
-h-
Well, now we're talking. If I can do better in C++, then I'm all for the idea.
ReplyDeleteBut if you're asking me to learn Esperanto, because it has better grammar than English, and JUST MAKES MORE SENSE, maybe I'll have to think about it ;)
Well, I personally favor Volapük, but live and let live ... perhaps :-)
ReplyDelete