Re: Re: Suggestions for class design

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello,

on 09/20/2005 04:59 AM Murray @ PlanetThoughtful said the following:
Let's take for example a class called 'Customer' that (obviously)
manipulates customers in the database. Here is a very basic Customer
class. (Data validation and the like are left out for brevity.)
This is a basic object persistence problem.


(Unless I've already got some major design flaws I think we should be
good to go.)
 >
 > Where I get tripped up is when I realize I'll need to at some point
 > get more than one customer at a time and thus I want to add a method
 > called 'get_customers()'.


Yes, there is a problem. You are trying to retrieve objects into memory
before they exist. It makes more sense that you retrieve objects using a
factory class.

That is the approach of Metastorage. You may want to take a looka at
Metastorage before you reinvent the wheel.

Hi Manuel,

I very much understand your desire to promote your various projects, but the
original poster is asking a question that is basic to any programmer's
development in object-oriented coding.

I denote a certain bias on your part against the fact that I suggest projects that I have developed.

The matter is that I am suggesting projects that I use. The fact that I developed them is a mere coincidence. I do not always suggest projects that I developed as I am not such a wizard that I have the best solutions for everything. However, if I use and recommend certain solutions, mine or others is because I believe they are the best at least for my purposes.

What the original poster wants to know is what is the best solution retrieve a collection of objects. I recommended what I use and explained why I think it is the best approach for this purpose. He appreciated the reply and sent me a thank you message.

I do not understand why this could bother you or anybody else. If you have a better solution, nothing stops you to make your recommendations.



Once he understands how to solve class abstraction problems such as the one
he is asking about, he will be better equipped to deal with a wider range of
application development tasks.

Right, that is why I suggested something that I believe that solves his probleme better and even justified.


This is not to trivialize your Metastorage project (or, to be more accurate,
I know nothing about it, so it's not my place to trivialize it or
otherwise), but to point out that 'out-of-the-box' solutions to fundamental
coding development problems probably ultimately makes for a poorer
programmer. I could well be wrong, but it seems this is a case of "give a
man a fish" as opposed to "teach a man to fish".

I think you should have learned about Metastorage first before commenting. It is not really a out-of-the-box solution. It is a code generator tool that employs well known design patterns to generate code to customized to the developer needs.

It is not yet another template pasting tool. It uses the JE WIN approach: Just Exactly What I Need. That works by letting the developer tell the kind of functions he wants to use, rather than bundling a pile of code that you may never user.

It takes in account the design of your persistent object classes to generate optimized code for the task, rather than generic code for unnecessary generic needs.

Basically it generates the code that you would generate if you were an expert in object persistence methodology.

Given that, I am not even saying, "use this", but rather, take a look at the kind of code that it generates as a concrete example of what I tried to explain. The generated code even comes with comments so you do not have to wonder too much.

Whether the original poster will use Metastorage or just pick some ideas, that is another story.


Also, and separate from above, I don't understand the relevance of your
comment, "You are trying to retrieve objects into memory before they exist".
Unless I'm horribly mistaken [1], the original poster has developed a class
that abstracts a single customer, and is asking the list for suggestions in
how to best approach a need to be able to abstract collections of customers.
This is a normal application development issue, and for the life of me I
can't grasp how your comment relates.

I tried to explain in the part of the message that you did not quote, why using a factory class as entry point, which is my suggestion, it makes more sense.

In case this was not very clear, who gives existence to the objects should be a parent, not a brother like he was doing. He was using a Customer class object to give birth to other unrelated Customer objects.

When using a factory class you can execute a query to retrieve Customer objects and create them on demand. This means that you do not have to create one Customer object first. The query may return data for 0 or more Customer objects. A factory may create just exactly the number of Customer objects as needed.

Furthermore, a factory class may solve the problem of avoiding to create multiple copies of the same Customer object in memory. That can be done by keeping a private array of all Customer objects retrieved in memory so far.

While retrieving the Customer collection query results, the factory class can check if a given customer object was already retrieve. If so it may return a reference to previously retrieved object instead of creating a new copy.

This is important because if you changed an Customer object in memory and later query a collection of customer object, if a new object copy is created it would be inconsistent with what you changed before. The consequences for your application can be disastrous.

I am not sure if this explanation is clear now as I admit that these matters are very abstract.


--

Regards,
Manuel Lemos

PHP Classes - Free ready to use OOP components written in PHP
http://www.phpclasses.org/

PHP Reviews - Reviews of PHP books and other products
http://www.phpclasses.org/reviews/

Metastorage - Data object relational mapping layer generator
http://www.meta-language.net/metastorage.html

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


[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux