|
|
Posted by Jerry Stuckle on 08/25/05 23:23
NC wrote:
> Oliver Grätz wrote:
>
>>NC schrieb:
>>
>>
>>>Fortunately, we are not there yet. OOP can still be avoided
>>>if necessary. Reading a remote file still can be done in a
>>>single file_get_contents(),
>>
>>OOP always seems to be "the bad guy". Sure, I like file_get_contents(),
>>especially if it's "file_get_contents('http://www.google.com');", but
>>what is so bad with
>>
>>$myfile=new File('my-article.txt');
>>foreach($myfile as $line)
>>{
>> // do stuff
>>}
>
>
> Nothing except it's unrealistic. In real-world object-oriented
> frameworks it's much more complicated. For example, in order
> to put the contents of a remote file into a string variable in
> VB.NET, you need to:
>
> 1. Define an HttpWebRequest object to describe the request.
> 2. Call HttpWebRequest.GetResponse(), which will return a
> WebResponse object.
> 3. Call WebResponse.GetResponseStream(), which will return a
> StreamReader object.
> 4. Call StreamReader.ReadToEnd(), which will finally give you
> the string you wanted in the first place.
>
>
>>>Most importantly, string is still not an object.
>>
>>What is so bad about
>>
>> $s=new String('this is a test');
>> echo $s->reverse();
>>
>>against
>>
>> $s='this is a test';
>> echo strrev($s);
>>
>>It's absolutely the same.
>
>
> In PHP, due to its continuing adherence to weak typing, yes.
> But OOP and weak typing are conflicting ideologies. In PHP,
> both of the examples below would work:
>
> $s = new String(123456789);
> echo $s->reverse();
>
> $s = 123456789;
> echo strrev($s);
>
> But the equivalent of "new String(123456789)" would cause an
> exception in most object-oriented languages. So you would
> have to do something like:
>
> N = 123456789
> Dim S As New String = N.ToString()
>
> So now you have two representations of the same entity...
>
>
>>But the String class could tell you about it's capabilities:
>>
>> print_r(get_class_methods('String'));
>
>
> And this is better than proper documentation because ... ?
>
>
>>The only thing bad about strings being objects is having
>>to write more code.
>
>
> Exactly. So why are we to abandon a more parsimonious approach
> in favor of less parsimonious one? Reminds me of the interview
> Bjarne Stroustrup supposedly gave to Computer magazine in 1998...
>
>
>>Objects are good. Period.
>
>
> You are entitled to your opinion, but I respectfully disagree.
> Objects are resource hogs. They are good only at creating more
> work for programmers (and that's why programmers like them).
> Their use in PHP should be limited to interfacing with
> technologies incapable of procedural interaction (COM, .NET,
> Java, etc.)
>
> Cheers,
> NC
>
Sorry, I disagree with you. OO does not have to be a resource hog. For
instance, in C++, you can define
String s = new String("123456789");
No duplication of data necessary.
Also, good OO code can be as (or more) efficient than non-OO code. Where it
becomes less efficient (other than poor programming practices) is when it
becomes more general purpose. This increases reuse - but also increases file
size and generally decreases performance. But that's also one of the limits of
reuse. It shows up in procedural code, also. For instance, the C call
"malloc()" (memory allocation) is known to be relatively slow. I can (and have)
easily write a function which will optimize memory allocation for a specific
structure, for instance. It will be faster and use less memory in the long run
(less fragmentation). But it's not worth the effort in 99% (or more) of the cases.
The real beauty of properly written OO is to separate the data representation
(i.e. storage, etc.) from the use of that data. A simple case - I needed to get
a web site up quickly (one day) on a (low cost) host where MySQL wasn't working
reliably. While the host worked on the problem, I created classes representing
the data storage which used CSV files and stored all my data there. I created
all the dynamic web pages based on the classes. Once they got MySQL working
properly, I simply changed the classes to use MySQL instead. I changed only the
class files - instead of numerous web page files. And I only had to test the
class files themselves - I knew the web pages were already working. A huge
savings of time!
Sure, it was a duplication of effort - but the site was up and running on time
and the customer was happy. And if they ever decide to go to any other
database, again it's a change of only the class files - none of the pages.
As I said - this is a simple, but real-life case. Before OO we used to do
similar things by creating functions to operate on the data. But that's just
basically object-based (instead of object-oriented) without many of the benefits
of true OO.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
Navigation:
[Reply to this message]
|