|
|
|
|
|
by loup-vaillant
5865 days ago
|
|
Looking at this thread, it seems your main disagreement is about the definition of OOP. I won't provide one, mind you. But such disagreements are so widespread that we may want to stop using the term OOP altogether, and only use more narrowly defined terms. |
|
It's a definition thing, sure. But it's important to realize that there's no trickery going on here. There's a very important point.
I get this all the time, and from all aspects of software engineering. As an example, it's become quite fashionable to say something along the lines of "use-cases suck!"
However use-case analysis is just a way of thinking about system functionality. Most people, when pressed, actually mean "we hate these monstrous word templates and rigorous bullshit that people make us do and call them use cases"
To which I do not disagree. But that's confusing the application with the tool again. To insist that they are the same is to throw out huge hunks of software engineering simply because a few people got into them and made them overly-complicated and onerous to use.
Or put another way: I'm sure some folks would like to describe OOP in terms of overly-complex class diagrams, lots of wiring, un-manageable systems, yadda yadda. Some other folks would like to describe OOP in terms of small systems pragmatically created bottom-up. It can be any or all of that. OOP is actually constructing solution code in a pattern that supports encapsulation, polymorphism, information hiding, etc. The idea is a conceptual tool, a code construction pattern of thinking. The implementation can be all sorts of things. Various implementations suck to more or less degree. But that's really not important. What's important is whether this tool is useful right now, do I know how to use it, and which parts work and which parts get in the way of where I'm going.
I understand that this can sound like sophistry, but it's not.