Brandon Mercer wrote:
Larry Meadors wrote:
On Tue, 1 Feb 2005 21:09:46 +0100, PA <[EMAIL PROTECTED]> wrote:
Static inner classes, static. Those are simply an extension of the
namespace. Contrast this with the sorry freak of nature which are plain
inner classes.
HAHAHAH! I just inherited some
Larry Meadors wrote:
On Tue, 1 Feb 2005 21:09:46 +0100, PA <[EMAIL PROTECTED]> wrote:
Static inner classes, static. Those are simply an extension of the
namespace. Contrast this with the sorry freak of nature which are plain
inner classes.
HAHAHAH! I just inherited some code with a pile of
On Feb 01, 2005, at 21:16, Larry Meadors wrote:
HAHAHAH! I just inherited some code with a pile of inner classes, and
I have to say I agree with you on that "sorry freak of nature"
comment. Still not sure I dig static ICs, but am willing to give them
the benefit of the doubt...for now.
Static inner
On Tue, 1 Feb 2005 21:09:46 +0100, PA <[EMAIL PROTECTED]> wrote:
> Static inner classes, static. Those are simply an extension of the
> namespace. Contrast this with the sorry freak of nature which are plain
> inner classes.
HAHAHAH! I just inherited some code with a pile of inner classes, and
I h
On Feb 01, 2005, at 21:03, Larry Meadors wrote:
Something like that, yes. I have never been a fan of inner classes,
Static inner classes, static. Those are simply an extension of the
namespace. Contrast this with the sorry freak of nature which are plain
inner classes.
but that is still the idea
Something like that, yes. I have never been a fan of inner classes,
but that is still the idea.
On Tue, 1 Feb 2005 18:55:15 +0100, PA <[EMAIL PROTECTED]> wrote:
>
> On Feb 01, 2005, at 18:23, Larry Meadors wrote:
>
> > I think I'd use a strategy pattern for this. Basically, one interface
> > wi
Actually, I'd keep the decision out of the Action, too.
I would create a TransactionHandler class that does it. You pass it
the information, and it returns information back - it should know
nothing about your web front end, and your web front end should know
as little as possible about the busine
On Feb 01, 2005, at 18:23, Larry Meadors wrote:
I think I'd use a strategy pattern for this. Basically, one interface
with several implementations; the implementation is dynamically
selected at runtime, based on the tranaction type.
Perhaps something like this?
http://dev.alt.textdrive.com/file/pl/
So check to see what type of transaction it is in the Action and then
send it to the corresponding method in the data class? Sounds good,
Brandon
Larry Meadors wrote:
I think I'd use a strategy pattern for this. Basically, one interface
with several implementations; the implementation is dynamic
I think I'd use a strategy pattern for this. Basically, one interface
with several implementations; the implementation is dynamically
selected at runtime, based on the tranaction type.
Larry
On Tue, 01 Feb 2005 12:19:03 -0500, Brandon Mercer <[EMAIL PROTECTED]> wrote:
> Ok, I've officially NOT fo
Ok, I've officially NOT followed some standard somewhere. :-( Shame on
me! Can somebody help me with the following predicament? I've got a
table of transactions that need to be processed. In that table I have a
column for that persons account number... which gets assigned in a
different ta
11 matches
Mail list logo