Good name (or maybe a pattern) for a client-side data accessor
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;
publicclass OrderDAO{
public OrderDTO getDaylyOrders();
publicvoid 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.
[1654 byte] By [
jdupreza] at [2007-11-26 16:06:24]
# 2
Good point.
Additionally it made me rethink the design: the "client" DAO should simply delegate the call to the OrderService, which itself should be a facade, and split the business method into several technical calls to maybe specific objects.
Not that a Facade should necessarily be on the server side, but in my cas it makes sense.
In this scenario the client class becomes merely a Business Delegate, as described this thread: http://forum.java.sun.com/thread.jspa?threadID=757540&tstart=0
How to name a Business Delegate class: OrderServiceBusinessDelegate?
Or is BD as in OrderServiceBD widely understood as "Business Delegate"? I fear not.
# 3
> How to name a Business Delegate class:
> OrderServiceBusinessDelegate?
> Or is BD as in OrderServiceBD widely
> understood as "Business Delegate"? I fear not.
I personally don't like initialisms in class names. I am also not sure it's a good idea to label classes based on the Patterns they implement. You should document it in the class comments and any other documentation you create about your design but if the users of this class don't need to know that it's a business delegate, is it helpful to throw it in their face? I'm not real firm on this and could probably be convinced otherwise. I just worked on a project where every value object class ended with VO and it was more distracting than helpful to me. I like classes to be named for what they represent and/or do from the perspective of the external 'world' and not how it is designed internally.
# 4
Actually, instead of Facade, I should have said Proxy which is basically what the business delegate is IMO.
# 5
> How to name a Business Delegate class: OrderServiceBusinessDelegate?
> Or is BD as in OrderServiceBD widely understood as "Business Delegate"? I fear not.
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. 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.
For implementations of the Abstract Factory pattern, I typically would include the term "Factory" in the class name. Same goes for Facade and Proxy.
The names of the classes of an application don't have to be understood by the users of the application. They only should be intuitive to other software developers that may work with the application in the future.
As dubwai mentioned, it is good to name business objects with names for what they represent in the "real world". This helps to understand the application from what it does and how it relates to the requirements it implements.
It is important to distinguish between service-level objects and business objects, however. For service-level objects, it is helpful to name them appropriately, possible including some part of the design pattern they implement, if any, in my opinion.
An example of a service-level object would be a Business Delegate or Proxy. An example of a business object would be a CheckingAccount or SavingsAccount.
# 6
> 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.
# 7
> 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.
Yes, external documentation including narrative text is typically required for good enterprise-level software design, and demonstrates that an application was well-thoughtout. The context here is large enterprise applications. UML diagrams along with the narratives are a plus.
> 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.
My comments were NOT in reference of maintenance developers, I was writing towards major revisions of application code with drives towards adding new features and the like. You are right, a maintenance developer does not need to know much about the design. However, a recently hired software architect might require this knowledge if they are to enhance an existing application. Again, the context is a large enterprise application.
> 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.
Yes, if you change the design (and the implementation) you should not use the old names if they are not appropriate. This is basic.
> 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.
Misnaming classes is a human error. In the context of this discussion, you points are valid for some enviroments with certain parameters. In my experience, you would not just move one class. Here I'm talking about major reengineering. Moving one class is trivial. Not all classs names should reflect the design pattern they are apart of. My point was that it is good to name "some" classes with a part of the design pattern, not all. Deciding what that "some" is should be depends on many things.
Singletons should be banished from existence and are not part of anything related to enterprise software design with design patterns. The education of Singleton is for old college professors that haven't written any code since 1970. They jump to teaching the Singleton design pattern because it is easy, very non-object-oriented, and can easily be comprehended by basic structured programmers, i.e. birds that don't know :o) Where is dynobird these days?
# 8
You didn't really address the heart of my point. If you end up with multiple implementations of this interface that you have named FooBusinessDelegate that are not BusinessDelegates, you'd have to go back and change the name, even though in some contexts it still going to be a BusinessDelegate.
"However, a recently hired software architect might require this knowledge if they are to enhance an existing application"
Having been in this kind of situation, what I'm saying is that these kind of warts on names are of very limited value. I'd rather see names that tell me what the class does and not how it does it. Sometimes it make sense, like if you are using the Visitor pattern because you can't really use the Visitor without knowing that it's a Visitor. But for high level interfaces in the design, it's too detailed. I have no problem with implementations being named that way, but coupling the other classes in the design needlessly to a BusinessDelegate is not something I would recommend.
It's largely a style issue but I think you may underestimate the cost of renaming classes. It's easy in a monlithic project but it can be fairly tricky otherwise. For example, I was using Hibernate in a project and I ended up having to support both 2.x and 3.x. Between these versions, all the package names and a lot of the class names changed. so instead of just having to make allowances for changes in behavior and use, I had to make allowances for different names and make sure the code would work with only one of the versions available. This took a good chunk of time out of my work.
I also dispute the idea that maintenance programmers don't need to understand the design. If the maintenance developers don't understand, the design, they can't (or rather should not) be making any changes. Maybe trivial ones, yes, but maintenance is not always trivial, especially when there are design problems.
# 9
And since Singleton was mentioned, here is some more on my anti-Singleton campaign... for new readers.
Aside, if you are ever in a meeting or interview with an individual that presents themselves as a "J2EE Architect" / "Enterprise Architect" / "Object-oriented Programmer" and they ask you about a Singleton, how to implement, threading, whatever, ... be wary and proceed with caution. This is a sign that he/she is not being honest about themselves, in my opinion.
Singletons have no place in enterprise software and are best left to textbooks, in my opinion.
# 10
> Sometimes it make sense, like if you are using the Visitor pattern because you can't really use the Visitor without knowing that it's a Visitor.
This is a great point!
> It's largely a style issue but I think you may underestimate the cost of renaming classes.
This is a great point. Again, if you name the classes wrong, then it may be a problem, as you mention in your example. However, if you name them in a good fashion; conducive to the application, the people involved, the future direction of the application, then it is good practice. And as you mentioned, makes sense.
> Maintenance is not always trivial, especially when there are design problems
Great point. Again, if the design is crappy, then the maintenance will be difficult. In my context, I was not referring to applications with crappy designs. Again, the context is very important. Your points are very valid and understood. In my experience, I never had the problems you encountered and when I had to re-analyze an application written five years ago, it was very helpful that I named the appropriate classes with certain indications from the design pattern name. The application did not have a crappy design :o)
Business Delegate is a bit too much, using the term "Delegate" is reasonable, in my opinion. But as I said, I'm a bit rusty and have not designed any applications it the past three years. So, I may not be speaking on the "best" practices of the day.
# 11
I see Singleton as merely a specific type of Factory. There are reasons you might want to return a single Object from the factory but the chances are that that behavior will not suffice forever. I definitely think that classes using the Factory should not be writing code that depends on the uniqueness of the Objects returned by the factory in almost any circumstance.
# 12
> Business Delegate is a bit too much, using the term
> "Delegate" is reasonable, in my opinion. But as I
> said, I'm a bit rusty and have not designed any
> applications it the past three years. So, I may not
> be speaking on the "best" practices of the day.
These are just my personal opinions on the matter and it's not clear-cut. I think it might be a matter of a difference of context. I guess what I'm really saying is that the BusinessDelegate class should be a subclass of an interface that specifies what it 'services' it provides. This interface or super class should be generic. Classes should largely depend only on that interface and not a BusinessDelegate unless there's some reason they can only work with a business delegate and not some other implementation of the interface.
# 13
> I guess what I'm really
> saying is that the BusinessDelegate class should be a
> subclass of an interface that specifies what it
> 'services' it provides.
Good point. I don't read the Business Delegate design pattern to be a single class. And, implementation details of how it is implemented are not specified in the pattern's documentation.
Whenever I used the pattern I always had an interface and an implementation class. Example below:
public abstract interface AccountProcessorDelegate {
public boolean updateAccount(int x);
}
public final class AccountProcessorDelegateImpl implements AccountProcessorDelegate {
public boolean updateAccount(int x) {
// implementation code here to interact with business objects
}
# 14
> > I guess what I'm really
> > saying is that the BusinessDelegate class should be
> a
> > subclass of an interface that specifies what it
> > 'services' it provides.
>
> Good point. I don't read the Business Delegate design
> pattern to be a single class. And, implementation
> details of how it is implemented are not specified in
> the pattern's documentation.
>
> Whenever I used the pattern I always had an interface
> and an implementation class. Example below:
Your example is exactly what I'm saying shouldn't be done. There's nothing about that interface that requires it be a 'delegate'. It should be called AccountProcessor.
# 15
> Your example is exactly what I'm saying shouldn't be
> done. There's nothing about that interface that
> requires it be a 'delegate'. It should be called
> AccountProcessor.
I disagree, but just think that we are not talking about the same thing.
In my example, there would be an interface on the Buisness Tier named AccountProcessor. There would also be an implementation class called AccountProcessorImpl. These would be business objects. The implementation calss would contain the API for executing business logic of the application.
On the Presentation Tier, the business delegate interface and implementation are not business objects. They are service-level objects that reside on the Presentation Tier.
The AccountProcesorDelegate would delegate method calls to the AccountProcessor. The AccountProcesorDelegate would receive data from the AccountProcessor.
In the business object model, there would be an interface named AccountProcessor.
In the presentation code, where the business delegate lives, there would be an interface named AccountProcessorDelegate.
# 16
If the business delegate interface was named AccountProcessor.
And, if the business object interface was named AccountProcessor.
There would be a bunch of confusion and difficulty, in my opinion. One of my main reasons of using the term 'Delegate' in the naming of the the Business Delegate interface is to help distinguish the difference between the the business object and the service-level object.
While one is designing and writing code, things like this may be fresh in the mind. Once some time passes and other applications are created, these details get a bit foggy. It is helpful to name classes in such a way so that when or if you need to revisit the design, after many years, you will be able to recall things quicker and understand the system faster, in my opinion.
# 17
> If the business delegate interface was named
> AccountProcessor.
>
> And, if the business object interface was named
> AccountProcessor.
The question I have is: why do you need two separate interfaces? In my opinion, this is the wrong way to think about interfaces. If I'm coding in the presentation tier and I've been told to use a specific interface, why does it matter that it's a delegate?
I also don't think class names are a good place to document these high level design issues. All that's doing is making it harder to reuse the code in other contexts. This is the kind of approach that makes it difficult if not impossible to take code from fat-client and use it on a web page or in some sort of daemon process. You are making the classes depend on things that are outside of the scope of their concerns.
# 18
Three-tier programming is a bit different. The Business Delegate design pattern was created for the three-tier model of the J2EE Architecture. When designing an application conforming to this model, there will be interfaces for Presentation and Business tiers.
The code for handling the presentation of the application is different than the code for the business model.
> Why do you need two separate interfaces?
You need two interfaces in my example because the delegate is part of the presentation code and the other interface is for the busines logic code in the business tier. This is how the Business Delegate pattern works. It is used to reduce the coupling between the tiers. There should be no direct communication between the business model and the presentation code, hence the delegate.
Class and interface names do not document design issues, they should be used to convey the meaning of the class or interface.
> All that's doing is making it harder to reuse the code in other contexts.
If you use a BMP-related DAO, then that is it. You cannot reuse the DAO object in other contexts. The business delegate object is created for delegating method calls from the presentation tier to the business tier and vice-versa. Trying to use it for anything else does not make sense, and that is not what the Business Delegate design pattern was intended for. The documentation for the pattern is very clear, check it out when you get a chance.
# 19
> Three-tier programming is a bit different. The
> Business Delegate design pattern was created
> for the three-tier model of the J2EE Architecture.
> When designing an application conforming to this
> model, there will be interfaces for Presentation and
> Business tiers.
>
> The code for handling the presentation of the
> application is different than the code for the
> business model.
There is no 'code' in interfaces.
> > Why do you need two separate interfaces?
>
> You need two interfaces in my example because the
> delegate is part of the presentation code and the
> other interface is for the busines logic code in the
> business tier. This is how the Business Delegate
> pattern works. It is used to reduce the coupling
> between the tiers. There should be no direct
> communication between the business model and the
> presentation code, hence the delegate.
That has nothing to do with semantics of the interface. These are implementation details. Why even have an interface if you are doing this?
> Class and interface names do not document design
> issues, they should be used to convey the meaning of
> the class or interface.
Exactly. Why are you using them to document design issues?
> > All that's doing is making it harder to reuse the
> code in other contexts.
>
> If you use a BMP-related DAO, then that is it. You
> cannot reuse the DAO object in other contexts.
The DAO is not the interface.
> The business delegate object is created for delegating
> method calls from the presentation tier to the
> business tier and vice-versa. Trying to use it for
> anything else does not make sense, and that is not
> what the Business Delegate design pattern was
> intended for.
Which is why it's stupid to tie the interface to that pattern. It makes anything that uses it coupled to that pattern and unusable in other contexts.
> Thedocumentation for the pattern is
> very clear, check it out when you get a chance.
The fact that you think this is pertinent just tells me that you are completely missing the point of what I am saying. I have that book, BTW. I first read it about 5 or 6 years ago.
# 20
Further analysis of this thread and our exchanges reveal that there is no common understanding of the following words, in my opinion. In many cases of 'forum' misunderstandings, it is the semantics of English language that are the source of confusion.
code
implementation details
document
tie
To try to explain and dig into this is a waste of time, in my opinion.
Just as an example to convey my point, when I type in the Java keywords in the source code of a Java interface, I feel that I am typing in code/keywords in the source code. On the other hand, you feel, "There is no 'code' in interfaces".
Oh well...
# 21
> To try to explain and dig into this is a waste of
> time, in my opinion.
Honestly, I think this is just a slight-of-hand that allows you to save face.
There is no question about what these terms mean. If you don't understand them, that's not my fault nor is it my problem.
I would suggest looking at the Collection interface and all it's implementations and thinking about what it means so separate implementation details from the interface. Any class can bind to the Collection interface without coupling itself to a specific implementation of it. Your interfaces should be addressing that same concern.
# 22
Oh well... I disagree and think we are not using the terms in the same manner. To "document" a class you can create JavaDocs, you can create UML diagrams (sequence, class, package, etc.), or you can write about the class in a Word document.
I don't feel that putting the term 'Delegate' in a class name is is "documenting" anything. In your post, you are using the word "document" in a strange manner and it is questionable, in my opinion.
It is also unclear whether you understand the differences between creating a three-tier application with interfaces on all three tiers, AND, implementing interfaces. such as in the Collections Framework
There is a big difference.
# 23
> Oh well... I disagree and think we are not using the
> terms in the same manner. To "document" a class you
> can create JavaDocs, you can create UML diagrams
> (sequence, class, package, etc.), or you can write
> about the class in a Word document.
>
> I don't feel that putting the term 'Delegate' in a
> class name is is "documenting" anything. In your
> post, you are using the word "document" in a strange
> manner and it is questionable, in my opinion.
"For Business Delegate objects, using the "Delegate" part is helpful if there will ever be other software developers 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."
When you wrote this, what was your meaning. If it's not to 'document' the design, then what is the purpose? What is your definition of the verb 'document'?
When I look up 'document' in Google the very first definition is: "writing that provides information." You think this is a strange usage of the word?
If not, documentation (conveying elements of the design in text), what exactly is the point of putting Delegate or BusinessDelegate in the name?
http://www.google.com/search?hl=en&q=define%3A+document&btnG=Google+Search
> It is also unclear whether you understand the
> differences between creating a three-tier
> application with interfaces on all three tiers,
> AND, implementing interfaces. such as in the
> Collections Framework
> There is a big difference.
So are you creating identical interfaces on two or more tiers? What is your point? You aren't saying anything here. Do you think 3-tier design means abandoning core design principles? I've worked on 3-tier projects and many other types of projects, if that's what you are asking.
# 24
So, you know how to search on ?oogle too.! What a great engineering skill that is.
Once I finish mastering the art of toliet cleansing, I will be promoted to a ?oogle Search guy.
Here I an 'documenting' the fact that ?oogle earch engine results define our existence and we should immediately burn down all libraries and bookstores because they don't matter any more.
You know, I recently started participating on a forum for financial professionals. It is so much different than here; we have our photos available on our profiles with decriptions and contact information.
I am generating exposure for my business and actually meeting individuals with real knowledge and networking potential. There are almost 16,000 members in the U.S.A. And I have already generated two strong leads for consulting projects with a mortgage brokerage in the South. It is a shame that these forums cannot offer such professional value or opportunity.
This is a sign of the coming of Web 2 and the demise of search engines. Take note and go find you a social networking site to grow your business and interact with the real. It is great. Jokesters get removed immediately and you are held accountable for all public statements. No anonymous clowns hiding in some basement in Sweden with their pranks and silly commentary :o)
# 25
> So, you know how to search on ?oogle too.! What a
> great engineering skill that is.
>
> Once I finish mastering the art of toliet cleansing,
> I will be promoted to a ?oogle Search guy.
You are a joke. I was trying to have a real discussion with you but you are clearly too childish to handle that. Being wrong is a fact of life, especially for you. Get over it.
