The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Object and function naming style

Hello

What do you prefer (C#):

g.Tables.Add("tablename");
g.Fields.HideAll();
g.Fields.Show("fieldname", true);
g.Fields.IsVisible("fieldname");

or

g.AddTable("tablename");
g.HideAllFields();
g.ShowField("fieldname", true);
g.IsFieldVisible("fieldname");
Dan Gibson Send private email
Monday, May 07, 2007
 
 
The first set.
Almost H. Anonymous Send private email
Monday, May 07, 2007
 
 
First one.

It also promotes reusability and extensibility.  The "Tables", and "Fields" properties can be subclasses of a collection class and then you can do neat stuff like sorting with only a line or two of code.
JSmith Send private email
Monday, May 07, 2007
 
 
I usually start by writing the second one, and end up changing it to the first one later on.
JW
Monday, May 07, 2007
 
 
Second one, with respect to "The Law of Demeter"

http://en.wikipedia.org/wiki/Law_of_Demeter
Franklin Send private email
Monday, May 07, 2007
 
 
I prefer the first syntax.
D. Lambert Send private email
Tuesday, May 08, 2007
 
 
What is the seperation between a Field, a Table, and 'g'?  You're object 'g' seems to hold multiple tables, yet can operate on any field within any of the tables. This could get very confusing unless you clearly define the hierarchy.

I'd guess that you want tables to hold multiple fields, which can be modified accordingly. Then you might put some of these general field operations (e.g. hide all) in the table object, since its the owner. But you might want to work with multiple tables and handle them all gracefully, you're object 'g' is simply a holder of a collection of tables with utility methods. It might have a hideAllFields() which applies to every table. However,  doing a lookup in 'g' on a field might not be allowed due to name collisions across tables.

I'd focus on seperating concerns and deciding who owns what first. Think about object responsibilities.
Manes
Tuesday, May 08, 2007
 
 
A bit more info. I'm working on accounting software that can be extended by 3rd party developers. So the question really is, when using/learning a 3rd party api (vs writing your own programs) which style is easier to learn/use?

I think I prefer the first style, it seems more .Netish than the 2nd. The 2nd does have the Demeter benefit though. Since it is the system controls that I'm designing, from my point of view the 2nd would be better for ensuring backwards compatibility between different versions of the base accounting system. On the other hand, the api is for _other_ developers to use, not me, so I guess what I want as the developer of the controls matters less than what the users of the controls want.

So, when it comes to learning an api, do you find one style easier than the other, or does it not matter?
Dan Gibson Send private email
Tuesday, May 08, 2007
 
 
Put yourself in place of your potential developers and try to develop something using your API. You'll quickly see which style is better.
Vasyl Smirnov
Tuesday, May 08, 2007
 
 
It really depends. 

* Does "g" really serve a purpose?  Could it be eliminated?

* I would go with the second as long as "g" did not have too many methods. 

* If any of the internal objects only needed to expose a single method, I would go with the second approach.

* If any of the internal objects needed to hide methods, I would go with the second approach and make all of the methods on the internal object public for testability.

* If any of the internal objects is used outside of "g", I would go with the first approach.

* The second approach provides a little bit more flexibility in later refactoring.  The first approach tends to lock down the class structure a little more.

It's really a pretty subjective determination and  really needs to be made on a case-by-case evaluation using domain knowledge.  In the end, neither approach is fatal, so pich the approach that feels best when the need arises and refactor later.
Wayne M.
Tuesday, May 08, 2007
 
 
"So, when it comes to learning an api, do you find one style easier than the other, or does it not matter?"

I would typically be more productive using an API built using the second style if my goal is to consume the API as a service.

When the public API is available through a single interface like that, it's easier to see exactly what is available and what methods must be called to achieve your goal.  I find it more cumbersome to have to wade through APIs that are spread out over a zillion different kinds of objects hunting for what I want to do. 

Have a look at some of the MS Enterprise application blocks, as a test case.  To use the logging block, for example, you have to understand how a bunch of little pieces fit together, where to obtain each of the pieces, and you have to remember which little piece does what you are wanting to do in order to use it effectively.  This might be fine if my goal is to assemble a custom logger, but it's a real PITA if my goal is simply to write logging statements out to a log file.

Worse, over the course of several versions of this API, the implementation has changed a few times.  Since client code depends on the internal structure (Demeter weakness) of the API, client code needs to be reworked with each new version of the API.
anon Send private email
Tuesday, May 08, 2007
 
 
+1 Think about object responsibilities

When you have lots of calls like a.b.c(), it's often an indication of a design issue. Like everything, "it depends...", but it's worth looking at to see if there's a better design.
Mike S Send private email
Tuesday, May 08, 2007
 
 
I go with the second.  I want a simple interface, not Dot Poisoning.

Sincerely,

Gene Wirchenko
Gene Wirchenko Send private email
Tuesday, May 08, 2007
 
 
I agree with those that prefer the second style. It seems like the first is better, because there's some reuse of concepts, so callers will be able to understand your design without cognitive overload brain explosion -- but that never happens in practice. They don't care about your stupid design, they just want to get something done, and the more objects and dots you have, the less Intellisense is helpful, and the longer it takes to get anything done.

Have a look at the Visual Studio automation model if you don't believe me :) It's done in the first way, and it's an absolute pain in the arse to do anything. The design isn't bad, as such, it's just that (as anon rightly points out) everything is now so spread about that finding out how you do what you want to do is damn near impossible.

(As with everything, some taste is in order, of course.)
Tom_
Tuesday, May 08, 2007
 
 
depends on the actually coupling between Table and Fields in the context of g. 

Is it logical to give Fields to another method independent of Table?

void LayoutFields(IFields blah)

in which case if you go with option two you are going to couple tables and fields interfaces into one thing.  That can be painful.

and option 1 is not looking too appealing,  someone mentioned the law of Demeter (which is not a law!),  often the reaction to option 1 then applying law of Demeter is an interface like option 2.  This is no better than option one!  You still haven't worked out a better design or decoupled your code.  You haven't solved the question of why you are reaching through and manipulating things at that level.

So, overall I'd have to say option 1 is probably the best start, at least it has table and field concepts separated.
Keith Nicholas Send private email
Wednesday, May 09, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz