You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Marco Tedone <mt...@jemos.org> on 2003/05/11 19:42:45 UTC
Abstraction level
Noel, I'm thinking to group the configuration information in a java class. A
collection of those classes then can be filled by any methodology (as per
your suggestion).
This class would have three attributes:
a) recipient
b) size
c) uom (for future conversion to Kb and Mb if that is OK)
and then get/set methods to retrieve the value.
Is that ok for you?
Marco
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Abstraction level
Posted by "Noel J. Bergman" <no...@devtech.com>.
> You are correct on all your points, Noel, I'm sorry.
No need to apologize. And no need to agree with me unless you do. :-)
> I was wondering if in the init() method we should
> implement some code to return an array of
> Objects which contains the tokenized parameters.
Which init() method? The base class only needs to init the things that it
needs. Remember: it is an abstract class. A derived class would do
something like:
public void init() throws MessagingException {
super.init();
...
}
So your XML based matcher might do something like:
public void init() throws MessagingException {
super.init();
InitFromXML(getCondition());
}
Whatever you want to initialize from the XML is up to you. Personally, I'd
think about a HashMap.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Abstraction level
Posted by Marco Tedone <mt...@jemos.org>.
You are correct on all your points, Noel, I'm sorry. I was wondering if in
the init() method we should implement some code to return an array of
Objects which contains the tokenized parameters.
Marco
----- Original Message -----
From: "Noel J. Bergman" <no...@devtech.com>
To: "James Developers List" <ja...@jakarta.apache.org>
Sent: Sunday, May 11, 2003 9:25 PM
Subject: RE: Abstraction level
> > I think you forgot to abstract the getStorageAllowed(String user)
> > method.
>
> Correct. As I said, I hadn't even compiled it.
>
> > My class was also abstracting the way we get the UserInbox.
>
> What does that buy us? There would immediately be a base class that
> implements the current storage model, and then all other classes would
> inherit from there.
>
> > In any case I think for the implementation class you will
> > want to store the configuration information somewhere
>
> Perhaps, but that's up to the implementation class. In my view, you are
> mixing far too much implementation into the abstraction. Why do you need
> anything more than an abstract method that returns the quota for a given
> user?
>
> > the implementation class will fill that JavaBean with
> > the configuration information once per request and it
> > will need to iterate trough it for the following needs
>
> Why is the implementation class responsible to do anything more than
return
> the quota? It does not need to check the user's storage or compare the
> values. That is common behavior that can be provided by the base class.
>
> --- Noel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: james-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Abstraction level
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I think you forgot to abstract the getStorageAllowed(String user)
> method.
Correct. As I said, I hadn't even compiled it.
> My class was also abstracting the way we get the UserInbox.
What does that buy us? There would immediately be a base class that
implements the current storage model, and then all other classes would
inherit from there.
> In any case I think for the implementation class you will
> want to store the configuration information somewhere
Perhaps, but that's up to the implementation class. In my view, you are
mixing far too much implementation into the abstraction. Why do you need
anything more than an abstract method that returns the quota for a given
user?
> the implementation class will fill that JavaBean with
> the configuration information once per request and it
> will need to iterate trough it for the following needs
Why is the implementation class responsible to do anything more than return
the quota? It does not need to check the user's storage or compare the
values. That is common behavior that can be provided by the base class.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Abstraction level
Posted by Marco Tedone <mt...@jemos.org>.
I saw your code and it's more or less what I was going to do. The only thing
is that I think you forgot to abstract the getStoreageAllowed(String user)
method. My class was also abstracting the way we get the UserInbox. Today is
trough the ComponentManager, tomorrow will be trough something else (as per
your suggestion). In any case I think for the implementation class you will
want to store the configuration information somewhere(a group of
user/size/uom/etc.) which, the implementation class you will decide will
set. I thought to a JavaBean: the implementation class will fill that
JavaBean with the configuration information once per request and it will
need to iterate trough it for the following needs:
a) To verify if there are any configuration information
b) To verify if user storage exceeded the maximum allowed
I thought to solve this problem, by setting an iterator in the abstract
class, set only once, but used in both cases above.
I'm still writing the abstract class, but here enclosed you'll find what I'm
doing at present.
Hope the code won't be too bad.
Marco
----- Original Message -----
From: "Noel J. Bergman" <no...@devtech.com>
To: "James Developers List" <ja...@jakarta.apache.org>
Sent: Sunday, May 11, 2003 8:22 PM
Subject: RE: Abstraction level
> > I'm thinking to group the configuration information in a java class.
>
> That's fine, but why does that belong in the abstraction? Why do you want
> to force me to keep that information in memory? By presupposing the
> existence of configuration objects, you are already elaborating on the
> implementation. All that the abstraction really requires is the
> specification of an interface.
>
> Consider the attached. I haven't even tried to compile it. I'm just
> expressing the idea.
>
> --- Noel
>
----------------------------------------------------------------------------
----
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Abstraction level
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I'm thinking to group the configuration information in a java class.
That's fine, but why does that belong in the abstraction? Why do you want
to force me to keep that information in memory? By presupposing the
existence of configuration objects, you are already elaborating on the
implementation. All that the abstraction really requires is the
specification of an interface.
Consider the attached. I haven't even tried to compile it. I'm just
expressing the idea.
--- Noel