Re: [PHP] Re: Suggestions for class design

[Manuel Lemos]

Hello,

on 09/20/2005 01:51 PM Murray @ PlanetThoughtful said the following:

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.


Hi Manuel,

I did make my recommendation. To you. It went something like (and I'm
paraphrasing), "Your proposed solution doesn't solve the original poster's
conceptual problem with abstracting classes that deal with collections of
objects in conjunction with classes that abstract single objects."

In other words, and I realize I'm stretching out on a limb with this
metaphor, I saw in your post an attempt to treat the symptoms without
offering a cure for the disease.


That is your impression because you really do not know how Metastorage 
generated code works.


It provides several types of functions that retrieve and manipulate 
collection. Retrieval is done by storing all collection objects in an 
array that is returned by those functions. There is no need for a 
separate class to abstract collections.




And your perception of bias may or may not be accurate. I don't recall
delivering wrath-of-god denunciation of your suggestion to use a project you
developed, just acknowledged a desire to promote a project you're probably
(and perhaps justifiably) proud of. You say that wasn't a component of your
recommendation. I'm willing to accept that, not that I expect you to be
losing any sleep over whether or not I believe you.



The problem is that I am not promoting Metastorage because I am proud of 
it. Actually I do not promote any of my projects because of pride or any 
other ego related reasons. I wish some people did not guess that wrong, 
but I admit that sometimes it is hard to make certain intentions clear.


I let others know about my projects because that helps maximizing the 
chance of getting valuable feedback from potential users like bug 
reports and feature suggestions. This is good for me because ultimately 
I also benefit from any improvements done on my projects due to user 
feedback.


Anyway, it would be pointless for me to let other people know about 
projects of mine that do not address their needs, as that would not 
raise their interest.


What I am trying to tell you is that while I may not be clear enough, I 
was trying to tell the original poster how Metastorage solves the 
problem he wants to solve. That does not mean he will be interested to 
use Metastorage, but at least it may raise his interest in studying how 
Metastorage solve his problem. If he will become interested in 
Metastorage later, I am not concerned. If he will, fine, if he doesn't, 
no problem either.





Thank you for the extra explanation. I still don't understand the comment's
relevancy to the actual question being asked by the original poster, but I
will explain, in case it's of interest, why that comment caused me some
confusion:

- The original poster outlined that he had created a class that represented
a customer.

- He told the list he was having difficulties with the concept of
abstracting a collection of customers

- He received some helpful suggestions from the list about how to approach
that task

- None of which would have meant he was 'trying to retrieve objects into
memory before they exist.' I don't know about anyone else, but what that
comment implied to me was that the original poster was attempting to
instantiate a class as an object before including the file that contained
the class definition.


No, that was not my point. My point is that if you want to get a 
collection of customers, you want a list of objects that may contain 
more than one. Therefore what represents better a list of objects of 
some class, is not an object of a class, but rather an array eventually 
created by a factory object.


I do not think it does not make much sense that the factory object be of 
the same class of the list of objects that you want to retrieve. So, 
first you create the factory class object and then it will retrieve the 
customer objects into an array. What he was doing is to make the 
customer class a factory for a collection of its own objects.


I am not sure if my comment is clearer now.

--

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

Re: [PHP] Re: Suggestions for class design

[Manuel Lemos]

Hello,

on 09/20/2005 10:04 AM Michael Sims said the following:

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 see your point, but I'm not so sure I agree fully.  Manuel suggested
Metastorage (which makes sense, it's his project and he's most
familiar/comfortable with it), I suggested Propel because that is what I've
used.  I think we both suggested existing ORM's for the same reason...
namely that properly implementing a full featured ORM is an extremely
difficult thing to get right.  I don't know anything about Chris's skill as
a programmer, but he's bound to reinvent the wheel several times over, and
poorly to boot.  I believe that implementing an ORM is one of those things
that you cannot fully understand and appreciate until you've tried to do it
and failed.  IMHO it's only after you've built one that you realize what you
really need, and by then it needs to be rebuilt.  It's kind of like Fred
Brook's "plan to throw one away; you will, anyhow", or at least it was for
me.


Right, I could not have said it better, especially the part about people 
that prefer to break their heads trying to do something that others have 
done, providing much more mature solutions.


I am including myself in that group of people. 3 years ago I started 
developing Metastorage but only after have looked at several solutions 
and learned they had too many deficiencies to be adopted. That study 
helped me realizing what would be the important design mistakes to avoid.




Another thing I had
done halfway was support for querying objects (without using SQL).
Basically I had created different types of criteria that could be used, but
my support for criteria wasn't general enough.  IOW, if I didn't forsee that
you would want a particular type of criteria, then you couldn't use it.
Propel gets this right by supporting any arbitrary criteria using their
Criteria object approach (and I'm sure Metastorage has similiar
functionality).  If you can represent it using SQL, you can represent it
using Propel's Criteria.


Metastorage provides its own OQL (Object Query Language). This means 
that you can define functions for your ORM to query objects and 
associate a search expression using that OQL. Metastorage compiles that 
expression into SQL at code generation time, that may include parameters 
to be passed to the function at run time.


This way the code generated by Metastorage does not waste time or memory 
building the SQL search clause at runtime, because all query decisions 
are antecipated at run time. This results in fast code that is very compact.




I think it's important to point out, however, that I have learned just as
much from using Propel as I did from creating my own ORMI didn't just
simply drop Propel into place and run with it.  First of all, I modified it
a good bit to work better for my environment.  Secondly, as a general rule I
don't incorporate any third-party code/libraries into my codebase without at
least doing a cursory review through the code.  Since I was particularly
interested in how this problem was solved, I investigated it more thorougly
than I normally would.


Right. I feel that I need to clarify that Metastorage approach seems to 
be very different from Propel. Metastorage generates self-contained code.


This means that it generates code that does not depend on extra 
libraries to perform its function, which is ORM. Of course it uses 
Metabase to access the database but Metabase does not implement the base 
ORM functionality. Other than that, Metastorage generated code does not 
depend on anything else.




Now, with all that said, it's possible that Chris isn't to the point where
he would benefit much from plugging in another ORM...in order to learn from
someone else code you at least have to have a basic understanding of the
problem they are trying to solve, or it will all be greek to you.  And if
that's the case then you're right, it might hurt more than it will help.  So
let me amend my recommendation by saying "check out Propel/Metastorage if
you're willing to actually study the approach it takes as opposed to simply
plugging it in". :)


Right, regardless of what Chris decide, my suggestion was not to use 
Metastorage but rather take a look first to what generates. Metastorage 
generated code even comes with comments so it easier to understand what 
it does and why.



--

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 ge

RE: [PHP] Re: Suggestions for class design

[Chris W. Parker]

Murray @ PlanetThoughtful 
on Tuesday, September 20, 2005 8:15 AM said:

> And it's also worth mentioning at this point that it might present
> more of a challenge to the original poster to implement and make use
> of a complex data abstraction package [1] than to learn a solution
> that not only addresses his specific question but also helps in his
> learning as a programmer.

Yep. You got it.

Basic building blocks are much better for me than taking an already
mature system and shoehorning it into my app, or rather, shoehorning my
app into it.


Chris.

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

RE: [PHP] Re: Suggestions for class design

[Michael Sims]

Murray @ PlanetThoughtful wrote:
> My post was not aimed at saying 'using packaged approaches to solve
> coding problems is bad', but to say 'the original poster is asking a
> fundamental learning question, so a packaged approach will possibly,
> maybe even probably, hamper his development as a programmer at this
> point.'
[...]

Gotcha.  Makes sense; thanks for explaining...

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

RE: [PHP] Re: Suggestions for class design

[Murray @ PlanetThoughtful]

> > 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 see your point, but I'm not so sure I agree fully.  Manuel suggested
> Metastorage (which makes sense, it's his project and he's most
> familiar/comfortable with it), I suggested Propel because that is what
> I've
> used.  I think we both suggested existing ORM's for the same reason...
> namely that properly implementing a full featured ORM is an extremely
> difficult thing to get right.  I don't know anything about Chris's skill
> as
> a programmer, but he's bound to reinvent the wheel several times over, and
> poorly to boot.  I believe that implementing an ORM is one of those things
> that you cannot fully understand and appreciate until you've tried to do
> it
> and failed.  IMHO it's only after you've built one that you realize what
> you
> really need, and by then it needs to be rebuilt.  It's kind of like Fred
> Brook's "plan to throw one away; you will, anyhow", or at least it was for
> me.

Hi Michael,

You've hit on a point that I implied in my original post, but should have
been more explicit about. If I can add some emphasis: * IMHO it's only after
you've built one that you realize what you really need *

I couldn't agree more. As I read and understand the original poster's
question, he is still in the 'building one' phase of his development as an
OO PHP coder. If this wasn't the case, I doubt he'd be asking the question
he asked.

My post was not aimed at saying 'using packaged approaches to solve coding
problems is bad', but to say 'the original poster is asking a fundamental
learning question, so a packaged approach will possibly, maybe even
probably, hamper his development as a programmer at this point.' Put another
way, working out how to implement a class to handle the question he asked
would not be incredibly challenging, particularly with the help and advice
of people on this list, and would add to his understanding of how OO works
generically and in PHP. Both very good things.

I use several package solutions in my own projects. Notably, MDB2 and
HTML_QuickForm. I use MDB2 because it means my projects can be more flexible
to any decisions made to change the backend storage technology. I use
HTML_QuickForm because it provides convenient methods to building forms, and
it minimizes the mixture of HTML and PHP code in my pages, something I
personally prefer. Having said which, before adopting either of these
packages I was satisfied that I understood how to achieve the same results
using nothing more than my own coding skills. 

In other words, as a programmer I am comfortable working directly with a
variety of data storage backends, employing classes to abstract different
collections of data objects. I am comfortable building, validating, and
processing forms. The packages I use are for convenience, rather than
placing me at arm's length to understanding the programming concepts and
needs they address.

Also, I don't disagree that there are some brilliant packages out there,
written by people who've taken time to learn more about a specific problem
or set of problems than the average programmer would have to spend,
particularly across the broad range of coding demands an application may
touch upon. Again I reiterate: using packages to address application needs
is not a bad thing, while avoiding learning the basics of programming by
using such packages almost certainly is, particularly if you're taking your
development as a programmer seriously, and consider yourself to be aiming at
becoming a 'professional' programmer.

[here there be snippage]

> My point is, I had implemented my own home grown ORM about 3-4 times, and
> while each one was much better than the one that preceded it, I still
> wasn't
> quite all the way towards a 100% general implementation.  That's when I
> found Propel.  It got so many things right that I hadn't figured out how
> to
> solve, as well as implementing things that I hadn't even considered yet.
> 
> Now, you could argue that going through all those iterations and
> refactoring
> my own ORM helped me to improve my skills as a programmer, and you would
> be
> right.  That's where I agree with you, somewhat. :)  However, I was many
> many iterations away from improving my ORM to the point where it would be
> as
> useful as Propel (and that's assuming it would ever be that useful).  The
> guys who developed it (and I'm sure the same goes for Manuel and
> Metastorage) concentrated on making the best general purpose ORM they
> could
> make.  IOW their whole goal was to build an ORM, while my goal each time
> was
> to develop one for 

RE: [PHP] Re: Suggestions for class design

[Murray @ PlanetThoughtful]

[snippage]

> 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.

Hi Manuel,

I did make my recommendation. To you. It went something like (and I'm
paraphrasing), "Your proposed solution doesn't solve the original poster's
conceptual problem with abstracting classes that deal with collections of
objects in conjunction with classes that abstract single objects."

In other words, and I realize I'm stretching out on a limb with this
metaphor, I saw in your post an attempt to treat the symptoms without
offering a cure for the disease.

Actually, that really is a terrible metaphor. I'm certain I'll think of a
better one about 3 seconds after I hit 'send'. Isn't that always the way?

And your perception of bias may or may not be accurate. I don't recall
delivering wrath-of-god denunciation of your suggestion to use a project you
developed, just acknowledged a desire to promote a project you're probably
(and perhaps justifiably) proud of. You say that wasn't a component of your
recommendation. I'm willing to accept that, not that I expect you to be
losing any sleep over whether or not I believe you.

This is a reality of expressing opinions on a public list: others are free
to disagree with you. See Michael Sims' response to the same post you're
addressing here. He makes some great points and I for one am glad he had an
opportunity to make them in response and counterpoint to a post I made. His
thoughts enrich the list, as do yours, and as, I hope, do mine.

> > 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.

At some point I just may do that. It's an interesting concept, if nothing
else. My comments remain relevant, however, regardless of my knowledge of
your project. At least, and this is important, that's my opinion.

> > 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.

Thank you for the extra explanation. I still don't understand the comment's
relevancy to the actual question being asked by the original poster, but I
will explain, in case it's of interest, why that comment caused me some
confusion:

- The original poster outlined that he had created a class that represented
a customer.

- He told the list he was having difficulties with the concept of
abstracting a collection of customers

- He received some helpful suggestions from the list about how to approach
that task

- None of which would have meant he was 'trying to retrieve objects into
memory before they exist.' I don't know about anyone else, but what that
comment implied to me was that the original poster was attempting to
instantiate a class as an object before including the file that contained
the class definition.

I may well have misunderstood what you meant by your comment, but it still
stands out as not being relevant to the problem the original poster was
describing.

Much warmth,

Murray
---
"Lost in thought..."
http://www.planetthoughtful.org

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

Re: [PHP] Re: Suggestions for class design

[Manuel Lemos]

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 th

Re: [PHP] Re: Suggestions for class design

[Jochem Maas]

Michael Sims wrote:

Murray @ PlanetThoughtful wrote:


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.



I agree with this.



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 see your point, but I'm not so sure I agree fully.  Manuel suggested
Metastorage (which makes sense, it's his project and he's most
familiar/comfortable with it), I suggested Propel because that is what I've


...



Sorry, I didn't mean to ramble on that long... :)


no need, very good piece of writing on the subject matter imho!





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

RE: [PHP] Re: Suggestions for class design

[Michael Sims]

Murray @ PlanetThoughtful wrote:
> 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.

I agree with this.

> 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 see your point, but I'm not so sure I agree fully.  Manuel suggested
Metastorage (which makes sense, it's his project and he's most
familiar/comfortable with it), I suggested Propel because that is what I've
used.  I think we both suggested existing ORM's for the same reason...
namely that properly implementing a full featured ORM is an extremely
difficult thing to get right.  I don't know anything about Chris's skill as
a programmer, but he's bound to reinvent the wheel several times over, and
poorly to boot.  I believe that implementing an ORM is one of those things
that you cannot fully understand and appreciate until you've tried to do it
and failed.  IMHO it's only after you've built one that you realize what you
really need, and by then it needs to be rebuilt.  It's kind of like Fred
Brook's "plan to throw one away; you will, anyhow", or at least it was for
me.

I think the whole DAO/ORM approach is something that most programmers who
are fans of OO stumble into as part of their natural development.  I know
that in my earlier projects I had implemented some type of this pattern
without fully realizing that I had done so.  It's just natural to consider
at some point that you should represent entities in your database as objects
(if you're an OO proponent).  In one of my earlier PHP projects, I
implemented a very basic ORM that represented only single entities and
didn't quite handle multiple entities very well, or the relationships
between entities (this seems to be where Chris is currently).  Then for the
next project I added better support for multiple entities and relationships,
but it was a half implementation, because I didn't represent the related
entities as full objects (for example, if a Customer has a list of phone
numbers, I had the Customer object return them as an array of strings rather
than an array of PhoneNumber objects).  I also had no support for recursion
when saving or updated objects (for example, in Propel, you can create a new
Customer object, create 5 new PhoneNumber objects, attach them to the
customer, then call the save() method on the Customer and it will recurse
through all attached objects, saving each of them).  Another thing I had
done halfway was support for querying objects (without using SQL).
Basically I had created different types of criteria that could be used, but
my support for criteria wasn't general enough.  IOW, if I didn't forsee that
you would want a particular type of criteria, then you couldn't use it.
Propel gets this right by supporting any arbitrary criteria using their
Criteria object approach (and I'm sure Metastorage has similiar
functionality).  If you can represent it using SQL, you can represent it
using Propel's Criteria.

My point is, I had implemented my own home grown ORM about 3-4 times, and
while each one was much better than the one that preceded it, I still wasn't
quite all the way towards a 100% general implementation.  That's when I
found Propel.  It got so many things right that I hadn't figured out how to
solve, as well as implementing things that I hadn't even considered yet.

Now, you could argue that going through all those iterations and refactoring
my own ORM helped me to improve my skills as a programmer, and you would be
right.  That's where I agree with you, somewhat. :)  However, I was many
many iterations away from improving my ORM to the point where it would be as
useful as Propel (and that's assuming it would ever be that useful).  The
guys who developed it (and I'm sure the same goes for Manuel and
Metastorage) concentrated on making the best general purpose ORM they could
make.  IOW their whole goal was to build an ORM, while my goal each time was
to develop one for the purposes of finishing whatever real project I
happened to be working on.  That meant they were closer to the problem, had
more experience with it, and were willing to do more to solve it more fully
and generally than I was.

Originally I intended only to look at the code they had created and learn
from it, using their ideas in my project.  I started that way for a few
days, but I realized that there was so much they had accounted for that I
didn't even think of that it would be better to simply use their tool rather
than trying to reinvent it.

I think it's important to point out, however, that I ha

RE: [PHP] Re: Suggestions for class design

[Murray @ PlanetThoughtful]

> on 09/19/2005 02:33 PM Chris W. Parker 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.

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.

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".

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.

Much warmth,

Murray
---
"Lost in thought..."
http://www.planetthoughtful.org

[1] And it wouldn't be the first time!

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

[PHP] Re: Suggestions for class design

[Manuel Lemos]

Hello,

on 09/19/2005 02:33 PM Chris W. Parker 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.


Metastorage is an persistent object class generator tool that lets you 
design your persistent object classes using a simple XML format that 
describes the classes, variables, validation rules, relationships and 
any functions that you may need to manipulate your objects.


Besides the persistent object classes, it also generates a factory class 
that takes care creating new objects from scratch or retrieve them from 
the database. The factory class makes sure that each object does not 
exist more than once in memory.


When you want to retrieve a collection of objects of the same class. You 
just add a function to the factory class to retrieve such objects, 
instead of calling the actual class of the objects your are retrieving.


You can also retrieve a collection of objects related to an object right 
from its class, for instance retrieving children objects of given parent 
object. In that case you would add a function to the parent object 
class, despite internally Metastorage implements that using calls to the 
factory class, which is itself a singleton.


Anyway, if you want to know more about Metastorage, you may find more 
information here:


http://www.meta-language.net/metastorage.html

There is a tutorial here:

http://www.meta-language.net/metastorage-tutorial.html

Some screenshots of the Web interface:

http://www.meta-language.net/screenshots.html




--

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