The entire point of access levels is to be able to define interfaces such that you've got a public interface how people interact with your objects, your protected interface of things that are useful to people deriving from your class that don't/shouldn't for most cases need to be changed, and then you've got your private interface/implementation that with the protected interface form the implementation of how it works.
Let me put this another way for you a class is like a miniature program it takes switches (member functions) and parameters (properties) and then it does stuff with those switches and parameters and gives you a result. With ls or grep or whatever you don't really care about how it's implemented, all you really care about is the results, same idea with a class, and so separation of the interface (public) from the implementation (protected, private) is very important to good OOP design, and again helps to increase modularity since you're relying upon an interface as opposed to an implementation. It's like relying upon the HTML standard as opposed to how IE does things.
And again yes people can get it wrong, but people can also crash cars, that doesn't mean either cars or OOP is bad. It simply means that the person writing the code or driving that car was bad. Just because Java is a shitty implementation of an OOP language doesn't mean that all OOP language implementations are bad or that the idea is innately wrong. Just because Java developers don't understand OOP and think that having those features means that they can be control freaks to limit "bad use" doesn't mean that the rest of us are like that, and in fact we're for the most part going "WTF Java? Being a megalomanical control freak is not how OOP works" and are instead simply using it for interface->implementation separation.
Now if I wanted to I could be ragging on how "functional" languages aren't, and about how functional languages create (almost) unreadable code but I don't really care enough to spend my time arguing those points as opposed to killing FUD and misunderstandings about OOP and programming.
Also, syntax and semantics are formalized in mathematical logic; this is essential to programming languages.
The main issue with going with OOP again in normal non-scripting cases essentially has to do with increasing the order of complexity. It doesn't mean going the OOP way is not the best way of going about it if you want the best design, but that it takes something trivial and makes it more complex for the purposes of being better engineered and more extensible in the long run.
Even math can be argued as being largely if not completely object oriented because you've got number objects verbing through addition, subtraction, etc other number objects, and you've got an equation object that contains number and operator objects capable of taking derivatives of itself and so on...
Last edited by Luke_Wolf; 03-05-2013 at 03:01 PM.
Just to make my point, I'll quote the preface of the book "Elements of Programming", from Alexander Stepanov. Note that I'm not claiming that he is right; I just want to express my idea through an authority in the field:
"Elements of Programming provides a different understanding of programming than is presented elsewhere. Its major premise is that practical programming, like other areas of science and engineering,must be based on a solid mathematical foundation. The book shows that algorithms implemented in a real programming language, such as C++, can operate in the most general mathematical setting. For example, the fast exponentiation algorithm is defined to work with any associative operation. Using abstract algorithms leads to efficient, reliable, secure, and economical software.The book’s value is more fundamental and, ultimately, more critical for insight into programming. To benefit fully, you will need to work through it from beginning to end, reading the code, proving the lemmas, and doing the exercises. When finished, you will see how the application of the deductive method to your programs assures that your system’s software components will work together and behave as they must."
An engineer from Adobe, who took Stepanov's course, states: “Ask a mechanical, structural, or electrical engineer how far they would get without a heavy reliance on a firm mathematical foundation, and they will tell you, ‘not far.’ Yet so-called software engineers often practice their art with little or no idea of the mathematical underpinnings of what they are doing. And then we wonder why software is notorious for being delivered late and full of bugs, while other engineers routinely deliver finished bridges, automobiles, electrical appliances, etc., on time and with only minor defects. This book sets out to redress this imbalance. Members of my advanced development team at Adobe who took the course based on the same material all benefited greatly from the time invested. It may appear as a highly technical text intended only for computer scientists, but it should be required reading for all practicing software engineers.”
What I see very clear is that, at the very least, the foundational roll of OOP is debatable.
To be blunt here we are in a world of objects with properties and methods of interaction. Our Languages and thus communications in general rely upon objects, our math relies upon objects, even mental constructs are objects.
This is fundamentally the point of OOP and why it's the foundation of programming, and why ALL languages are fundamentally object based...
The other thing is the Adobe's guy point is just bad. What a Software Engineer is doing is more or less what engineers involved with R&D are doing. The thing about bridges is this most of the fundamental work is already done for you, somebody has done it before and so there's a known way for it to be done. Remember that the first of the modern bridges broke due to resonance. Today's engineers doing that are essentially in the position of a Software Engineer who is maintaining code, which yeah it's a lot of hard work and takes quite a bit of skill and time to understand it all but fundamentally speaking they're not really doing anything new, unless they're doing R&D on new types of bridges. Writing new complex programs on the other hand takes a lot of work and design to get right, and just like those R&D engineers, things don't always work the first time or the second, or even the 10th time, but eventually things get to the point where the program moves out of R&D and into more typical engineering.
Last edited by Luke_Wolf; 03-05-2013 at 09:59 PM.
So, if language is at the core of programming, and mathematics establishes the foundations of languages, then obviously mathematics is at the core programming.
I agree that there exists a foundational aspect about thinking in terms of objects. But, as Stepanov says, saying that everything is and object is saying nothing at all; how do these objects relate? what structure governs them? This is what mathematics does best, and algebra in particular can be used to reason about programs, as is done in Stepanov's book.
By the way, some mathematical proofs are divine, and saying that "Even proofs are simply expressions and usage of language rules" is having no clue about the nature of mathematics (again, don't take this the wrong way).
What he is suggesting is not that mathematics is a mere technique to help improve code (as can be though of OOP); he says that mathematics is the foundation of programming.
I do think that you have a point when suggesting the object nature of our world but, again, to say that everything is an object hardly gives structure to programming (structure as studied in algebra). I am convinced that algebra is fundamental to programming, and that it dictates its nature.
This is analogous with the engineering happening when sending men to space: Do you think OOP is fundamental on these projects? Because this programs must not break, they use mathematics. If buildings were implemented like commercial computer programs, they'd all fall the same day.
But the fact that both math and all programming languages are logic languages means that they can of course express logic (remember what I said about certainty?), and as a result both fundamentally operate in a similar method and can use the same algorithms, in fact within limitations you can design things the same. However they are not the same.
and what Stepanov is saying amounts to hand waving there, essentially he's saying nothing at all. However Saying everything is an object sets up a fundamental understanding of the universe if you will, it sets up a basis from which you can then begin to examine the interactions and properties of these objects.. The relations if you will, and from there you can continue to build up.
Here's the thing Language requires nouns, be it math, be it english, be it C++ or some other programming language, it all requires nouns to work, and you build up with verbs, prepositions, pronouns and other constructs from there. Let's think about that sentence I brought up earlier:
What happens if we remove the nouns?Code:Sally went to the store and picked up a bunch of bright red apples.
you see how that means nothing? on the other paw if we have just the nouns:Code:went to the and picked up a bunch of bright red.
you have these nouns and you know they're somehow related but you don't know what the relations are and then you add in verbs (functions in programming)Code:Sally store apples
Well it's clear what happened, it's not pretty but okay lets add in some prepositionsCode:Sally goto store, Sally pickup apples
okay and to finally bring us full circle lets add in some adjectives (properties), linking words, and quantifiers:Code:Sally went to the store, Sally picked up apples.
Do you see how that builds up and works now?Code:Sally went to the store and picked up a bunch of bright red apples.
https://www.youtube.com/watch?v=j-zczJXSxnw , Also sending men into space is a very bad example for this. You do realize just how much trial and effort was put into sending men into space and just how many times those trials failed to launch? Here's a hint, they failed a lot of times, which is why it took so long before they were comfortable moving from just getting rockets to work to putting men in them. Even today we're still having issues which is why the Constellation program flopped... HARD.
Also in complex programs OOP makes it far less likely for a program to break because it's application of the UNIX philosophy towards programs, because what you're doing is you're encapsulating and breaking up your big program into a bunch of tiny little programs which are reusing and thus testing your code in as many ways as possibly, also this is where unit testing as a part of OOP development comes in.
Last edited by Luke_Wolf; 03-06-2013 at 12:10 AM.