On 20 February 2011 23:51, tolga <kacmazto...@gmail.com> wrote:
> 21.02.2011 01:41, Richard Quadling yazmış:
>> On 20 February 2011 23:34, Richard Quadling<rquadl...@gmail.com>  wrote:
>>> On 18 February 2011 19:03, Pete Woodhead<pete.woodhea...@gmail.com>
>>>  wrote:
>>>> Hi I'm Pete Woodhead.  I'm new to the list and to PHP.  To be honest I
>>>> very
>>>> new to code writing.
>>>> Thought this would be a good way to learn good habits as well as good
>>>> code
>>>> writing.
>>>> Looking forward to learning and participating.
>>> Assume that all the data you get from the user is out to get you. It
>>> probably isn't. Most of the time. But when it does, it'll be your
>>> fault. Unless you've left the company by then.
>>> Also, poka-yoke is a great concept to learn about (thanks to a great
>>> article in php|Architect all the way back when).
>>> Richard.
>>> --
>>> Richard Quadling
>>> Twitter : EE : Zend
>>> @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY
>> http://www.phparch.com/magazine/2006-2/february/ in case anyone was
>> wondering.
> i'm interested in php about 3 maybe 4 years but i still couldnt get the
> logic of classes. it makes no sense to me. i couldnt understand whats about
> classes good at or how to use or write it. and i can say that " is 'class'
> really necessery? "

Necessary? No. They are not necessary. But they can certainly help.

I'm not an expert or a teacher but here is a short list of "features"
that I've found the most useful when it comes to using OOP techniques
over procedural or linear programming and trying to explain them to
non OOP developers.

1 - Encapsulation.

: "A benefit of encapsulation is that it can reduce system complexity,
and thus increases robustness, by allowing the developer to limit the
interdependencies between software components."

For any given program, there will be groups of functions and variables
which are either loosely associated with each other, or maybe more
tightly bound. In a procedural environment, you may need to pass the
same parameters to every function in the related group.

In its simplest form, encapsulation allows you to place the shared
variables and the methods into a closed group (a class). The class
becomes the container for all the variables and functions (or
properties and methods if you prefer). You don't need to pass around
the parameters to every function as they are already part of the

Encapsulation allows the combination of "data" and "behaviour" into
the "object". So, for example, say you want to connect to a database.
Commonly, you'll need the name of the server, a username and a
password. You may also require a database name. That would be the
"properties". The behaviour could be limited to "connect" and
"disconnect". Depending upon your preference, you may have
"isConnected" as a property which is maintained dynamically, or a
method "getConnectedState" which investigates the state of the
connection in real time. Whatever really.

The properties defined within the class can be protected from
inspection/alteration from anything outside of the class (or a
subclass). This means that the global list of all know
variables/function names has shrunk considerably for an OOP app.
Having 2 libraries of code which havbe been coded with the same
function names ... how do you know which function to call. Often the
code will complain due to a collision of names. But for variables,
maybe not. Redeclaring a variable name may be fine in your language
and not be an error.

Maybe not a great example, but OOP is about building blocks, so ...

2 - Inheritence.

http://en.wikipedia.org/wiki/Inheritance_(computer_science) :
"Inheritance is a way to compartmentalize and reuse code by creating
collections of attributes and behaviors called objects which can be
based on previously created objects."

So, having built an object which exhibits behaviour and has properties
(like things in the real world), you may often want to produce
something that is "like" the thing you created. A common approach in
procedural code is to add another variable to the mix which has to
somehow be stored and differentiated between "this" type of thing and
"that" type of thing. You may have MANY types, all requiring their own
additional data and differentiating behaviour. Complex/long switch()
or if/then/else blocks ensue.

Inheritence allows you to do this in a very simple way. A "class"
(just a collection of data and behaviour) can be "extended" to include
new properties and/or behaviour and maybe alter the behaviour, or even
obscure existing behaviour (there are issues about doing this and it
is not a trivial issue if you get it wrong).

So, for example, you've got your database connection class. Now you
need to include connecting to the database through another connection
type (say a VPN tunnel). So, you could simply add parameters
indicating the data required for VPN connectivity or you could create
a new class based upon the initial database connectivity class. This
is commonly known as subclassing.

The subclass would have all the properties and methods of the main
class (and without any need to copy them in code, that is done for you
because you "extend"-ed the base class), so all you need to do is add
the new data (properties) and functions (methods) to the new subclass.

3 - Polymorphism.

: "Subtype polymorphism, almost universally called just polymorphism
in the context of object-oriented programming, is the ability to
create a variable, a function, or an object that has more than one

This one is a little more complex. The first two features can be seen
as nothing more than a form of grouping. They are hopefully fairly
simple to understand. It is probably possible to implement both of
those features in procedural code without too much difficulty.

So, what is this third feature. I don't know of a similar technique in
procedural code, so the explantion may be awkward.

Following on from the DB connectivity example ... so you've built your
DB connectivity classes. You have a base class which does the raw DB
connectivity. You have several sub-classes dealing with making that
connectivity through additional security (VPN, firewall, dialup -
whatever). All of these options are for the purpose of one thing -
connect to a database. You now come to the part of your application
where you need to initiate the connection. Your code requires an
object that is of the appropriate type (just like you can typehint
string, integer, boolean in some languages, in PHP, you can also type
hint class types). But what type do you set? Your app allows the user
to determine which connection they want to use at run-time. How do you
hint all those different connection types?

Well, you don't. The main advantage of polymorphism is that it allows
you to pass a subclass off as the main class. So, as long as subclass
x is extended from class y, your type hint will be for class y and all
subclasses will be allowed to be passed to the method.

Hmmm. And now you can see why I'm not a teacher. I get the feature,
but I can't easily explain it.

There are MANY more features that you can use when if comes to OOP,
but, for me, these three really do make the next big leap from
procecural programming to OOP. Linear -> procedural -> OOP.

OOP is an evolution. In my opinion, AOP is the next big leap and is an
evolution of OOP. But that's another story.

Here endeth the lesson.



Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY

PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to