<p><pre><code> He [my father] taught me: "See that bird? It’s a Spencer's
warbler." (I knew he didn't know the real name.)
"Well, in Italian it's Chutto Lapittitda. In
Portuguese, it is Bom Da Peida. ... You can know the
name of the bird in all the languages of the world,
but when you're finished, you'll know nothing
whatsoever about the world. You'll know about the
humans in different places, and what they call the
bird. So let's look at the bird and see what it is
doing -- that's what counts." I learned very early
from my father the difference between knowing the
name of something and knowing something.”
</code></pre>
—Richard Feynman
The bit about these kinds of articles that always nags at me is the assumption that different programming paradigms are somehow mutually exclusive. Essays talk as if object-oriented code cannot also be functional, or code isn't procedural if it involves classes, or whatever.<p>In some cases that might be true - declarative programming and procedural programming, for example, are diametric opposites in many respects. But others can be quite comfortable bedfellows. In particular, object-oriented programming and its older cousin modular programming tend to play quite nicely with other paradigms. Consider CLOS or Objective-C.<p>And even when they're opposed to each other that really just means you're limited in how you can mix them on a per-line basis. You can still write a multi-paradigm language that lets you support features from different styles.<p>Consider C#, which supports object-oriented, procedural, functional, and declarative programming (with the last admittedly being somewhat constrained), and where it's standard practice to use elements of each style all within a single short procedure. Sometimes elements of different styles end up depending intimately on each other. For example, to provide optimal support for (declarative) query expressions, one will probably need to implement the (object-oriented) IQueryable interface, and many of the methods in that interface are expected to take (functional) anonymous procedures as arguments and/or are used to build up (functional) monads representing the query that's being declared, which are in turn represented as (object-oriented) instances of classes that implement specific interfaces.
No, please. OOP does not have a monopoly on abstraction, encapsulation, modularity, etc. If you are focused on "state transformations and encapsulated abstractions", you're not necessarily writing OOP.
Even without OOP you're carrying state information one way or another. This is a confusing article because his OOP examples are procedural, and his procedural examples carry state in a global object.
Procedural has a static state of flow working from the program controling the data and OOP has a lose state of flow working with the data controlling the program. Would that be a easier true definition?<p>Another way to look at this is if you have say a physical button that the user can toggle on or off and it is lit up by code. Doing this is processed by procedural code then the code will know what state the button is and if any processing limitations will be slow in processing if the button is on or off as could be indicated by slow transition to respond to the light going on or off.<p>Now using OOP code the code that controls the light being on or off is would in general isolated from the processing of the state of the button and can lead to the the button showing on with the light on yet the processing code still thinking it is off. IE the code has no fixed static processing path and as such can lose state of if the button is on or off. This can lead to the button being off and the underliying code thinking it is on as they desync. Sorry if not the best explanation but is based upon a example I've seen in real life. The example was a phone busy/not busy button and the lovely C++ object oriented code got into a kefufle thinking the butotn was on when it was not after the operator had played track and feild on the button tapping away at it real fast out of bordem. The next result was the call processing system thought the phone was not busy when it was and tried to route a call which it was unable to do and the upshot was the entire phone system crashed.<p>OOP has it's uses, but it also has it's downsides, like all approaches it is the right tool for the job. Just that error handerling in OOP can get more complex than boring old procedural code which is alot easier to deal with, when it comes to exceptions as the processing state is static.<p>Another way to look at it is physical gears - procedural code is a fixed gear and OOP is a gear cog that can change in size and whilst you will see the end result you have no idea what size the dynamic OOP cog is.<p>Realy can be a hard one to explain without examples and it does lack a classic Hello World example.
I disagree with this somewhat. The biggest gain for large pieces of software from OOP is encapsulation, and in that regard writing loosely-coupled procedural code within classes will provide you will proper encapsulation.<p>You can't get away from writing procedural code completely, because chances are you're writing a <i>procedure</i>, so even if you're thinking about state transforms rather than a list of actions to take, you're still writing procedurally.
>> The first sentence says that you must use object data structures to write OOP.<p>Actually I don't think it does. It says that: "objects are data structures consisting of data fields and methods together with their interactions". There is no obligation.<p>True it would be easier implemented in a language provided data-structure. But if you were crazy enough you could place the data-structure all in global variables and try to tie them up using reflection.
Maybe oversimplified, but, these being the 5 programming paradigms listed in Wikipedia:<p>Aspect-oriented (? not an expert on this)<p>Imperative/procedural (most work is done by statements)<p>Functional (most work is done by functions)<p>Logic (most work is done by declarations)<p>Object Oriented (most work is done by objects)
Obligatory <a href="http://www.paulgraham.com/reesoo.html" rel="nofollow">http://www.paulgraham.com/reesoo.html</a> -<p>OOP is not well defined. State your definition (use the above link as a legend) before arguing about what OOP is and isn't, and there will be much less miscommunication.