|
|
Posted by gosha bine on 05/17/07 14:34
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
Navigation:
[Reply to this message]
|