Forums Register Login

NX: Terminology angst

+Pie Number of slices to send: Send
I have used two terms that might be misleading in my code.
1) 'recordSet' to be the records returned from the DB. They are not a Java Set. They are a List. the name recordSet is just a habit I picked up over the year to describe the collection of rows returned from a query.
2) DBAdapter, LocalAdapter, RemoteAdapter etc. To be honest ive used these just because I have been hanging around here and the class names just rubbed off on me. But they are NOT actually adapter patter. Im worried it will make the examiner think it is. In facts those classes are part of the Bridge pattern.
Should i retrofit my code (yuk!) or is it ok to just mention this in a short Terminology section of the choices.txt?
+Pie Number of slices to send: Send
Hi,
I'm not sure that changing interface names is a "retrofit." While I can't say whether
your class or interface names are appropriate, if based upon responses by others
you determine that they are, by all means change them--if you can do so without
incurring significant costs, and under ideal circumtances, the only costs would be
recompiling, though, it's true, to be safe, you would have to run your JUnit tests
again (which also is low-cost))--for the names you give them is part of your grade.
Thanks,
Javini Javono
+Pie Number of slices to send: Send
Yeah, but DBBridge and LocalBridge sound so lame. LocalAdapter just wizzes of your keyboard
Its more the effort to visually check every file and document to make sure I have no reference to DBAdapter when there isnt one.... but I think your'e right. Looks like I have a few more hours work before submission.
+Pie Number of slices to send: Send
Morgan,

Originally posted by Morgan Bath:
Its more the effort to visually check every file and document to make sure I have no reference to DBAdapter when there isnt one.... but I think your'e right. Looks like I have a few more hours work before submission.


If you use TextPad you can open all your source code files in the editor and do a global search for DBAdapter. If you're using a different editor it may support the same kind of search. I think you are judged on the suitability of the names you use (I think the name of interfaces, classes, methods, etc. come under the general considerations category) so if you're using a Bridge (rather than the lovely Adapter) then the name should reflect this.
You can use all the time you will save from not persisting your JTable column widths in the suncertify.properties file to get rid of DBAdapter from your code.
+Pie Number of slices to send: Send
Naming all these classes after the Bridge pattern is NOT a good idea IMO.
The individual class names should say more about the specific role of each participant in this collaboration. It is the collaboration of these classes that is an example of the Bridge pattern. An Adaptor sufix appended to a class name is just fine if that is indeed what the class does.
Well chosen names are a very important part of a program's documentation. You can count on being judged (and not just on the exam) on how well you do this.
As Martin Fowler says:

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

 
+Pie Number of slices to send: Send
Both of you present good points, and yet opposing conclusions. But I do have one bone of contention. Names indicating the pattern used arent for the compiler to understand. They are for the programmer. Most programmers now are aware of the common patterns. I have Model, View and Controller classes in my gui package. For a programmer I think that is more clear than calling them : ContractorBookingClient, ContractorData and ContractorController. Or something similar. With just model, view and controller classes any programmer immidiatly knows what is going on in the gui just by looking at the package. A user might not like the names, but a programmer should.
But the bridge vs adapter names is a tough one. Adapter is a better name for what the classes do. BUT as a programmer I would be tempted to think adapter pattern. And seeing as adapter and bridge are physically almost identical im worried the examiner looks at the names and code, thinks "adapter pattern", looks at the choices.txt and sees "Bridge pattern" and then goes ... oooh this guy is cheating. He uses someone elses code and doesnt even know whats in it. Does that make sense?
+Pie Number of slices to send: Send
Hi Morgan,
Well, I finally did what I should have done before I wrote my last comment: namely lookup Bridge in GoF's Design Patterns. I think Ken's right about the naming conventions for Bridge. I haven't used the Bridge design pattern before but according to GoF the naming convention (or at least a naming convention) seems to be as follows:
The abstraction interface is called whatever it's called, say Xxxxx.
The implementor interface would then be called XxxxxImpl, and the concrete implementations of the implementor interface would then be called OneXxxxxImpl and TwoXxxxxImpl. Hopefully, there are more meaningful names for these things than Xxxxx, One, and Two, but I'm just trying to illustrate the naming convention.
By the way, I also called my MVC classes: Model, Viewer, and Controller.
+Pie Number of slices to send: Send
Well basically its a choice of changing:
DBAdapter, LocalAdapter, RemoteAdapter & RemoteAdapterImpl
to
DBBridge, LocalBridge, RemoteBridge & RemoteBridgeImpl.
I cant think of a better name for a class that provides a bridge between the gui and db. I traditionaly call it an DBadapter or ContracterDBAdapter etc even though its not Adapter pattern. Im trying out actually calling DBBridge or COntractorDBBridge ... but it just doesnt roll of the tongue

BTW when you say you havnt used Bridge pattern before, do you mean havnt conciously used it or never ever actually formed a bridge between two classes to hide implementation details?
[ February 19, 2004: Message edited by: Morgan Bath ]
+Pie Number of slices to send: Send
 

Originally posted by Morgan Bath:
BTW when you say you havnt used Bridge pattern before, do you mean havnt conciously used it or never ever actually formed a bridge between two classes to hide implementation details?


Nope, not that I'm aware of. Guess I led a pretty sheltered existence; I need to get out more.
[ February 19, 2004: Message edited by: George Marinkovich ]
+Pie Number of slices to send: Send
I think an example is in order. First lets look at Bridge, then we'll look at Adapter.
Suppose you create a class called CoolThing.

You can subclass CoolThing to create other variations of CoolThings. However, maybe you decide that this strategy is too limiting as you want to be able to provide this behavior in some other object, let's say it's a class called Pet. The problem is that to get that behavior, you have to derive from Thing. Checking your Design Patterns handbook, you find the Bridge pattern.

You now have a complete Bridge pattern that allows you to add CoolThing behavior to any kind of Object. You can also extend CoolThing to add other types of behavior so both can vary independently.

So what has Bridge got to do with an Adapter ???
Not much although you could think of PetCoolThing as an Adapter because it is one (see below). The Bridge is the collaboration between the CoolThing interface and its implementors, present and future and the possible future extensions of CoolThing.
The class name CoolThing is a pretty good one because it describes its responsibility which is not specific and its role which is to provide CoolThing behavior. You could add Bridge to its name but it doesn't really help much as it pins it down unnecessarily.
The class name PetCoolThing is a pretty good one because it describes its specific responsibility which is to be a Pet and its role in the world of CoolThings which is to provide CoolThing behavior. You could add Bridge to its name but it is somewhat verbose and doesn't really add much. You could potentially add Adapter to its name.

Now let's take a look at Adapter. Suppose we have some legacy class Fanfare that does something cool, i.e. playsTrumpets(), but it doesn't implement the CoolThing interface. Checking our trusty handbook we find Adapter.

We now have a complete Fanfare as CoolThing Adapter. The class name is fairly good because it is precise although it is a bit verbose. It describes its specific responsibility which is to use a Fanfare to playTrumpets() and its role which is to provide CoolThing behavior. Now let's look at some alternative names.
CoolThingAdaptor - this would be OK if it is in the Fanfare package but that is in our legacy code which we can't change, so this alternative is rejected.
FanfareAdapter - this is pretty good if it lives in the CoolThing package but not if we want to put it somewhere else.
FanfareAsCoolThing - it makes no mention of Adapter but it's not bad at all. It implies Adapter behavior. I like it and would probably choose it. I can add it to the CoolThing package but it move it elsewhere and the name would still be relevant.

IMO, patterns language is best used to communicate the design in the design documentation rather than in the relatively less stable implementation of the design. The fact that an a particular class evidences use of a pattern doesn't mean it can't also evidence use of other patterns as well. Why pin it down by attaching a single pattern name to its class name ???

BTW, PetCoolThing is an Adapter and so is FanfareAsCoolThing. PetCoolThing provides its adaptive behavior through inheritance and is a less flexible type of Adapter than FanfareAsCoolThing which provides its adaptive behavior through composition and delegation.
[ February 19, 2004: Message edited by: Ken Krebs ]
+Pie Number of slices to send: Send
Ken,
Thanks for the clear explanation, it was very helpful. Turns out I have done that before, but it just never registered with me as the Bridge design pattern. I haven't internalized as many of the design patterns as I should. Now I think I'll be able to remember Bridge.
+Pie Number of slices to send: Send
I totally agree Ken, but thats my problem. Because in this case what I have here is some object that allows me to connect to the database and use it without worrying about nitty gritty little implementation details. It might be local, or it might be remote. But what do you call it? Well my first thought is the word Adapter. Why? I really dont know. It just seemed a good description. Thats what if 'feels' like to me. And perhaps if the Adapter pattern had never been invented it would be a good word. It conjures the image of something that you can use to access a database without speaking Datbaseish.
But I agree, I really dont like DBBridge either. Thats just using the word to punch home the use of the pattern and just plain ugly. Im toying with DBClient: LocalClient and RemoteClient etc
In a real project I wouldnt have given this a nanoseconds thought. It would be adapter and any programmer coming along to maintain my code who couldnt understand it wasnt named after a pattern would get the middle finger. I figured here it was best to wait until after the grading before I flipped him off
+Pie Number of slices to send: Send
Morgan,

Im toying with DBClient: LocalClient and RemoteClient


If Client is the interface, those names for the implementations are very good IMO as they describe the specific responsibility in terms of the Client role.
If DBClient is the interface, those names for the implementations are OK though I myself would prefer LocalDBClient and RemoteDBClient.
I still would not use the names of the patterns used (Bridge and Adapter) for the previously mentioned reasons.
In a real project, it's much more important to get the naming right than on SCJD. I would use the naming conventions of my employer. If they sucked I would seek to change them as they are just too important to be ignored.

Just my 2 cents worth.
+Pie Number of slices to send: Send
 

Originally posted by Ken Krebs:
Morgan,
If DBClient is the interface, those names for the implementations are OK though I myself would prefer LocalDBClient and RemoteDBClient.


Actually thats what I meant

Originally posted by Ken Krebs:

In a real project, it's much more important to get the naming right than on SCJD. I would use the naming conventions of my employer. If they sucked I would seek to change them as they are just too important to be ignored.

Just my 2 cents worth.


Yeah, but on a real project, you pick a name and if the customer or your boss dont like it (and he better have a damn good reason for it before he approaches me about it), you just change it. On the assignment you dont get the chance to alter it. Hence im going anal over details like this
+Pie Number of slices to send: Send
Hey Morgan,
I'd like to share my methodology for making sure that requirements have been met.
Give the requirements to your most anal geek friend, then give him the code and documentation. Ask him to see if you've met the letter of the requirements, and don't offer a single word of explanation thereafter. Finally, buy him a beer as a Thank you.
All best,
M
+Pie Number of slices to send: Send
Thanks for all the advice guys. Im just gonna submit before I find something else to worry about.
cheers
[ February 19, 2004: Message edited by: Morgan Bath ]
Ever since I found this suit I've felt strange new needs. And a tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com


reply
reply
This thread has been viewed 796 times.
Similar Threads
NX: choices.txt (Lazy bum vs. Please shut him up!)
Habibi book contact info?
NX: RandomAccessFile / Singleton DataSchema
Will this cause auto-failure?
NX: Question on Max's DVD project
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 19, 2024 04:31:15.