Took my first peek today into Object-Oriented Programming (OOP). This is something I've postponed until good-n-ready .. cuz I heard OOP's concepts can be difficult to digest, especially those introduced at the outset.
I'm currently reading the Gilmore book (among others). Jason says (.. in chapter 6, under heading labeled » Benefits of OOP):
"It is the most powerful programming model on the planet."
Uh, actually he said it's » the most powerful programming model YET DEVISED
. I substituted the phrase on the planet for dramatic effect. =)
Same thing. So you can see why this statement got me all hot-n-bothered. [ # Tho Nigel said OOP is not very different. ]
The flip-side of OOP is called 'procedural' programming. I reckon it'd be better for me to learn OOP before becoming too indoctrinated into the Procedural method. Less to unlearn this way. You know how difficult it can be sometimes to change-over to a new paradigm (way of thinking) .. once you've become comfortable with your current method. Old dogs & new tricks.
The OOP model shifts the focus away from (conceptually) a program's procedural events .. to the REAL-LIFE things the programming model represents.
This modeling-of-real-life lends itself (I've found) to making comparisons with how programming applies to REAL-LIFE itself (.. and vice versa).
Sorta meta-physical stuff .. which I won't delve into right now. But thought-provoking nonetheless, and maybe worth discussing some other time.
The focus on REAL-LIFE entities (or 'objects') tends to make programming with OOP less obscure .. than the regular procedural method .. which mimics a foreign language.
Regarding OOP being conceptually daunting .. here's a statement I had to read several times in order to grasp (.. we're still talking about the advantages of OOP):
The developer can change the implementation of the application without affecting the object user because the user's only interaction with the object is via the interface.
So no, it's not rocket science, but the going early on is pretty slow indeed. But it's also very rich, which makes it rewarding. [ # I've heavily marked-up the first few pages of this chapter, as ideas & concepts were exploding all over the place. ]
••• today's entry continues here below •••
» Classes = Characteristics + Behaviors
Objects are created from a standardized template known as a CLASS. The CLASS tells you everything about the object. The class DEFINES the object. So the two terms seem almost synonymous (on a certain level).
OOP is really all about two things (seems to me) » Characteristics & Behaviors (C+B) .. which define the CLASS (.. which in turn defines the OBJECT). They are the nouns and verbs .. to the OBJECT's sentence. Things and actions .. the actions these things do.
Take the class 'Employee' for example. It can have a characteristic of 'pay-rate'. The CLASS of 'Employee' can have different sub-classes (e.g. Clerk, Programmer, Engineer) each with its own 'characteristic' pay-rate.
In PHP, characteristics are called FIELDS, and behaviors are called METHODS (.. F&M). Okay, I can see why they chose the term 'methods,' but not sure how they came up with 'fields'.
» 
OOP's 3 Foundational Concepts
The most complicated of OOP's 3 foundational concepts is » Polymorphism .. which is probably why the book discusses it last. (I'll address it first.)
Polymorphism simply means you can implement the same (inherited) C+B differently in different classes. Poly means multiple. Morph = change the form. Able to change the form (of C+B) in multiple ways.
A Ferrari & a Volkswagen bug are, for example, two different "implementations" of the B+H for the class CAR. [ # Made up that illustration myself. =) ]
I'm just an OOP n00b, but I can't see how OOP would/could work if you were unable .. to implement the C+B differently in different classes. Programming that way would be so limited. No?
The other two foundational concepts are » Encapsulation & Inheritance. Inheritance simply means sub-classes get all the C+B of their parent classes. No great conceptual feat there. I learned about Inheritance from working with CSS. But the book points out that the OOP model places great stock in Inheritance.
Encapsulation is explained using a microwave oven. You don't have to know all the technical details of how one works in order to use it, cuz it uses a standardized 'interface'. Same with your television and car. The technically daunting parts are 'encapsulated,' so you don't see them. Each OBJECT operates independently of the others.
I believe the term 'abstraction' can be applied here, tho the book doesn't specifically use it. Either way, it seems like a method to control complexity.
The text uses simple examples that help clarify concepts, but they would take too much space to include here. I'm reading several texts concurrently .. in order to get a broader introduction to OOP's foundational concepts.
Tho it seems to me that, once you step inside the world of OOP, you're still left with standard procedural techniques to get your programming job done. No? So it's not an either/or proposition (.. either OOP or procedural.)
» An OBJECT is like a Puzzle Piece
The problem with OOP (seems to me) is that I can't give you a graphic or image of an 'OOP' .. cuz it's sorts like an idea, or a concept, which embodies a set of techniques for programming .. which defy concrete imagery.
The closest image you might associate with OOP (from what I've read) is the puzzle piece. Check out the following quote .. which lies at the heart of the Jason's discussion on the benefits of OOP:
OOP-minded developers design each part of the application so they're INDEPENDENT from the others. This enables developers to assemble components LIKE A PUZZLE .. rather than tightly lash, or couple them together. These components are called OBJECTS.
I mean, if we want to grasp Object Oriented Programming .. it would seem we first need to understand, and form a concept regarding the OBJECT. No? And for that (seems to me) the best place to start is with a puzzle piece. This is why the #1 term that comes to mind when I think of the OOP model is » MODULAR.
» 
OOP & Design Patterns | Pro's & Con's
Might be worthwhile, before we close today, to wax philosophical. OOP can be viewed as a 'design pattern' of sorts. In other words, it forces the programmer to adhere to a number of prescribed methods & formats which bring about a degree of standardized uniformity to the code.
The question naturally arises » is this good or bad? Liberating or enslaving? And of course (.. since most everything in life comes with a trade-off) the answer is » it depends.
It's good (liberating) for the n00b like me, because it prevents me from committing a whole host of errors I might otherwise make. But it's bad (enslaving) for the experienced stud-programmer .. cuz it forces them to conform to a model that might not represent the 'best' way to accomplish a certain task.
It forces them to jump thru hoops they wouldn't ordinarily jump thru. So 'best' is a relative term. You can see how the more programmers you have working on a particular project, the more valuable these design patterns become. MODx, for example, is written in OOP-based PHP.
In the end, it all depends on what you want to do. And IF you want to build something big and cool, then you'll probably need lots of programmers .. working together. And IF your team has members who are NOT expert programmers, then a design pattern starts looking mighty attractive .. even if it's not OOP, specifically.
Again, I'm brand-spanking new to OOP. My goal, initially, is to get to the place where I know enough about PHP in order to ask effective questions. If I've made any GCE's (gross conceptual errors), I'm counting on you gurus to set me straight. Danka.
Note: PHP5 is the first version that comes with a full-blown OOP feature set. Version 4 had some OOP features, but they suk'ed pretty bad. The C++ and Java programming languages also have a rich OOP feature-set. The Luke-n-Laura book says (on pg 159):
PHP's OO implementation has all the features you would expect in a fully object-oriented language.
The books I'm reading review OOP's feature-set .. dedicating a chapter or two. Note that OOP is big enough topic to warrant an entire book.
Just realized a coincidence .. the book I've been reading to the Bug lately is titled » OOPs .. about a piggy family whose house is destroyed because of spilt milk. A series of unfortunate events, you might say. It has been his favorite for weeks.
