Prev: 64 bit date in 32 bit php ??
Next: Iterating ASTs with SPL in PHP-5.3.1
From: Ashley Sheridan on 19 Jan 2010 12:44
On Tue, 2010-01-19 at 12:30 -0500, Paul M Foster wrote:

> On Tue, Jan 19, 2010 at 03:11:56PM +0000, Ben Stones wrote:
>
> > Hi,
> >
> > I've been learning about object oriented programming for the past few weeks
> > and I've understood it pretty well, but I have one question. Usually with
> > PHP scripts I make, all the functionality for a specific page is in the
> > actual PHP file, and I'd use PHP functions in a separate directory which
> > would be included in whichever PHP file needs specific functions I have
> > created. The functions would be for the specific things in my script, such
> > as validation checks, functionality that will be used/repeated a lot
> > throughout my script, etc. What I don't understand about OOP is what its
> > primary purpose is for. Do I use OOP for all the functionality of my
> > application, in separate directories, and include these specific class files
> > and call the methods to complete specific functionality needed for whatever
> > PHP file I'm working on, or is OOP used for specific functionality like I
> > would with functions? Essentially what I'm asking is what is the primary
> > purpose for OOP? Hope you understand.
>
> <opinion>
>
> OOP is a *trend* or *fad* in programming. You can create a whole
> application written almost entirely with OOP. It will usually follow the
> MVC (Model-View-Controller) paradigm. It will have a front controller
> (one page that every other page starts from) and distribute the work of
> displaying pages, validating values, and storing data across a variety
> of classes in a bunch of files. See a package called CodeIgniter for a
> good but simple example of this paradigm. Generally, an application
> written this way will load many tens of pages' worth of code before any
> byte gets to the screen.
>
> Alternatively, you can write simple OOP components for selected parts of
> your application. For example, if you're dealing with a bunch of
> customer screens, you can write an object oriented class which handles
> all the customer queries with the database.
>
> There are a variety of arguments that OOP advocates will make in favor
> of OOP. It's *supposed* to make your programming easier and faster, and
> make for easier debugging. In the real world, this may or may not be
> true. OOP does work to reduce the clutter in your namespaces-- the
> names of methods within classes are hidden from the rest of your
> namespace, unlike global functions. It also relieves you from having to
> pass a lot of parameters to each routine you call; you can store a lot
> of properties in the class, and they are shared with the methods in the
> class.
>
> One of the more serious problems I've seen with OOP lies with classes
> which have dependencies on other classes. It's like walking a minefield
> sometimes, ensuring that this class gets instantiated before that one,
> which depends on it. You can write an incredibly complicated automatic
> instantiator which instantiates classes and ensures they fire in the
> proper order (I have), but it seems kind of silly when you could just as
> easily write external functions which perform similar functions.
>
> </opinion>
>
> Bottom line is, study OOP (look it up in wikipedia.org), and if you
> think its advantages are worth your effort to learn the new paradigm, go
> with it. But ignore the hype (and there's a lot of it). Do what works
> for you.
>
> <suit status=on type=flame-retardant>
>
> Paul
>
> --
> Paul M. Foster
>


I wouldn't call OOP a fad really, as that suggest a silly short-term
trend, but you do bring up a good point about class dependency problems.
If dependencies are causing that sort of level of problem, then it might
be worth re-making part of the wheel (after all, you wouldn't see wooden
cart wheels on a Ferrari, would you?!)

I've seen plenty of sites use no OOP at all, but I think once a system
gets beyond a certain size, it does make more sense to use OOP, just to
avoid running into problems where you have so many functions performing
so many tasks but becoming a nightmare to maintain.

Oh, and your flame suit failed because you forgot the quotation marks
around the attribute values, and you didn't close the tag :p

Thanks,
Ash
http://www.ashleysheridan.co.uk


From: Paul M Foster on 19 Jan 2010 13:01
On Tue, Jan 19, 2010 at 05:44:56PM +0000, Ashley Sheridan wrote:

<snip>

>
> Oh, and your flame suit failed because you forgot the quotation marks around
> the attribute values, and you didn't close the tag :p

Dang! I *thought* it felt awfully warm in here.

Paul

--
Paul M. Foster
From: Robert Cummings on 19 Jan 2010 13:12
Ashley Sheridan wrote:
> On Tue, 2010-01-19 at 12:30 -0500, Paul M Foster wrote:
>
>> On Tue, Jan 19, 2010 at 03:11:56PM +0000, Ben Stones wrote:
>>
>>> Hi,
>>>
>>> I've been learning about object oriented programming for the past few weeks
>>> and I've understood it pretty well, but I have one question. Usually with
>>> PHP scripts I make, all the functionality for a specific page is in the
>>> actual PHP file, and I'd use PHP functions in a separate directory which
>>> would be included in whichever PHP file needs specific functions I have
>>> created. The functions would be for the specific things in my script, such
>>> as validation checks, functionality that will be used/repeated a lot
>>> throughout my script, etc. What I don't understand about OOP is what its
>>> primary purpose is for. Do I use OOP for all the functionality of my
>>> application, in separate directories, and include these specific class files
>>> and call the methods to complete specific functionality needed for whatever
>>> PHP file I'm working on, or is OOP used for specific functionality like I
>>> would with functions? Essentially what I'm asking is what is the primary
>>> purpose for OOP? Hope you understand.
>> <opinion>
>>
>> OOP is a *trend* or *fad* in programming. You can create a whole
>> application written almost entirely with OOP. It will usually follow the
>> MVC (Model-View-Controller) paradigm. It will have a front controller
>> (one page that every other page starts from) and distribute the work of
>> displaying pages, validating values, and storing data across a variety
>> of classes in a bunch of files. See a package called CodeIgniter for a
>> good but simple example of this paradigm. Generally, an application
>> written this way will load many tens of pages' worth of code before any
>> byte gets to the screen.
>>
>> Alternatively, you can write simple OOP components for selected parts of
>> your application. For example, if you're dealing with a bunch of
>> customer screens, you can write an object oriented class which handles
>> all the customer queries with the database.
>>
>> There are a variety of arguments that OOP advocates will make in favor
>> of OOP. It's *supposed* to make your programming easier and faster, and
>> make for easier debugging. In the real world, this may or may not be
>> true. OOP does work to reduce the clutter in your namespaces-- the
>> names of methods within classes are hidden from the rest of your
>> namespace, unlike global functions. It also relieves you from having to
>> pass a lot of parameters to each routine you call; you can store a lot
>> of properties in the class, and they are shared with the methods in the
>> class.
>>
>> One of the more serious problems I've seen with OOP lies with classes
>> which have dependencies on other classes. It's like walking a minefield
>> sometimes, ensuring that this class gets instantiated before that one,
>> which depends on it. You can write an incredibly complicated automatic
>> instantiator which instantiates classes and ensures they fire in the
>> proper order (I have), but it seems kind of silly when you could just as
>> easily write external functions which perform similar functions.
>>
>> </opinion>
>>
>> Bottom line is, study OOP (look it up in wikipedia.org), and if you
>> think its advantages are worth your effort to learn the new paradigm, go
>> with it. But ignore the hype (and there's a lot of it). Do what works
>> for you.
>>
>> <suit status=on type=flame-retardant>
>>
>> Paul
>>
>> --
>> Paul M. Foster
>>
>
>
> I wouldn't call OOP a fad really, as that suggest a silly short-term
> trend, but you do bring up a good point about class dependency problems.
> If dependencies are causing that sort of level of problem, then it might
> be worth re-making part of the wheel (after all, you wouldn't see wooden
> cart wheels on a Ferrari, would you?!)
>
> I've seen plenty of sites use no OOP at all, but I think once a system
> gets beyond a certain size, it does make more sense to use OOP, just to
> avoid running into problems where you have so many functions performing
> so many tasks but becoming a nightmare to maintain.

I would have to agree that OOP is not a fad, perhaps over-hyped at
times, but definitely not a fad. The argument about class dependencies
is an invalid argument since functions will also have dependencies on
other functions from other libraries, quite likely located in multiple
source files. In fact, you've argued an advantage for OOP in the context
of PHP since autoload can be used to mitigate this issue for classes,
but not for functions. Another advantage of OOP that is difficult to
provide via the procedural paradigm is polymorphism.

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
From: Paul M Foster on 19 Jan 2010 14:44
On Tue, Jan 19, 2010 at 01:12:49PM -0500, Robert Cummings wrote:

<snip>

>
> I would have to agree that OOP is not a fad, perhaps over-hyped at
> times, but definitely not a fad. The argument about class dependencies
> is an invalid argument since functions will also have dependencies on
> other functions from other libraries, quite likely located in multiple
> source files.

Yes, functions can have dependencies as well, but you simply call the
function you need from within another function. It's been done for
decades in C and any number of other languages. Anyone who's ever
programmed in C (or comparable language) is familiar with having to do
"includes" at the beginning of source files and simply calling functions
now visible or now linked. This practice is frowned upon in OOP, or
"dependency injection" wouldn't have been written about so much.

> In fact, you've argued an advantage for OOP in the context
> of PHP since autoload can be used to mitigate this issue for classes,
> but not for functions.

Autoloading doesn't mitigate class interdependency unless you build an
autoload function which handles dependency injection transparently.
Again, a complex proposition.

> Another advantage of OOP that is difficult to
> provide via the procedural paradigm is polymorphism.

Agreed. Though the advantages of polymorphism are questionable,
depending on your viewpoint.

Paul

--
Paul M. Foster
From: "Jay Blanchard" on 20 Jan 2010 07:47
[snip]
> Another advantage of OOP that is difficult to
> provide via the procedural paradigm is polymorphism.

Agreed. Though the advantages of polymorphism are questionable,
depending on your viewpoint.
[/snip]

In a loosely typed language like PHP that advantages of polymorphism far
outweigh any potential disadvantages, especially where virtual functions
are concerned.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: 64 bit date in 32 bit php ??
Next: Iterating ASTs with SPL in PHP-5.3.1