Enterprise Application design using java interfaces
Hi
Are the following design principles correct in the case of designing enterprise application with java interfaces:
1. create interfaces to all the application boundaries and controlls and entities.
2. the method parameters must be specific objects instead of interfaces.
If so, will this pose a problem in case of access that method reflectively passing an object that implements the interface as method parameter?
3. the return type in the method signature can be a interface.
4. In case of composition (if a class need to store the reference of another class as class or instance variable) should the reference type be an interface or superclass(if any)?
5. Value object/data access object need not have a corresponding interface.
Thanks in advance.
> Hi
>
> Are the following design principles correct in the
> case of designing enterprise application with java
> interfaces:
>
> 1. create interfaces to all the application
> boundaries and controlls and entities.
Depends on what you call boundaries. I'd say services and persistence layers benefit from interfaces.
Entities, as in model classes? Not necessarily.
> 2. the method parameters must be specific objects
> instead of interfaces.
Not sure what you mean here. When you pass in a reference to an object, it's specific. If it declares its static type as an interface there's no harm done. It might be just what you need.
Look at java.io package. You pass in java.io.InputStream in a lot of places. Is your rule saying that's wrong? I'd say your rule is wrong, if I interpret it correctly.
> If so, will this pose a problem in case of access
> that method reflectively passing an object that
> implements the interface as method parameter?
>
> 3. the return type in the method signature can be a
> interface.
Why not? If it's a factory, then that's the right thing to do.
> 4. In case of composition (if a class need to store
> the reference of another class as class or instance
> variable) should the reference type be an interface
> or superclass(if any)?
If that's your intent, yes.
>
> 5. Value object/data access object need not have a
> corresponding interface.
VO? True. DAO? Wrong, wrong, wrong.
These rules are so ridiculous they're not worth answering. Where did you get them?
There's danger in citing rules like this. Better to know the rules and when they can and should be broken. Sounds like you're trying to assemble a cookbook of some kind to substitute for real knowledge.
%
These were some of the guidelines set for the projects by the architect team in one of my previous projects.
I started this email thread to know the valid guidelines if any, for the usuage of interfaces.
Thus I would be curious to read related articles if any.
Your help in this regard is appreciated.
Thanks in advance.
> These were some of the guidelines set for the
> projects by the architect team in one of my previous
> projects.
I hope they fired that team.
> I started this email thread to know the valid
> guidelines if any, for the usuage of interfaces.
The thing is that it's a big subject, and I'm not sure that there's an agreed upon set of guidelines.
> Thus I would be curious to read related articles if
> any.
>
> Your help in this regard is appreciated.
>
> Thanks in advance.
My best advice, if you're doing web-based apps that access relational databases, is to start looking into Spring:
http://www.springframework.org
The framework is good, but the design recommendations are worthwhile on their own.
%
So the thread that would not die - almost did?
> So the thread that would not die - almost did?Lovely.~
> Hi
>
> Are the following design principles correct in the
> case of designing enterprise application with java
> interfaces:
>
yes, they are very good.
> 1. create interfaces to all the application
> boundaries and controlls and entities.
>
so that the client code and server code could have a good clear way of interaction.
> 2. the method parameters must be specific objects
> instead of interfaces.
yes. this is mostly for the benifit of less to compile. the compiler can check on a class that it does have implementations of what is required by the interface but it does not check on im[plementation details, meaning the class may an empty method signature and can not be found at compile time. so it is a waste if you declare a param list using interface types.
> If so, will this pose a problem in case of access
> that method reflectively passing an object that
> implements the interface as method parameter?
>
there is no difference here.
> 3. the return type in the method signature can be a
> interface.
>
yes. this usually gives you a broader flexibility for the client code.
> 4. In case of composition (if a class need to store
> the reference of another class as class or instance
> variable) should the reference type be an interface
> or superclass(if any)?
>
more flexibility.
> 5. Value object/data access object need not have a
> corresponding interface.
>
value objects are half objects, they should all be public, no interface is necessary.
this is beyond duffymore's comprehension, he is a dba:)
> his is beyond duffymore's comprehension, he is a dba:)
Spoken without irony by the person who thinks in all apparent seriousness that "ialod" and "iastor" are Java VM instructions and that the null reference points to a "null object".
Be wary of taking Java advice from daFei. He hasn't the faintest clue how Java works, but likes to pretend he has lots of valuable advice.
~
