| OOP have strong stuff behind, strong enough to say it a fundamental practice of computing, specifically of the software engineering (And someone can have opinions on what computing is and if software eng. is part of it, but lets say it could be) After reading all way down it seems that you see OOP as a simplifier tool that make code easier to understand as you say in the very bottom paragraph: "That's too bad, because it makes it harder to identify the cases where an object-oriented style truly results in an overall simplicity and ease of understanding. " And also your argument of seeing OOP as just making abstractions for standard types. And yeah objects represents information relaying on the standard types the underlaying language provide but the fundamental stuff is not there, actually the standard types relay on the underlying machine, SLA, etc... So they all are just "repurposing of what's already there". So my point here is that the same arguments can be applied to any upper abstraction we made to "make stuff simpler". But as far as I can see what is behind any of this abstractions or frameworks are the fundamental concepts of reuse, coupling and cohesion. And here is really my point with this replica, the discussion about something being fundamental or not on the computing field, besides than it appears to be a subjective matter, should be in terms of this 3 core concepts and the way the "tool" under discussion makes easier to achieve each one as needed. Of course there is a different tool for different works and OOP could be a lot of overhead to solve some kind of problems (Technically talking because OOP is more than just defining bunch of data and functions together). But if the discussion is about computing and specifically to software engineering where reuse is critical, let me say that the way OOP faces the 3 core concepts of software engineering works very well if your problem space can handle the overhead and most of our "Engineering problems" and restrictions can handle that for sure IMO. More code is not necessarily a bad signal, not if you are getting real benefits from it, and again its not just simplicity to go and read the code its simplicity modeling your problem so you can reuse your low coupled and high cohesive abstract datatypes. I have posted this replica using the cool replica.la service ;) http://www.replica.la/discussions/37 |