Object Oriented Programming question

--00504502d372069778047d85e413
Content-Type: text/plain; charset=ISO-8859-1

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.

Thanks,

--00504502d372069778047d85e413--

RE: Object Oriented Programming question

From: Ben Stones

> 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.

OOP is a way of looking at a problem and map it into code. Some problems
will fit into it, some don't. Some people can look at problems and see
objects and some can't. But in most cases, it is not easy to take an
existing procedural program and re-map it into objects. It would be
easier to start over from the specification and write it from scratch in
the object model.

If you have been doing procedural programming, don't worry if you don't
figure it out right away. It is not an easy transition to make. Many of
us with decades of programming behind us will never be able to make that
switch. Our brains are too tightly locked into the previous thought
patterns.

Bob McConnell

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

Re: Object Oriented Programming question

--=-DJbPtDGYupM1Wuz9Fbib
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

On Tue, 2010-01-19 at 15:11 +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.
>
> Thanks,


There are a few advantages by going the OOP route with PHP.

Firstly, you can bring together what would normally be in several
variables into one object, making it easier to work with, instead of
having to use various global variables to hold all the information.
Also, you can instantiate more than one object of the same type, and it
is a lot easier to work with than global variables. For some complex
cases, you could only manage this with a huge global array, which would
become unwieldy if made too large.

Secondly, object allow inheritance. So, if you create an object class,
you could use that as a basis for another more complex object by
building upon it with inheritance. You can also use other classes as a
basis for a more complex one of your own. Pear does this quite a lot.

Lastly, with OOP, you can create functions that can only be called from
within your object. These methods allow you to create functions that
will only ever be used by your classes, and won't accidentally be called
from anywhere else in your scripts.

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



--=-DJbPtDGYupM1Wuz9Fbib--

Re: Object Oriented Programming question

Ben,
I use a combination of procedural and OOP in my scripts. It =
depends on my needs. As an example, I use OOP for gathering order =
information. I created a class which gathers all the order information =
allowing me to easily access any piece of data in the order. I could do =
this with a bunch of individual functions but it's easier and more =
logical to group them all together in a single class. When I first =
started working with classes, I used them sparingly. Now I find myself =
using them more and more.

Take care,
Floyd

On Jan 19, 2010, at 10:11 AM, Ben Stones wrote:

> Hi,
>=20
> 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.
>=20
> Thanks,


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

Re: Object Oriented Programming question

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.



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.



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.



Paul

--
Paul M. Foster

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

Re: Object Oriented Programming question

--=-okY5I+oUen7nMQ2D8gJU
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

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.
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> 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



--=-okY5I+oUen7nMQ2D8gJU--

Re: Object Oriented Programming question

On Tue, Jan 19, 2010 at 05:44:56PM +0000, Ashley Sheridan wrote:



>
> 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

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

Re: Object Oriented Programming question

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.
>>
>>
>> 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.
>>
>>
>>
>> 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.
>>
>>
>>
>> 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

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

Re: Object Oriented Programming question

On Tue, Jan 19, 2010 at 01:12:49PM -0500, Robert Cummings wrote:



>
> 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

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

RE: Object Oriented Programming question

[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.=20

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

RE: Object Oriented Programming question

At 10:26 AM -0500 1/19/10, Bob McConnell wrote:
>Some problems will fit into it, some don't.

I teach OOP thinking at the local college and haven't run into a
problem that doesn't fit. For example, in my last class I had a woman
who wanted to pick out a blue dress for her upcoming wedding
anniversary. The class worked out the problem with a OOP solution.

----

>Some people can look at problems and see objects and some can't.

That's for certain -- but in time just about everyone can understand
the basic concepts of OOP.

----

>But in most cases, it is not easy to take an
>existing procedural program and re-map it into objects. It would be
>easier to start over from the specification and write it from scratch in
>the object model.

I agree with that because part of OOP is understanding/defining the
problem through an object oriented perspective -- it's a paradigm
shift in thinking.

However, a programmer who is good in procedural also understands
problem solving. OOP and Procedural are just two different approaches
and each brings it's own set of tools/problems to the table.

---

>If you have been doing procedural programming, don't worry if you don't
>figure it out right away. It is not an easy transition to make. Many of
>us with decades of programming behind us will never be able to make that
>switch. Our brains are too tightly locked into the previous thought
>patterns.
>
>Bob McConnell

While I teach OOP, I don't write any OOP for clients. My charge is to
do things quickly and OOP requires a considerable amount of analysis
before creating a solution. In most cases, I don't have the time.
Besides, I'm more of an agile programmer and that doesn't lend itself
well to OOP, IMO.

Also IMO, one can argue the advantages that OOP and Design Patterns
bring to the table over procedural, but after all is said and done,
if you know your stuff in procedural, OOP is not going to provide you
with much that you don't already have.

Cheers,

tedd

--
-------
http://sperling.com http://ancientstones.com http://earthstones.com

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

Re: Object Oriented Programming question

On Wed, Jan 20, 2010 at 06:47:04AM -0600, Jay Blanchard wrote:

> [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.

My viewpoint may be jaundiced from having programmed in C++, but the
polymorphism of PHP seems a little crippled by comparison.

Paul

--
Paul M. Foster

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

RE: Object Oriented Programming question

[snip]
My viewpoint may be jaundiced from having programmed in C++, but the
polymorphism of PHP seems a little crippled by comparison.
[/snip]

I wholeheartedly agree, but I figured out how to work with it in PHP to
my advantage and the advantage of my team. It'll get better...=20

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

Re: Object Oriented Programming question

Jay Blanchard wrote:
> [snip]
> My viewpoint may be jaundiced from having programmed in C++, but the
> polymorphism of PHP seems a little crippled by comparison.
> [/snip]
>
> I wholeheartedly agree, but I figured out how to work with it in PHP to
> my advantage and the advantage of my team. It'll get better...

Certainly it is lacking compared to C++, but it's difficult to get that
kind of functionality from a loosely typed language.

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP

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

Re: Object Oriented Programming question

2010/1/20 tedd :
> Also IMO, one can argue the advantages that OOP and Design Patterns bring to
> the table over procedural, but after all is said and done, if you know your
> stuff in procedural, OOP is not going to provide you with much that you
> don't already have.

You also have to consider that whilst PHP provides all the fancy
clever OOP facilities, it is written in C, not C++. So, as you say, if
you know your stuff ...

--
-----
Richard Quadling
"Standing on the shoulders of some very clever giants!"
EE : http://www.experts-exchange.com/M_248814.html
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
ZOPA : http://uk.zopa.com/member/RQuadling

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

Re: Object Oriented Programming question

tedd wrote on 20/01/2010 16:11:
> At 10:26 AM -0500 1/19/10, Bob McConnell wrote:
>> Some problems will fit into it, some don't.
>
> I teach OOP thinking at the local college and haven't run into a problem
> that doesn't fit. For example, in my last class I had a woman who wanted
> to pick out a blue dress for her upcoming wedding anniversary. The class
> worked out the problem with a OOP solution.

Don't forget to throw an exception if another woman shows up in the same
dress and color at the wedding! That would make you OOPD crash totally! ;-)

--
Kind regards
Kim Emax - masterminds.dk

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

Re: Object Oriented Programming question

On Wed, Jan 20, 2010 at 10:11:18AM -0500, tedd wrote:



>
> While I teach OOP, I don't write any OOP for clients. My charge is to
> do things quickly and OOP requires a considerable amount of analysis
> before creating a solution. In most cases, I don't have the time.
> Besides, I'm more of an agile programmer and that doesn't lend itself
> well to OOP, IMO.

This is a fascinating viewpoint. It's almost a sideways condemnation of
OOP: "It takes too long to write OOP for customers". (I know that's not
how you meant it.) But I have to agree, with one proviso. I tend to
write mostly procedural for clients because of time constraints. But I
believe part of the reason I do this is because I haven't built generic
OO components ahead of time which lend themselves to being used on
client sites. If I had spent the considerable time to build OO
components which were usable in this context, I'd be happy to use them.
OTOH, MVC (OOP on steroids) is just beyond reasonable in most cases for
client sites.

I will also echo that it takes a lot of time/work to correctly build OO
components, compared to straight functions or function libraries.

Paul

--
Paul M. Foster

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

RE: Object Oriented Programming question

From: tedd

> At 10:26 AM -0500 1/19/10, Bob McConnell wrote:
>> Some problems will fit into it, some don't.
>=20
> I teach OOP thinking at the local college and haven't run into a=20
> problem that doesn't fit. For example, in my last class I had a woman=20
> who wanted to pick out a blue dress for her upcoming wedding=20
> anniversary. The class worked out the problem with a OOP solution.

Hi Tedd,

Here's one you can think about. I have a box, purchased off the shelf,
with multiple serial ports and an Ethernet port. It contains a 68EN383
CPU with expandable flash and RAM. The firmware includes a simple driver
application to create extended serial ports for MS-Windows, but allows
it to be replaced with a custom application. The included SDK consists
of the gcc cross-compiler and libraries with a Xinu kernel and default
drivers for a variety of standard protocols.

I need to build a communications node replacing the default drivers with
custom handlers for a variety of devices. It must connect to a server
which will send it configuration messages telling it what hardware and
protocols will be connected to each port. The Xinu package includes
Posix threads.

In the past 23 years I have solved this problem six times with five
different pieces of hardware. But I still don't see how to apply OOP to
it.

> ----
>=20
>> Some people can look at problems and see objects and some can't.
>=20
> That's for certain -- but in time just about everyone can understand=20
> the basic concepts of OOP.

Understanding basic concepts and understanding how to map them on to
real problems are two entirely different skill sets. I understand the
concepts, they just don't make any sense to me. All of the definitions
are backwards from the way I learned to evaluate problems. I feel like a
carpenter trying to figure out how to use a plumber's toolbox. There are
some things in there I think I recognize, but most of it is entirely
foreign to me.

Cheers,

Bob McConnell

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

Re: Object Oriented Programming question

Hi Bob,

[Couldn't resist jumping into this topic :)]

Even if you look at traditional unix (or similar) kernel internals,
although they tend to use functional paradigms, they do have a
OOP-like flavor. Example:

Everything in a unix system is a 'file' (well not really with
networking logic, but it is one of the most important abstractions).
There is a notion of a 'abstract' base class 'file', and then there
are different 'types' of files - regular, directory, devices etc... So
you 'instantiate' a specific 'concrete' object when dealing with a
specific file. What are the methods that apply to all files? There is
open(), close(), read(), write(), ioctl() etc... Not all methods are
valid for certain kinds of files - e.g. usually you don't write() to a
keyboard device.

In unix and C, the OOP is modeled using structs (to store various
attributes, or data members), and each struct tends to have
'pointer-to-functions' (listed above in case of files) to actual
implementation on how to deal with such objects in the system.

In fact the device-driver framework in unix can be thought of as an
excellent example of polymorphism where a table stores all the
specific functions that operate on the device.

Grouping data and its associated operations is one of the hallmarks of
OOP. In C, there is no *direct* support to express such groupings
where as in C++ (and other OOP languages), there is direct support via
notion of 'classes' to express such relationships.

I would recommend this book: 'The design and evolution of C++' by
Bjarne Stroustrup where such topics are discussed more in depth.

Hope this helps.

Ravi




On Wed, Jan 20, 2010 at 8:31 AM, Bob McConnell wrote:
> From: tedd
>
>> At 10:26 AM -0500 1/19/10, Bob McConnell wrote:
>>> Some problems will fit into it, some don't.
>>
>> I teach OOP thinking at the local college and haven't run into a
>> problem that doesn't fit. For example, in my last class I had a woman
>> who wanted to pick out a blue dress for her upcoming wedding
>> anniversary. The class worked out the problem with a OOP solution.
>
> Hi Tedd,
>
> Here's one you can think about. I have a box, purchased off the shelf,
> with multiple serial ports and an Ethernet port. It contains a 68EN383
> CPU with expandable flash and RAM. The firmware includes a simple driver
> application to create extended serial ports for MS-Windows, but allows
> it to be replaced with a custom application. The included SDK consists
> of the gcc cross-compiler and libraries with a Xinu kernel and default
> drivers for a variety of standard protocols.
>
> I need to build a communications node replacing the default drivers with
> custom handlers for a variety of devices. It must connect to a server
> which will send it configuration messages telling it what hardware and
> protocols will be connected to each port. The Xinu package includes
> Posix threads.
>
> In the past 23 years I have solved this problem six times with five
> different pieces of hardware. But I still don't see how to apply OOP to
> it.
>
>> ----
>>
>>> Some people can look at problems and see objects and some can't.
>>
>> That's for certain -- but in time just about everyone can understand
>> the basic concepts of OOP.
>
> Understanding basic concepts and understanding how to map them on to
> real problems are two entirely different skill sets. I understand the
> concepts, they just don't make any sense to me. All of the definitions
> are backwards from the way I learned to evaluate problems. I feel like a
> carpenter trying to figure out how to use a plumber's toolbox. There are
> some things in there I think I recognize, but most of it is entirely
> foreign to me.
>
> Cheers,
>
> Bob McConnell
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

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

RE: Object Oriented Programming question

At 11:31 AM -0500 1/20/10, Bob McConnell wrote:
>From: tedd
>
>> At 10:26 AM -0500 1/19/10, Bob McConnell wrote:
>>> Some problems will fit into it, some don't.
>>
>> I teach OOP thinking at the local college and haven't run into a
>> problem that doesn't fit. For example, in my last class I had a woman
>> who wanted to pick out a blue dress for her upcoming wedding
>> anniversary. The class worked out the problem with a OOP solution.
>
>Hi Tedd,
>
>Here's one you can think about. I have a box, purchased off the shelf,
>with multiple serial ports and an Ethernet port. It contains a 68EN383
>CPU with expandable flash and RAM. The firmware includes a simple driver
>application to create extended serial ports for MS-Windows, but allows
>it to be replaced with a custom application. The included SDK consists
>of the gcc cross-compiler and libraries with a Xinu kernel and default
>drivers for a variety of standard protocols.
>
>I need to build a communications node replacing the default drivers with
>custom handlers for a variety of devices. It must connect to a server
>which will send it configuration messages telling it what hardware and
>protocols will be connected to each port. The Xinu package includes
>Posix threads.
>
>In the past 23 years I have solved this problem six times with five
>different pieces of hardware. But I still don't see how to apply OOP to
>it.
>
>> ----
>>
>>> Some people can look at problems and see objects and some can't.
>>
>> That's for certain -- but in time just about everyone can understand
>> the basic concepts of OOP.
>
>Understanding basic concepts and understanding how to map them on to
>real problems are two entirely different skill sets. I understand the
>concepts, they just don't make any sense to me. All of the definitions
>are backwards from the way I learned to evaluate problems. I feel like a
>carpenter trying to figure out how to use a plumber's toolbox. There are
>some things in there I think I recognize, but most of it is entirely
>foreign to me.
>
>Cheers,
>
>Bob McConnell

Bob:

I am sure that you have all the tools and you solve problems in
similar fashion -- it's only the jargon just hasn't made sense to you
yet -- but it will. Six months from now , or a year, or whenever --
you'll have your "Is that what you're talking about? Hell, I've been
doing that for years- -- but not quite that way" moment.

The problem is to break the problem into smaller and smaller parts
that can be solved without requiring any alteration by the outside
world. In other words, make the communication between the parts as
simple and as independent as possible. They call encapsulation (data
hiding) and loose coupling. From that, you can assemble the parts as
you like.

I don't know your specific problem, but it reminds of a problem I had
several years ago when I was writing software for plotters (Apple,
HP, IT, Houston, etc.). Each plotter had it's own internal commands
for pen-up/down, move x,y, and so on. While this was before OOP, the
solution was to create a universal plotter language and then write
translators for each specific plotter. That way, I could use my
universal plotter language to do plotter things without ever thinking
about any specific plotter.

That way when another plotter came along, I would simply write a
routine that would control that plotter's basic pen-up/down and move
x,y commands in my plotter language. The technique worked very well.
IMO, it was that type of abstraction that launched OOP.

The problem you present is one where I would try to find the
commonality between all the components and reduce those down to the
simplest aspects of communication and responsibility.

I know that sounds like a bunch of OOP-speak, but problems well
defined will expose their solutions.

Leonardo da Vinci was once asked about his marble carvings -- he
replied (not a direct quote) that he just carved away everything that
wasn't part of the statue. He was liberating the statue from the
marble. Similarly, we liberate the solution from the problem.

Cheers,

tedd

--
-------
http://sperling.com http://ancientstones.com http://earthstones.com

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

Re: Object Oriented Programming question

At 11:18 AM -0500 1/20/10, Paul M Foster wrote:
>On Wed, Jan 20, 2010 at 10:11:18AM -0500, tedd wrote:
>
>
>
>>
>> While I teach OOP, I don't write any OOP for clients. My charge is to
>> do things quickly and OOP requires a considerable amount of analysis
>> before creating a solution. In most cases, I don't have the time.
>> Besides, I'm more of an agile programmer and that doesn't lend itself
>> well to OOP, IMO.
>
>This is a fascinating viewpoint. It's almost a sideways condemnation of
>OOP: "It takes too long to write OOP for customers". (I know that's not
>how you meant it.) But I have to agree, with one proviso. I tend to
>write mostly procedural for clients because of time constraints. But I
>believe part of the reason I do this is because I haven't built generic
>OO components ahead of time which lend themselves to being used on
>client sites. If I had spent the considerable time to build OO
>components which were usable in this context, I'd be happy to use them.
>OTOH, MVC (OOP on steroids) is just beyond reasonable in most cases for
>client sites.
>
>I will also echo that it takes a lot of time/work to correctly build OO
>components, compared to straight functions or function libraries.
>
>Paul

Paul :

My view of the world is limited to what I do, but to me it's almost a
philosophical issue -- what constitutes reusable code and what
doesn't?

I've looked over many OOP routines that provided no useful purpose to
me because their application was so specific that I could not use it
for the problem I was solving. Programmers put these things together
to be totally self contained, but failed to see that their solution
only fits their problem. As such, for me to use their code I would
have to disassemble it and then reassemble it for my own use -- in
many cases taking it back to procedural.

OOP makes sense if you and your client can agree on a final solution
before any code is written. My experience with clients is that first
I usually have to educate them as to what a web page is and then work
to solve their specific problem, which in many cases they can't even
identify. They can only say what they want.

It's not their fault that they don't know what their problem is for
they haven't been trained in problem identification. In fact, I would
prefer an ignorant client over one who thinks they know how to solve
the problem. I often tell clients to just tell me what you want and
I'll work out the solution.

I remember a sign that hung in an old gas station when I was a kid, which read:

Labor:

$10.00 per hour
$15.00 per hour, if you watch.
$20.00 per hour, if you help.

In any event, when dealing with clients who don't fully realize what
their problems are NOR fully appreciate what their needs are, I don't
have the time to work out every detail beforehand so that I can
create an OOP solution before writing the code.

I might also add that writing an OOP solution before identifying the
problem is an effort that will need to be redone later. Not all
solutions should be written in OOP.

Also, just because you can write OOP does not mean that what you
write is better than what the procedural counterpart would be. It
just means that you used OOP to solve the problem.

So, to get back to your statement that I don't have time to write in
OOP for clients, you are correct -- I can't spend the time necessary
to do it.

Cheers,

tedd

--
-------
http://sperling.com http://ancientstones.com http://earthstones.com

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

Re: Object Oriented Programming question

On Tue, Jan 19, 2010 at 7:11 AM, 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.
>
> Thanks,
>

Hey, Ben,

The primary purpose of object-oriented programming is to make code
easier to maintain.

Typically moving to an OO approach means designing your scripts with
objects in mind from the ground up. You might find it helpful to
start fresh with a new project and try to write it all with classes
and methods. This can be a challenge, depending on how long you have
been programming without objects.

I recommend that you find some open-source, object-oriented scripts
similar to ones you have worked on in the past and read through the
code to see how it's done. An object-oriented framework like
CodeIgniter can help get you on the right track, though there are also
pitfalls with using frameworks. Watch out for over-complex frameworks
that will only confuse you.

Also, there are a lot of poorly-written and/or non-OO PHP scripts
floating around out there, so it might help to read OO code written in
Python, Ruby, or some other scripting language. I have found that in
general, the quality of publicly available work is higher in those two
languages than in PHP.

Andrew

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

Re: Object Oriented Programming question

--=-qGK25z/M41iIhgdSbJf5
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

On Fri, 2010-03-12 at 06:49 -0800, Andrew Brookins wrote:

> On Tue, Jan 19, 2010 at 7:11 AM, 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.
> >
> > Thanks,
> >
>
> Hey, Ben,
>
> The primary purpose of object-oriented programming is to make code
> easier to maintain.
>
> Typically moving to an OO approach means designing your scripts with
> objects in mind from the ground up. You might find it helpful to
> start fresh with a new project and try to write it all with classes
> and methods. This can be a challenge, depending on how long you have
> been programming without objects.
>
> I recommend that you find some open-source, object-oriented scripts
> similar to ones you have worked on in the past and read through the
> code to see how it's done. An object-oriented framework like
> CodeIgniter can help get you on the right track, though there are also
> pitfalls with using frameworks. Watch out for over-complex frameworks
> that will only confuse you.
>
> Also, there are a lot of poorly-written and/or non-OO PHP scripts
> floating around out there, so it might help to read OO code written in
> Python, Ruby, or some other scripting language. I have found that in
> general, the quality of publicly available work is higher in those two
> languages than in PHP.
>
> Andrew
>


I'd just like to add my own thoughts on OOP.

Whereas with conventional procedural PHP you might put your functions
outside in a separate file to be called whenever you need them, going
the OOP route allows you to section out your functions into groups as it
were.

Imagine a company site selling products and support online. You might
have an object to deal with the logins, shopping cart and shopping
history, another object for dealing with the blog/forum where you
support is given, maybe another for pulling the general content of the
page together. This would allow you to only load in those bits you need
on each part of the site and re-use specific parts on other sites
easily.

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



--=-qGK25z/M41iIhgdSbJf5--

Re: Object Oriented Programming question

I also agree OOP is not a fad. Its a step up from procedural/including.
And it's still evolving.

While PHP is able to do polymorphism perfectly without OOP/classes,
through "require($plugin/className); $varFunctionName ($p1, $p2,
etc);", My newsscraper works very well that way.
But if you want inheritance features it's best to cross into OOP land.

A MVC app (front scripts that forward functionality to many other
scripts) does not have to include dozens of scripts to get things
done. You can require_once() the functionality that you need within
switch($command) statements.
Bytecachers and compilers furher reduce this problem (to
insignificance as far as i'm concerned).

But in my 20+ yrs exp, OOP-ing everything in an app from the start
costs too much (wasted) design time in the first half of any large
project.
So i've reverted back to sticking to procedural programming for nearly
everything, except well walled-off problems that scream "OOP me".

For my own CMS i first had designed classes to handle the
businesslogic near the database level (a dossier class containing refs
to media-item classes for instance), but as my CMS was evolving i was
spending too much time re-and-re-designing those dossier and media
classes. The conflict between "a well written class" and "a class that
does what i need atm" kept popping up.
I found that using functions and arrays as return/command "objects" is
much nimbler.
I get things done quicker not OOP-ing.
But i bet some other programmers prefer OOP over procedural for the same reason.

I do use OOP-ed objects for several of my subsystems (adodb.sf.net is
my current favorite), and if i have a small app to share (especially
in javascript) then i put it in an object, for namespace cleanness.

OP: if you want to use OOP to it's max, read
http://www.amazon.com/Design-Patterns-Elements-Reusable-Obje ct-Oriented/dp/0201633612/ref=sr_1_1?ie=UTF8&s=books&qid=126 8432214&sr=8-1

On Tue, Jan 19, 2010 at 7:12 PM, Robert Cummings wrote:
> 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.
>

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