File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Placing interfaces and respective implementations in seperate packages Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Placing interfaces and respective implementations in seperate packages" Watch "Placing interfaces and respective implementations in seperate packages" New topic
Author

Placing interfaces and respective implementations in seperate packages

Jianping Wang
Ranch Hand

Joined: May 29, 2010
Posts: 60
put intefaces and implements in separate packages. Is this the right decision? The reason for this is I want client only know interfaces, and completely eliminate the possibility of client accessing server side classes.



SCJP 6 with 93%
Oracle Database SQL Expert with 98%
Carlos Morillo
Ranch Hand

Joined: Jun 06, 2009
Posts: 221

Hi Jianping,


I personally placed my BusinessService and RemoteBusinessService interfaces together with some other classes
in a domain package. My domain package is the core of all the business logic domain.

The class implementing BusinessService I placed it in a direct package together with some other classes.
My direct package has to do with local access.

The class implementing RemoteBusinessService I placed it a remote package.
My remote package has to do with network access through RMI.


HTH,


Carlos.


SCSA, OCA, SCJP 5.0, SCJD http://www.linkedin.com/in/carlosamorillo
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5266
    
  13

Jianping Wang wrote:The reason for this is I want client only know interfaces, and completely eliminate the possibility of client accessing server side classes.

And how are you planning to disallow client accessing a server side class? As far as I know the developer is the one who develops code, so if he accesses a server side class, there is nothing you can do about it.
I have 5-6 different packages and for classes which should only be used inside that package (like my Data class) have the default access modifier (so they don't actually have an access modifier ). So from another package (like my business service implementation) you can only access the interface, not the Data class (which is desired). I don't have seperate packages for interfaces and implementations, because with such a limited application as this one you'll may end up with more packages than source files


SCJA, SCJP (1.4 | 5.0 | 6.0), SCJD
http://www.javaroe.be/
Roberto Perillo
Bartender

Joined: Dec 28, 2007
Posts: 2265
    
    3

Jianping Wang wrote:The reason for this is I want client only know interfaces, and completely eliminate the possibility of client accessing server side classes.


I guess that, in order to achieve that, all you have to do is define an interface that extends Remote and exposes only the services you want. I think that will do the job.

Carlos Morillo wrote:I personally placed my BusinessService and RemoteBusinessService interfaces together with some other classes
in a domain package. My domain package is the core of all the business logic domain.


Hum... interesting. I'd just tell you to be careful not to mix the concepts: if you have a BusinessServices, then it is pretty likely that you have an anemic domain model (which is ok in this certification, since the logic to be implemented is very simple). If there was a domain model, then we could have, for instance, a class called Room implementing the logic of booking rooms. This modeling is more adequate when the domain logic is complex, so your way is more adequate. I'd just advise you to rename the domain package to services and put the domain package inside it, with your Room class (that is, your class that represents a room).

Did you implement any logic in your Room class, champion?


Cheers, Bob "John Lennon" Perillo
SCJP, SCWCD, SCJD, SCBCD - Daileon: A Tool for Enabling Domain Annotations
Carlos Morillo
Ranch Hand

Joined: Jun 06, 2009
Posts: 221

Roberto Perillo wrote:
Carlos Morillo wrote:I personally placed my BusinessService and RemoteBusinessService interfaces together with some other classes
in a domain package. My domain package is the core of all the business logic domain.


Hum... interesting. I'd just tell you to be careful not to mix the concepts: if you have a BusinessServices, then it is pretty likely that you have an anemic domain model (which is ok in this certification, since the logic to be implemented is very simple). If there was a domain model, then we could have, for instance, a class called Room implementing the logic of booking rooms. This modeling is more adequate when the domain logic is complex, so your way is more adequate. I'd just advise you to rename the domain package to services and put the domain package inside it, with your Room class (that is, your class that represents a room).

Did you implement any logic in your Room class, champion?


Roberto, What do you mean by anemic???
I am having a hard time understanding your views.


Roberto, I followed your advise in this thread
To follow your advice in that thread was anemic now?


My Room class is a value object and it has a couple of methods to convert Room<->String[].
We have already discussed this here

I also asked earlier about the Room class package location here
and from the responses I got they were too abstract and not very clear to me, therefore I left it in the domain package.

Anyway, it's already too late to change it since my assignment was submitted more than 5 weeks ago and
I still don't see any clear explanation why should I change it.


Roberto Perillo
Bartender

Joined: Dec 28, 2007
Posts: 2265
    
    3

Howdy, Carlos!

Well champion, one good reading about the "anemic domain model" concept can be found here.

When we have a rich domain model, we have a totally object-oriented structure, where entities concentrate most of the logic implemented in the application. In this case, we could have a class called Room that could be like this:



The idea is that you have a model of objects where most of them have attributes and behavior and domain logic is spread accross these objects. This is the domain model (which reflects the model, that is, your abstraction of the domain). This type of modelling requires another style of architecture, which can be achieved with the Domain Model pattern. This pattern suggests a structure where you can implement the domain model. This pattern is specially useful when the domain logic is complex.

Another pattern that is heavily used in the industry is the Transaction Script pattern. In this pattern, your entities are anemic and the business logic is concentrated in service classes, where each method of each service class handles a request from the presentation layer. Each method is called "transaction script". They handle the business logic and use dumb objects (DTOs) to pass values back to the presentation layer.

The early J2EE literature used the term Value Object to refer to DTOs. DTOs are dumb objects that exist only to transport values from one layer to the other. Value objects are essentially objects that do not have an identity and, once created, cannot have their values changed.

Now, in the context of this assignment, having transaction scripts is more adequate then having a rich domain model, because the domain logic is very simple. If the domain objects (such as the Room object) will not have domain logic, then we have an anemic domain model.

In conclusion, my point of view is that, in the context of this assignment, Transaction Script are more adequate then a rich Domain Model.
Carlos Morillo
Ranch Hand

Joined: Jun 06, 2009
Posts: 221

Roberto,


Thanks for the information, but this is not a J2EE development project.
You just need to use J2SE.

In the Head First Design Patterns nowhere in the book a Transaction Script pattern is mentioned.

I do appreciate the information and I know in the future this can be very valuable, but
many of this information in my view when you mention it and present it gets very confusing.

I am sure what you are saying about all this patterns and entities is valid in the J2EE space, but
it is my understanding as far as I know that J2EE patterns like the ones you mention are not part
of the goals of the SCJD certification and it gets very confusing here.



Best,


Carlos.
Roberto Perillo
Bartender

Joined: Dec 28, 2007
Posts: 2265
    
    3

Carlos, just to clarify, these concepts I addressed are free of technology: they can be used in a JSE application or in a JEE application. I just mentioned "JEE" in the text above because you said Value Object, and usually people say "Value Object" when they mean "Entity".

But you'll do well if you follow the approach I proposed in the thread you mentioned in your post above (which is based on the Transaction Script pattern).
Carlos Morillo
Ranch Hand

Joined: Jun 06, 2009
Posts: 221

What about the packages location of some classes?

That was the original question Jianping had instead of this diversion to J2EE patterns.
Roberto Perillo
Bartender

Joined: Dec 28, 2007
Posts: 2265
    
    3

Carlos Morillo wrote:What about the packages location of some classes?

That was the original question Jianping had instead of this diversion to J2EE patterns.


Sorry for trying to help you add some value in your assignment.

I thought I had already answered this in my first post in this thread.

And again, these concepts are free of technology: they can be used with JSE or JEE. And by the way, these are not GoF patterns. They can be found in Martin Fowler's Patterns of Enterprise Application Architecture book.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Placing interfaces and respective implementations in seperate packages