You are here: Re: Trying to get to grips with OOP! Classes. « PHP Programming Language « IT news, forums, messages
Re: Trying to get to grips with OOP! Classes.

Posted by Carl on 10/22/43 11:35

Simon Dean wrote:
> Carl wrote:
>
>> Simon Dean wrote:
>>
>>> Thing is though... what if you just want to list a series of Actors
>>> that you have on file (this is totally fictiional - It could be
>>> Orders Order OrderDetails OrderDetail Customers Customer etc...
>>
>>
>>
>> I think you may want to take a step back and think closely about what
>> exactly you think an object is. The <Actor> is a valid object IMO,
>> <Actors> is not; It is simply a collection of <Actor> Objects (a.k.a
>> an array in php).
>>
>> If you really want to be able to produce a list of actors in an OO
>> manner, you may consider a class such as <ActorManager>, which when
>> instantiated contains a collection of actor objects. It may also have
>> the ability to limit the actors it 'represents' based on criteria
>> such as age, sex, experience, etc.
>
>
> What's the difference then, between your ActorManager and my Actors class?
>


It is not really much different; The fundamental difference being the
disambiguation of the actual role of the object that produces the list
of actors. Having an <Actors> class is no better to me than simply
loading an array with actors, and does not satisfy _my_ requirements for
a productive object; the creation of a list of actors with no additional
functionality would just as well be implemented in a method rather than
a class.

An <ActorManager> class should provide methods to handle those
responsibilities that you would expect of a Manager/Agent responsible
for managing actors. i.e. select all actors that are available for work,
all actors of a certain age, only female actors, etc... An ambiguous
<Actors> class suggest no other responsibility other than being a
collection of actors, something that an array in php will already handle
quite well.

>
>> Are you using a database to store your Customers/Actors, if so, you
>> may want to consider the fact that you already have a 'collection' of
>> Customers/Actors inherent in the db table itself. Rewriting this
>> collection in code without abstracting it further or adding additional
>> functionality gives very little reward for the effort.
>
>
> Don't get me wrong, I quite agree. This is just the structure we use at
> work where we get everything from the database and represent everything
> in classes and then more... It's never made much sense to me, because
> nothing is really being simplified in the process... the error handling,
> save and load routines are being standardised though I guess... but
> that's about it....
>

I understand, I've seen this method used before and am not suggesting it
is 'wrong'. Still, I firmly believe that by using it, you are not taking
full advantage of object oriented programming.

>>
>> The relationship between customers/orders/order details you describe
>> is a very standard "one to many" relationship.
>>
>>>
>>> Any how, back to my original observation... yes, what if I just want
>>> to show an "actor" listing and therefore, I just want to load a
>>> particular selection criteria and loop through as I would with
>>> while($line = mysql_fetch_array($result))) { } (hey, did I just
>>> remember some coding?)???
>>
>>
>>
>> Again, i would suggest something like the <ActorManager> class I
>> described above, for example...
>>
>> /* * print the name and age of all actors between 18 and 30 years old
>> */ $manager = new ActorManager(); $manager->setMinimumAge(18);
>> $manager->setMaximumAge(30);
>>
>> $actors = $manager->getActorList(); foreach($actors as $actor) { echo
>> $actor->name."\t".$actor->age."\n"; }
>
>
> In this instance, presumably the set's are a backend to produce a where
> statement, the getActorList loads the query data into a selection of
> Actor objects, which again, doesn't sound too different to my Actors
> class... perhaps I never explained it properly...

There is a good possibility that the implementation of your method is
not very different from mine. Perhaps the difference of opinion is a
result of semantics. When thinking about object oriented design, i
particularly like this definition of object (from
http://wordnet.princeton.edu/perl/webwn?s=object ) :
"(a tangible and visible entity; an entity that can cast a shadow) "it
was full of rackets, balls and other objects""

Although it is not always possible _or even ideal_ to make this a firm
rule, I find if beneficial to define objects in a manner that make its
purpose, actions, attributes and features as clear as possible.

Cheers,
Carl.

 

Navigation:

[Reply to this message]


Удаленная работа для программистов  •  Как заработать на Google AdSense  •  England, UK  •  статьи на английском  •  PHP MySQL CMS Apache Oscommerce  •  Online Business Knowledge Base  •  DVD MP3 AVI MP4 players codecs conversion help
Home  •  Search  •  Site Map  •  Set as Homepage  •  Add to Favourites

Copyright © 2005-2006 Powered by Custom PHP Programming

Сайт изготовлен в Студии Валентина Петручека
изготовление и поддержка веб-сайтов, разработка программного обеспечения, поисковая оптимизация