In this case, I think the 'it depends' hinges on what that ignored
field is. In any case, A.x's elements are going to have field e in
them. The question is whether both A and B are refering to the same P
entities. If so, then you should use a single P object. If they're
different entities,
I would _try_ to have a uniform approach so that a P object is always a P
object, not P.1 and P.2
As long as the logic is has a property that might not be used instead of
might have a property that will be used,
then I would say you dont have a problem.
-Original Message-
From: [EMAIL
i'm not sure this is clear for me, but depending of context, you can:
1)inerhit class b frm a,
or
2)apply a decorator pattern
regards
salvatore
- Original Message -
From: Douglas Knudsen [EMAIL PROTECTED]
To: cfcdev@cfczone.org
Sent: Thursday, September 15, 2005 6:16 PM
Subject:
say teh properties of P are
m = username
n = userid
o = List of HR actions
No, sometimes I I want to just build a report involving Ps and only
need username and userid. Other times I may need one instance of P
that has the list of HR actions.
In short, I;m wondering if I can avoid having
A P is a P. If you don't use all the properties of a P, that doesn't
change what it is. Don't use inheritance, don't use multiple
versions, just use a single P class, and use what pieces you need from
it for each task.
cheers,
barneyb
On 9/15/05, Douglas Knudsen [EMAIL PROTECTED] wrote:
say
that's what I was thinking too. If I tie up my right hand, I may not
be as agile as James Gosling and my spelling would probably be 100%
better, but I am still a Person.
As an aside, this thread was technology independent! neat.
thanks!
DK
On 9/15/05, Barney Boisvert [EMAIL PROTECTED] wrote:
Douglas,
You may not need P objects at all. Instead, have you considered plain
ol' queries? Instead of an array of object, x could be a query with
columns m and n, and y could be a query with columns m, n, and e.
Like Barney, I prefer one class instead of two classes. But zero
classes is even
yeah, a plain old query result in CF already provides encap and
fulfills one of those uber popular patterns too.
My question though was a bit more aesthetic. In fact, I'm working on
a Java POJO set for a Flex front end. :) Felt it was ok to ask here
as it was a generic question that can be
yeah, a plain old query result in CF already provides encap and
fulfills one of those uber popular patterns too.
A ColdFusion query is a data structure. It doesn't provide any meaningful
encapsulation. The reason you'd return a query from your Gateway and loop
over it in your presentation tier
