Good name (or maybe a pattern) for a client-side data accessor

Question

Hello,
I am building a client/server app, the client is a Swing application.
The client needs to read/write information to the server. I have a set of "DAO" classes that encapsulate remote acces:
package myapp.client;
public class OrderDAO {
    public OrderDTO getDaylyOrders();
    public void saveOrder(OrderDTO order);
}The implementing class connects to an RMI server which exposes an OrderService interface with more technical methods (getOrdersForDate(Date), getPendingOrders(),...).
I just feel the name DAO is misleading on the client side, because traditionnally it is a server-side pattern, and indeed in the myapp.server package, I have a set of classes named OrderDAO as well, which do what I think is the usual work of DAOs (mask the usage of the DB to the server logic).
I'm wondering whether my client-side "DAO" actually follows the intent of the DAO pattern. Otherwise what is it, or how should it be named?
Isn't it a BusinessDelegate instead, as it encapsulates the usage of the OrderService?
Note that it is not just a Proxy to the server-side DAO class, because there is a bit of sever-side business logic (filtering and aggregation by the OrderService) between what the server side DAO returns (essentially Lists of entities mapped from the database tables) and what the client-side "DAO" returns.

Answer 1

It has been a while for me, but when I designed
applications I favored using some part of a design
patttern name for the main class of the pattern. For
Business Delegate objects, using the "Delegate" part
is helpful if there will ever be other software
develoeprs working with the code. Even if not, it
will help you remember the design when/if you return
to it in a few years or so.I see where you are coming from here but I think that this doesn't really hold up under scrutiny and from my paast experience. First of all, it's not feasible to rely the design with class names. You'll end up with something similar to Hungarian notation if you try. This means that you must have external design documents. It's tempting to think that classnames and JavaDocs will be enough but they aren't. They are necessary but not sufficient.
When I talk about the 'users of the class' I'm talking about other developers. The 'users of the application' don't see the classes. My experience is that naming classes or anything else with notes about it's internal implementation seems like it would be helpful but is of limited usefulness to maintenance developers. For most work the developer is only going to care what the class does (e.g. retreieve business objects) not how it does it. If the developer need to know that, they can easily open the class documentation and even the source (assuming that's available.
If you do end up doing this, you also need to think about what will happen if you change the design under the hood of the class. Do you change the name of the class? You really should, if it's name is based on the design. What I've seen happen too often is that it does not happen and the class is named as it if does one thing but acutally does something else entirely.
OrderServiceDelegate would be an informative
name because it would imply that the actual code for
implementing the "order service" is in another class
and that this class is for "delegating" only.That's easily determined by looking at the class documentation and like I said above, doesn't usually matter to other classes using it. That's one of the main tenets of OO design. Separation of concerns. The classes that use this shouldn't need to know how it does it's job (althought, this is not always feasible IMO.) If the classes depend on a BusinessDelegate, then what do you do if you move the class to an environment where they use the Facade directly, for example. You are in effect coupling related classes to a pattern. If I have a FooRetriever, I might want one that's a business delegate, one that's a DAO and one that is a stub. The idea of coupling an interface to a pattern is strange to me.
For implementations of the Abstract Factory pattern,
I typically would include the term "Factory" in the
class name. Same goes for Facade and Proxy. Factory classes are the most likely misnamed. Often implementations of factories (I know that's not a GoF pattern) or abstract factories are named FooBarSingleton. So, if anything, don't name Singleton classes with the word Singleton.