By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,264 Members | 1,079 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,264 IT Pros & Developers. It's quick & easy.

working with classes + php

P: n/a
I'm new to working with classes. I'm pretty much a self taught php
programmer that uses php mostly for database entry and listings. I would
like to expand my talents and start working with classes. Is there a good
tutorial out there on the web that a novice can understand. I currently
wanting to add a password generator class to one of my existing webpages at
my helpdesk. The class is located at PHPclasses.com
(class.password.generator.php). Thanks for any help that you can give.

A
May 15 '07 #1
Share this Question
Share on Google+
20 Replies


P: n/a
On May 15, 3:09 pm, "Auddog" <wil...@hotmail.comwrote:
I'm new to working with classes. I'm pretty much a self taught php
programmer that uses php mostly for database entry and listings. I would
like to expand my talents and start working with classes. Is there a good
tutorial out there on the web that a novice can understand. I currently
wanting to add a password generator class to one of my existing webpages at
my helpdesk. The class is located at PHPclasses.com
(class.password.generator.php). Thanks for any help that you can give.

A
I think learning OOP in PHP causes bad habits. There are too many
different ways to do it. If you learn from a language like Java, you
will certainly get it down very well. PHP5 has many of the features of
Java OOP (not all of them, though).

If you don't have a plethora of time and need to go with the more
practical approach of learning OOP where you will be using it, in PHP,
the PHP manual is the most accurate way to learn it.

http://php.net/oop

-Mike PII

May 15 '07 #2

P: n/a
I think learning OOP in PHP causes bad habits. There are too many
different ways to do it. If you learn from a language like Java, you
will certainly get it down very well. PHP5 has many of the features of
Java OOP (not all of them, though).

On the contrary. Java also has quite a few unwanted characteristics as
an OO language. I agree that Eiffel would be a better place to start,
but it remains abstract, as it is hardly used. Also, PHP programmers
often have to learn javascript as well, so you gain an understanding of
both class-based and template-based object orientation.

I think the "bad habits" are a good thing to start from. As a resource
on how to learn OO programming, I would also recommend "Refactoring" by
Martin Fowler. The examples alone in that book can teach you as much as
a good theory book.

I think PHP offers you the opportunity of gently discovering the
advantages of objects. In fact, a lot of people only need to realize the
power of a component like PHPMailer or FPDF to give abstract words like
"code reuse" a firm body.

Best regards
May 15 '07 #3

P: n/a
Dikkie Dik wrote:
>I think learning OOP in PHP causes bad habits. There are too many
different ways to do it. If you learn from a language like Java, you
will certainly get it down very well. PHP5 has many of the features of
Java OOP (not all of them, though).


On the contrary. Java also has quite a few unwanted characteristics as
an OO language. I agree that Eiffel would be a better place to start,
but it remains abstract, as it is hardly used. Also, PHP programmers
often have to learn javascript as well, so you gain an understanding of
both class-based and template-based object orientation.

I think the "bad habits" are a good thing to start from. As a resource
on how to learn OO programming, I would also recommend "Refactoring" by
Martin Fowler. The examples alone in that book can teach you as much as
a good theory book.

I think PHP offers you the opportunity of gently discovering the
advantages of objects. In fact, a lot of people only need to realize the
power of a component like PHPMailer or FPDF to give abstract words like
"code reuse" a firm body.

Best regards
I don't know what "unwanted characteristics" java has as an OO language.
It is a pure OO implementation. And I agree with Mike - I think Java
is a much better language to learn OO programming.

And I've found the "bad habits", once you get into them, are very hard
to break. I don't know how many times I've had C++ programmers who got
off to the wrong start with OO programming and the result was a
horrendous mess of OO and non-OO code.

Smalltalk is also a great language for learning OO, but it's not used in
web programming.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
May 16 '07 #4

P: n/a
Jerry Stuckle wrote:
<snip>
I don't know what "unwanted characteristics" java has as an OO
language. It is a pure OO implementation.
I'm curious why you think Java "is a pure OO implementation?"
--
Visit <http://blogs.instreamfinancial.com/anything.php>
to read my rants on technology and the finance industry.
May 16 '07 #5

P: n/a
Thomas Gagne wrote:
Jerry Stuckle wrote:
><snip>
I don't know what "unwanted characteristics" java has as an OO
language. It is a pure OO implementation.
I'm curious why you think Java "is a pure OO implementation?"

Because it is designed that way. It has all the aspects of OO, and you
must do everything in an OO manner.

But that doesn't mean you can't write bad code in it.

Why do you think it isn't?

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
May 16 '07 #6

P: n/a
On 17.05.2007 03:01 Jerry Stuckle wrote:
I don't know what "unwanted characteristics" java has as an OO language.
It is a pure OO implementation. And I agree with Mike - I think Java
is a much better language to learn OO programming.
Technically, Java is not "pure OOP" language, because it has many
non-oop features, e.g. primitives.

As to learning, why if you try to explain to someone who is new to
programming, why this

class Test {
public static void main(String[] args) {
System.out.println("hello");
}
}

is any better than

echo "hello";
;)
>
Smalltalk is also a great language for learning OO, but it's not used in
web programming.
Seaside (http://www.seaside.st) is a great Smalltalk-based
web-development framework.

I personally find Ruby (which is essentially "smalltalk for the masses")
an ideal language to learn OOP and webprogramming.
--
gosha bine

extended php parser ~ http://code.google.com/p/pihipi
blok ~ http://www.tagarga.com/blok
May 16 '07 #7

P: n/a
>I'm curious why you think Java "is a pure OO implementation?"
Why do you think it isn't?
Because it is not pure OO. Not everything is an object. There are "basic
types" and "objects" in java. And Strings, that are both/neither basic
types and objects.

In pure OO languages (like Ruby), ALL types are objects. Including
integers, floats, etc.

--
Willem Bogaerts

Application smith
Kratz B.V.
http://www.kratz.nl/
May 16 '07 #8

P: n/a
gosha bine wrote:
On 17.05.2007 03:01 Jerry Stuckle wrote:
<snip>
>>
Smalltalk is also a great language for learning OO, but it's not used
in web programming.

Seaside (http://www.seaside.st) is a great Smalltalk-based
web-development framework.

I personally find Ruby (which is essentially "smalltalk for the
masses") an ideal language to learn OOP and webprogramming.

Stuckle is partially correct--nothing indicates that Smalltalk for
growing as a web language as fast as other languages are, but I did hear
at conference two weeks ago the Ruby on Rails presenter (a big Ruby fan)
suggesting anyone using Seaside would be moving backwards to Rails.
Indicating that if you think Rails is cool (and it is) you should see
what Seaside can do.

--
Visit <http://blogs.instreamfinancial.com/anything.php>
to read my rants on technology and the finance industry.
May 16 '07 #9

P: n/a
Mike P2 wrote:
I think learning OOP in PHP causes bad habits. There are too many
different ways to do it. If you learn from a language like Java, you
will certainly get it down very well.
I'd agree with what others have posted that Java is not an ideal place to
start learning object-oriented programming, though for different reasons.

In object-oriented programming, everything's focused on "nouns". In real
life, verbs are just as important. In pure OO, a verb (method) can only
exist as an appendage to a noun (object). Thus instead of creating a
function like log_error(), OO programmers create an object ErrorLogger
with a method doIt() and somehow imagine that this is a better design.

This leads to a proliferation of FooProvider, FooFacilitator, FooFactory
and FooInitialiser objects in large OO programs.

There's a good article on such problems here...
http://steve-yegge.blogspot.com/2006...-of-nouns.html

PHP, I think, as a much better balance than Java. It has good OO
facilities, but doesn't force you to use them when they're not the
best tool for the job.

--
Toby A Inkster BSc (Hons) ARCS
http://tobyinkster.co.uk/
Geek of ~ HTML/SQL/Perl/PHP/Python/Apache/Linux
May 16 '07 #10

P: n/a
On 16.05.2007 16:21 Toby A Inkster wrote:
>
In object-oriented programming, everything's focused on "nouns". In real
life, verbs are just as important. In pure OO, a verb (method) can only
exist as an appendage to a noun (object). Thus instead of creating a
function like log_error(), OO programmers create an object ErrorLogger
with a method doIt() and somehow imagine that this is a better design.
In your everyday natural language, how often do you use verbs without
nouns and nouns without verbs? In OOP, when you say

client.connect_to(server)

this is exactly how you'd say it in english.
--
gosha bine

extended php parser ~ http://code.google.com/p/pihipi
blok ~ http://www.tagarga.com/blok
May 16 '07 #11

P: n/a
Willem Bogaerts wrote:
>>I'm curious why you think Java "is a pure OO implementation?"
>Why do you think it isn't?

Because it is not pure OO. Not everything is an object. There are "basic
types" and "objects" in java. And Strings, that are both/neither basic
types and objects.

In pure OO languages (like Ruby), ALL types are objects. Including
integers, floats, etc.
OK, I'll grant that the primitive types are not objects, so it isn't a
"pure OO language" in that sense.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
May 16 '07 #12

P: n/a
Toby A Inkster wrote:
Mike P2 wrote:
>I think learning OOP in PHP causes bad habits. There are too many
different ways to do it. If you learn from a language like Java, you
will certainly get it down very well.

I'd agree with what others have posted that Java is not an ideal place to
start learning object-oriented programming, though for different reasons.

In object-oriented programming, everything's focused on "nouns". In real
life, verbs are just as important. In pure OO, a verb (method) can only
exist as an appendage to a noun (object). Thus instead of creating a
function like log_error(), OO programmers create an object ErrorLogger
with a method doIt() and somehow imagine that this is a better design.

This leads to a proliferation of FooProvider, FooFacilitator, FooFactory
and FooInitialiser objects in large OO programs.

There's a good article on such problems here...
http://steve-yegge.blogspot.com/2006...-of-nouns.html

PHP, I think, as a much better balance than Java. It has good OO
facilities, but doesn't force you to use them when they're not the
best tool for the job.
That's true, Toby. but typically my ErrorLogger would have additional
functions, also - such as log levels, destination, etc.

But yes, improper design does lead to a proliferation of objects. That
doesn't mean the language is bad - rather its the implementation that
stinks.

Any time you have a class with only one method and/or no properties you
need to be looking at the implementation of the class. You may or may
not change the class (or get rid of it all together), but that should be
a red flag.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
May 16 '07 #13

P: n/a
Jerry Stuckle wrote:
<snip>

OK, I'll grant that the primitive types are not objects, so it isn't a
"pure OO language" in that sense.
It's been a while since I've used Java, but I'm pretty sure its messages
aren't objects either. And if its stack frame were an object it would
make backtracking and exception continuations more easily implemented.

Another reason one might consider Java fairly non-OO is the language's
dependency on its syntax for feature implementation. Consider how new
features in Java require parser/compiler changes and new keywords rather
than new methods to existing objects.

Java's static typing is another constraining feature. If you've never
worked without it then dynamic typing's value and the importance of
messages instead of function calls may be lost on you.

But I think comparing Java to OO languages is unfair since Java wasn't
designed to be a great OO language (that had been done years earlier),
it was a product designed to capitalize on the emerging web hysteria and
an antidote to C and C++ programming by adding garbage collection (and
more keywords).

--
Visit <http://blogs.instreamfinancial.com/anything.php>
to read my rants on technology and the finance industry.
May 16 '07 #14

P: n/a
gosha bine wrote:
In your everyday natural language, how often do you use verbs without
nouns and nouns without verbs?
Go away! (is an example)

It's not so much a case of using nouns alone, or verbs alone; but OOP
promotes nouns as "masters" and verbs as "slaves". A verb cannot be
invoked without first referencing some noun.

As a practical example, consider this code in PHP:

function dump_obj($o)
{
echo get_class($o) . "\n";

$M = get_class_methods($o);
sort($M);
foreach ($M as $method)
echo "+ {$method}()\n";

$K = get_class_vars($o);
sort($K);
foreach ($K as $key)
{
$val = $o->$key;
if (is_array($val))
$val = sprintf('Array, length %d', count($val));
elseif (is_object($val))
$val = sprintf('Object, type %s', get_class($val));
elseif (is_string($val))
{
if (strlen($val)<40 && !strstr($val, "\n"))
$val = sprintf("'%s'", addslashes($val));
else
$val = sprintf('String, length %d', strlen($val));
}
elseif (is_bool($val))
$val = $val?'TRUE':'FALSE';
elseif (is_null($val))
$val = 'NULL';
elseif (!is_numeric($val))
$val = gettype($val);

echo " $key = $val\n";
}
echo "--\n";
}

This can be used like so:

dump_obj($database);
dump_obj($user);
dump_obj($template);

where $database, $user and $template are objects of some type.

Now, probably the best pure-OO method for doing this would be to give each
object you're likely to want to dump a "dump()" method, so you'd have:

$database->dump();
$user->dump();
$template->dump();

However, that means that you need to re-implement the dump() method for
each class your write. You *may* be able to use inheritance here, but
because most OO languages (Java and PHP included) don't support
multiple-inheritance, if your classes are already inheriting from
some other parent class, then inheritance is probably not possible.

So you create the ObjectDumper class.

If you're dumb, you'll code it like this:

class ObjectDumper
{
public function dump (Object $o)
{ /* as above */ }
}

And you'll need to call it like this:

$dumper = new ObjectDumper;
$dumper->dump($database);
$dumper->dump($user);
$dumper->dump($template);

But if you're smart, you'll use a static method, like this:

class ObjectDumper
{
public function __construct ()
{ throw new Exception('Do not create instance of ObjectDumper.'); }
public static function dump (Object $o)
{ /* as above */ }
}

And then you can just code this:

ObjectDumper::dump($database);
ObjectDumper::dump($user);
ObjectDumper::dump($template);

Some OO purists will contest that the above is somehow "better", but when
asked why, they'll generally fall back on "because it's object-oriented"
as if that were an end in itself.

OO should not be treated as an end in itself. OO is often, some might even
say usually, a good way of modelling complex projects, and classes provide
a good way of organising code, minimising naming collisions and increasing
code legibility.

However, it doesn't always make sense. In the above ObjectDumper example,
the object oriented code is:

1. Bigger: requires more code;
2. Slower: requires more parser time, and in the case of the
"dumb" example, requires time to instantiate the object; and
3. No more readable than the original dump_obj() function.

Java forces you down the object-oriented route every time. PHP (and PHP is
by no means alone in this matter) allows you to use object-oriented methods
when appropriate, and procedural programming when it makes sense.

--
Toby A Inkster BSc (Hons) ARCS
http://tobyinkster.co.uk/
Geek of ~ HTML/SQL/Perl/PHP/Python/Apache/Linux
May 17 '07 #15

P: n/a
Toby A Inkster wrote:
gosha bine wrote:
>In your everyday natural language, how often do you use verbs without
nouns and nouns without verbs?

Go away! (is an example)

It's not so much a case of using nouns alone, or verbs alone; but OOP
promotes nouns as "masters" and verbs as "slaves". A verb cannot be
invoked without first referencing some noun.

As a practical example, consider this code in PHP:

function dump_obj($o)
{
echo get_class($o) . "\n";

$M = get_class_methods($o);
sort($M);
foreach ($M as $method)
echo "+ {$method}()\n";

$K = get_class_vars($o);
sort($K);
foreach ($K as $key)
{
$val = $o->$key;
if (is_array($val))
$val = sprintf('Array, length %d', count($val));
elseif (is_object($val))
$val = sprintf('Object, type %s', get_class($val));
elseif (is_string($val))
{
if (strlen($val)<40 && !strstr($val, "\n"))
$val = sprintf("'%s'", addslashes($val));
else
$val = sprintf('String, length %d', strlen($val));
}
elseif (is_bool($val))
$val = $val?'TRUE':'FALSE';
elseif (is_null($val))
$val = 'NULL';
elseif (!is_numeric($val))
$val = gettype($val);

echo " $key = $val\n";
}
echo "--\n";
}

This can be used like so:

dump_obj($database);
dump_obj($user);
dump_obj($template);

where $database, $user and $template are objects of some type.

Now, probably the best pure-OO method for doing this would be to give each
object you're likely to want to dump a "dump()" method, so you'd have:

$database->dump();
$user->dump();
$template->dump();

However, that means that you need to re-implement the dump() method for
each class your write. You *may* be able to use inheritance here, but
because most OO languages (Java and PHP included) don't support
multiple-inheritance, if your classes are already inheriting from
some other parent class, then inheritance is probably not possible.
That would be an improper use of inheritance, Toby. Inheritance
requires an "izza" relationship, i.e. an Employee "izza" Person, a
Manager "izza" Employee, etc. A database is not a dump.
So you create the ObjectDumper class.

If you're dumb, you'll code it like this:

class ObjectDumper
{
public function dump (Object $o)
{ /* as above */ }
}

And you'll need to call it like this:

$dumper = new ObjectDumper;
$dumper->dump($database);
$dumper->dump($user);
$dumper->dump($template);

But if you're smart, you'll use a static method, like this:

class ObjectDumper
{
public function __construct ()
{ throw new Exception('Do not create instance of ObjectDumper.'); }
public static function dump (Object $o)
{ /* as above */ }
}

And then you can just code this:

ObjectDumper::dump($database);
ObjectDumper::dump($user);
ObjectDumper::dump($template);
There are other considerations, also. For instance, do you want to
specify the type of dump (i.e. just dump memory, make it human-readable,
etc.). Do you want to specify the dump file location? And dozens of
other possibilities.

However, this can also be considered a System (or maybe, more
accurately, "subsystem") function. Another way to do it, which would be
appropriate, would be to create a (Sub)System object, possibly derived
from a System object, and add the method (and any related ones) to it.
Some OO purists will contest that the above is somehow "better", but when
asked why, they'll generally fall back on "because it's object-oriented"
as if that were an end in itself.
It's better than inheriting from a Dump object, as noted above.
OO should not be treated as an end in itself. OO is often, some might even
say usually, a good way of modelling complex projects, and classes provide
a good way of organising code, minimising naming collisions and increasing
code legibility.

However, it doesn't always make sense. In the above ObjectDumper example,
the object oriented code is:

1. Bigger: requires more code;
2. Slower: requires more parser time, and in the case of the
"dumb" example, requires time to instantiate the object; and
3. No more readable than the original dump_obj() function.

Java forces you down the object-oriented route every time. PHP (and PHP is
by no means alone in this matter) allows you to use object-oriented methods
when appropriate, and procedural programming when it makes sense.
I would still do it in an OO method in PHP, using a System object which
handles a lot of system-oriented tasks.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
May 17 '07 #16

P: n/a
Toby A Inkster wrote:
gosha bine wrote:
>In your everyday natural language, how often do you use verbs without
nouns and nouns without verbs?

Go away! (is an example)
Example of your sense of humor? Very nice indeed.
It's not so much a case of using nouns alone, or verbs alone; but OOP
promotes nouns as "masters" and verbs as "slaves". A verb cannot be
invoked without first referencing some noun.
Just like a noun cannot be used without a verb. How often did you see
"new MyClass()" without assignment or method call?
As a practical example, consider this code in PHP:

function dump_obj($o)
Debugging is perhaps the worst example you could come up with. Debug
functions are, by their nature, aware of object internals, which is not
the case for regular methods.
Now, probably the best pure-OO method for doing this would be to give each
object you're likely to want to dump a "dump()" method, so you'd have:

$database->dump();
$user->dump();
$template->dump();

However, that means that you need to re-implement the dump() method for
each class your write. You *may* be able to use inheritance here, but
because most OO languages (Java and PHP included) don't support
multiple-inheritance, if your classes are already inheriting from
some other parent class, then inheritance is probably not possible.
This should be rephrased as "some languges, like Java and PHP, don't
support etc", but I don't think inheritance is an issue here.
Mixins/delegation looks more appropriate

# ruby

module Dumper
def dump
....
end

class User
include Dumper
....
end
a = User.new
a.dump

But yet again, methods that must be aware of their arguments' internals
are very rare and almost always a sign of architecture flaws.

So you create the ObjectDumper class.

If you're dumb, you'll code it like this:
....
$dumper = new ObjectDumper;
$dumper->dump($database);
$dumper->dump($user);
$dumper->dump($template);
Looks ok to me (yes, I just called myself dumb ;), if we replace
irrelevant debugging example with more realistic one:

class Printer // can be specialized to HTMLPrinter, PDFPrinter etc
function print(other)
data = other.getPrintableData
....
interface Printable
function getPrintableData

class User implements Printable
class FooBar implements Printable

$somePrinter.print($someUser)
$somePrinter.print($someFoobar)
But if you're smart, you'll use a static method, like this:
"static methods" are not the part of OOP concept. It's just a fancy way
to call a global function and should be avoided in pure OOP.
Some OO purists will contest that the above is somehow "better", but when
asked why, they'll generally fall back on "because it's object-oriented"
as if that were an end in itself.
Again, this has nothing to do with OOP. Let's replace "OO purists" with
"PHP newbies" and I will agree completely.
OO should not be treated as an end in itself. OO is often, some might even
say usually, a good way of modelling complex projects, and classes provide
a good way of organising code, minimising naming collisions and increasing
code legibility.
Looks like you're confusing OO notation and OO thinking. It's perfectly
possible to write OO program in pure C, and there are a lot of Java
programs that are in essence procedural.

--
gosha bine

extended php parser ~ http://code.google.com/p/pihipi
blok ~ http://www.tagarga.com/blok
May 17 '07 #17

P: n/a
Jerry Stuckle wrote:
That would be an improper use of inheritance, Toby. Inheritance
requires an "izza" relationship, i.e. an Employee "izza" Person, a
Manager "izza" Employee, etc. A database is not a dump.
DumpableObject extends Object { /*...*/ }
Person extends DumpableObject { /*...*/ }
Employee extends Person { /*...*/ }
Manager extends Employee { /*...*/ }
Database extends DumpableObject { /*...*/ }

--
Toby A Inkster BSc (Hons) ARCS
http://tobyinkster.co.uk/
Geek of ~ HTML/SQL/Perl/PHP/Python/Apache/Linux
May 17 '07 #18

P: n/a
Toby A Inkster wrote:
gosha bine wrote:

>In your everyday natural language, how often do you use verbs without
nouns and nouns without verbs?

Go away! (is an example)

It's not so much a case of using nouns alone, or verbs alone; but OOP
promotes nouns as "masters" and verbs as "slaves". A verb cannot be
invoked without first referencing some noun.
That's one way of thinking about it. Or we could say methods require a
scope (they must), even if that scope is implicit it is still a scope.
The scope is some kind of object whether its HERE or THERE, it's got to
be somewhere. No matter where you go, there you are.
As a practical example, consider this code in PHP:
<snip>
This can be used like so:

dump_obj($database);
dump_obj($user);
dump_obj($template);
It could. Regardless whether it is a good example or not it is an
example of tight coupling, which is usually a clue that a method is
poorly scoped -- it lives somewhere it probably shouldn't.
Now, probably the best pure-OO method for doing this would be to give each
object you're likely to want to dump a "dump()" method.
I don't know by what measurement this would be considered the "best
pure-OO method." I can think of at least two other ways that are
acceptably OO that don't require redundant code. This example, if its
the "best pure-OO method" PHP allows, isn't a pattern as much as it's a
kludge. And because it's a kludge it carries all the usual baggage
kludges carry with them--including redundant code.
, so you'd have:

$database->dump();
$user->dump();
$template->dump();

However, that means that you need to re-implement the dump() method for
each class your write. You *may* be able to use inheritance here, but
because most OO languages (Java and PHP included) don't support
multiple-inheritance, if your classes are already inheriting from
some other parent class, then inheritance is probably not possible.
Since "pure OO" has already been brought up, then we should agree that
all classes inherit from a single base class, commonly called Object.
It would be consistent with the best OO approaches to implement the
method once in Object so all its subclass' instances could use it. It
provides the added benefit of allowing subclasses whose structure
prohibits dump() from working properly, to override its behavior so that
it does work predictably, which is something a locally scoped dump()
class, as you've described, would not be able to do.
So you create the ObjectDumper class.
I'll skip the straw man "dumb" example, but the solution proposed with
the static method is an attempt to give the method a global scope.
That's all. If the syntax is a bother than it's not the fault of OO,
just of PHP's syntax. But even that is a mere inconvenience because a
better design is sexier than bad syntax is ugly.
>
<snip>

Some OO purists will contest that the above is somehow "better", but when
asked why, they'll generally fall back on "because it's object-oriented"
as if that were an end in itself.
No. Relatively better scoping is relatively worse scoping. Some
people know this intuitively but have trouble describing it.

One approach you didn't describe by itself is also satisfactorily OO, if
you ignore its coupling--a locally scoped (instance) method. If an
object (or more precisely one of its methods) needs to do something
fairly unique to itself (good cohesion) but invasive to other objects
(bad coupling) it could implement that method inside its own scope, just
as it does any of its other methods.
OO should not be treated as an end in itself. OO is often, some might even
say usually, a good way of modelling complex projects, and classes provide
a good way of organising code, minimising naming collisions and increasing
code legibility.

However, it doesn't always make sense.
This complaint is often repeated by people either attacking OO or
apologizing for it. Often (though not in this posting) OO is compared
to a hammer--then everything else is a nail. Well, if we consider
programming is a nail then perhaps some people are just using the wrong
end of the hammer?
<snip>

Java forces you down the object-oriented route every time.
I wish it did. We'd probably see better Java code.
PHP (and PHP is
by no means alone in this matter) allows you to use object-oriented methods
when appropriate, and procedural programming when it makes sense.
This is a similar argument C++ proponents make. That by being
multi-paradigm (as the description above seems to say about PHP) it
allows the programmer more flexibility. Another way of looking at it
would be to say C++ is jack of all trades and master of none. Or
without analogy, that a multi-paradigm language is adequate for
everything but excellent at nothing.
--
Visit <http://blogs.instreamfinancial.com/anything.php>
to read my rants on technology and the finance industry.
May 17 '07 #19

P: n/a
Toby A Inkster wrote:
Jerry Stuckle wrote:
>That would be an improper use of inheritance, Toby. Inheritance
requires an "izza" relationship, i.e. an Employee "izza" Person, a
Manager "izza" Employee, etc. A database is not a dump.

DumpableObject extends Object { /*...*/ }
Person extends DumpableObject { /*...*/ }
Employee extends Person { /*...*/ }
Manager extends Employee { /*...*/ }
Database extends DumpableObject { /*...*/ }
That could work, but it's a bit of a stretch.

One of the problems here is you would have multiple DumpableObjects out
there unnecessarily. And if you want to change the location of the dump
file, for instance, you need to change it in all the objects. Of
course, you could use static members for the location. But I think it's
unnecessary overhead.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
May 17 '07 #20

P: n/a
Lol. It looks like I've started quite a controversy with my suggestion
to learn another language with OOP first. Sorry about that, Auddog.

So anyway, if you're still keeping up with this thread, you can read
that suggested book, read the PHP documentation, or go big and
learn...some...other language first.

-Mike PII

May 17 '07 #21

This discussion thread is closed

Replies have been disabled for this discussion.