Shopping service design

[Ali_RS]

Hi

For in-game item shopping, I need two services (interfaces).

1- A REST service that gets item lists, their prices, and special offers from the REST server (master server) using the Retrofit library.

2- An RMI service that buys the item. It calls the game server to create the entity and add it to inventory.

I am not sure how to come up with naming conventions for these interfaces. Sorry if sounds stupid

• To name both ShoppingService and put one inside the net.rmi package and the other inside the net.rest package?

• To name one ShoppingRmiService (?) and one ShoppingRestService (?) and put them both inside the net package?

• To name one ItemBuyService and one ItemListService and put them both inside the net package?

or any other suggestions?

Regards

[xuan]

Depends on your package naming convention.

If you did package-by-feature you’d have them both in the same package x.y.x.shopping.
More about that: Java Practices->Package by feature, not layer

[pspeed]

Sometimes when we have “what package does this go in?!?!” style problems, the best course of action can be to defer the decision. Often if you haven’t even implemented it yet then you aren’t really sure what will be similar or different, how painful it will be to use if you split different things out.

Implement it all in one package but keeping in mind to use good compartmentalization. Don’t make an “interface” unless it’s going to have multiple implementations, etc… Don’t assume two things are going to be different implementations of the same interface just because “they do similar but different things”. Make methods do what they say and say what they do. (For example, if getListOfFoo() is really getListOfFooAndUpdateCounts() or whatever then probably there is an API problem). And so on… basically just good design choices. Think about testability if you wanted to write unit tests. (Can you mock things to test real units, etc.)

And as you get things working, likely those choices will change anyway. When it’s all working from front to back, you can then start to apply organizational and package ideas to it and move them around.

At that point a different set of questions is important:
is every user of interface X going to need implementation Y? (factors into .jar separation concerns)
is every user of thing X going to always need to import these three packages? (factors into package splitting)
if I replace implementation Y with implementation Z am I going to have to surgically remove 50 classes one at a time or can I just delete this directory?
…sometimes the answers to those questions will even compete with one another.

And there are personal philosophies and conventions involved in that as much as anything else. I’ve waffled on this a few times even within my own designs.

[Ali_RS]

Thanks for the help.