> OO was "discovered" when two guys who were using a block > structured language to write a simulation engine played > around with moving the stack frame for a block to the > heap, thus making the blocks long-lived. Voila: objects!
eh?! That isn't how it is surely?
You must have seen assembler before. Consider strlen, strnlen, strcat, etc. In assembler you write a macro to peel the arguments out of your current instructions, jump to label z, return, etc. now you have fifteen string functions, all labeled, you have code code code jump str_1: jmp str_2 etc. and you realize, hey! I have to do all this code code code stuff every time I need the length of string x, so you hock up some more macros...Then hey! What if I just use a table of string start addresses, name them, use them as a base pointer for a function call and say lodx @mystring #strlen?
Then! Hey ! you get fancy cause you've got the same functions trying to add fifteen bytes, fifteen ints etc.. and they're all the same if you can name the base pointer for the instructions, the offset into the specific call, the base pointer for the start of the strings table, and the offset into the strings table for a specific table. And then you Hey! try it in C too. Same deal, now you just have a ton of typedef and function pointers, same problems too! Bad names!! Bad syntax.
That is when you come about to object based languages.
So now the problem is, "How do I teach this really complicated stuff to some new guy?"
Hey! You use bad real-world metaphors that confuse the hell out of people!!
So, I would say that the guy who said, "Object names should..." be intuitive to remember and provide a strong correlation between your assumptions about the code and how it actually works, got it right. Just like the guy who made toScreen, read from a file, probably didn't, even if the code rocked.
So maybe they should have said, "Class syntax that has nomenclature based on existing, real-world paradigms, will be easy to understand and more intuitive to use."
I enjoy Robert C. Martin posts because, among other things, he touches sensible aspects of software development in the trenches, aspects many of us have experienced or witnessed as an abuse within projects where customers gain their opinion of our industry.
In this case, a classical abuse of object orientation: Modeling the real world
From time to time, I hear someone saying that object orientation is about modeling the real world. I remember repeating this very same idea in my first year of experience with objects, it feels very good after all.
The phrase conveys good intentions, and depending of your database design experience perhaps you wont find something wrong with it.
The good intention in that phrase is that you should design your software with expressiveness, close to the application domain concepts and business rules.
The bad in the phrase is that the goodness in the previous paragraph gets buried in a silly practice that doesnt take-off from verbs to methods and nouns to class types.
Bottom line, modeling the real world is one of the most ambiguous and vague phrases I have heard, it is almost equal to say nothing at all. What exactly is the real world? There are possible answers as the number of human beings on the face of the earth.
Do you see the harm?
Most object design methods consider physical, logical, static, dynamic and functional aspects in software design; modeling the real world simply ignores those aspects of practical design.
The harm in modeling the real world often consists of an amputation of very important design properties like time and space efficiency, management of dependencies, economy of expression and scalability.
Flat View: This topic has 31 replies
on 3 pages
[
«
|
123
]
Previous Topic
