I'm writing a Client of FooServer which is reliant upon a rather clunky library whose functionality I'd like to encapsulate in a wrapper library to make the usage less clunky.
My first thought is to choose
FooServer as the name of what will likely be the most used class in the library. That way, when I want to get some property of the server or tell it to perform some action I can do something like:
FooServer foo = FooServer.findById(12);
string property = foo.property;
foo.performAction();
That seems innocent enough. But my fear is that by calling the class
FooServer, it may violate the
principle of least surprise because it does not fully implement a Foo server, nor would it be of use in implementing a Foo server.
I also dislike tagging it with "Wrapper" or something of the sort, because reading that in the client code doesn't seem right either.
I know I'm probably over-thinking it, but names are important to me, because they are the start of clean, readable code that does what it says and says what it does. So that's why I come to you, dear reader.
What would you name the class?
Hey! Why don't you make your life easier and subscribe to the full post
or short blurb RSS feed? I'm so confident you'll love my smelly pasta plate
wisdom that I'm offering a no-strings-attached, lifetime money back guarantee!
Leave a comment
Hi Sammy, what about calling it a FooAdapter?
Posted by
Kevan Stannard
on Feb 27, 2011 at 04:44 AM UTC - 5 hrs
I asked myself the same thing when I wrote the Apify gem, which includes classes for both server and client implementations. I ended up calling the client class Apify::Client and I'm quite happy with it.
I would always suffix the client class with something like "Client", "Connection" or "Remote", because this describes the class best. Nobody is helped when you pretend the connection is the server, and might even be confused by the name. Also you might eventually have some connection-related methods in that class (like timeout or proxy settings) and the abstraction falls apart completely.
Posted by
Henning Koch
on Feb 27, 2011 at 06:25 AM UTC - 5 hrs
@Kevan - I hadn't thought about it in those terms, but I suppose it is an Adapter or maybe Facade in terms of the GoF design patterns catalogue. I'll think about it some more.
@Henning: I agree with the client bit, and I'm glad you mentioned it because now that I think about it, I wonder if what I've written is more along the lines of a client. I'll have to ponder it a bit as well, but certainly it is wrapping actions and properties of the server.
The original clunky library actually interfaces with several types of servers: FooServer, BarServer, BazServer for instance. So I wonder if it would make more sense for me (and remove the naming strangeness) to go through 2 layers of abstraction: one to be an adapter for the library, and one for the specialization of that into accessing a FooServer.
Posted by
Sammy Larbi
on Feb 28, 2011 at 12:12 PM UTC - 5 hrs
I don't think what you have described is a client as such, since it is providing the services of the FooServer to its own clients. If this were all on the web, then I *think* what you are writing is a sort of proxy. Proxies have methods the server doesn't have, for example, to refresh their caches. So it is therefore not a subclass or instance of the server. And if it will stand in for other servers, the analogy seems more apt. But I don't have the full picture, so maybe what I have written is Just Wrong.
Posted by hgs
on Mar 29, 2011 at 08:05 AM UTC - 5 hrs
@hgs: That a good point, I hadn't thought of it like that, but it does seem an apt metaphor.
In that case though, would you *name* it FooProxy, or is it better that the client code should not realize or read as if it's utilizing a proxy?
Posted by
Sammy Larbi
on Mar 29, 2011 at 01:16 PM UTC - 5 hrs
