searching for good interface names

[Stefan Ram]

What would be good names for the following interfaces?

Where »good« means: adhering to common naming conventions and
suggesting the contents of the interface just by the name of
the interface to as many readers as possible.

The interfaces are parts of the package »gregorian«, so that
information that they are related to the gregorian calendar
does not need to be repeated in the interface names.

public interface ?0
{ public int getYear();
public int getMonth();
public int getDay();
public int getHours();
public int getMinutes();
public double getSeconds();
/* time zone information follows */
public int getDirection();
public int getShiftHours();
public int getShiftMinutes(); }

public interface ?1
{ public void setYear( int year );
public void setMonth( int month );
public void setDay( int day );
public void setHours( int hours );
public void setMinutes( int minutes );
public void setSeconds( double seconds );
public void setDirection( int direction );
public void setShiftHours( int shiftHours );
public void setShiftMinutes( int shiftMinutes ); }

public interface ?2
extends ?0, ?1 {}

/* some additional operations beyond mere getters
and setters, I already have a satisfactory name
for this interface */
public interface ?3
{ public void add( final double addend );
public java.lang.Object sum( final double addend );
public double doubleValue();
public void assureBroken();
public void shiftTimeZone( int minutes ); }

/* a date and time together with some additional
operations for it. */
public interface ?4
extends ?2, ?3 {}

What I am interested in most, is whether there are common
names for an interface of setters ?1, and interface of getters
?0 and for the combination ?2 of these two allowing data
access but no other operations ?3 yet.

Then I have the need to tell between a small interface ?2 just
for data access and a larger interface ?4 for data acces ?3
plus additional operations ?3.

(?3 could be broken down in other interfaces, too. But that
would not be in the scope of this post.)

 

[Roedy Green]

The interfaces are parts of the package »gregorian«, so that
information that they are related to the gregorian calendar
does not need to be repeated in the interface names.

The main thing you want to do is choose names that won't be confused
with Sun's calendar classes.

how about

immutableInstant
mutableInstant
computationalinstant

Instead of Instant -- epoch, timestamp

don't call them Dates the way Sun abuses English.. Dates don't have
associated times.

 

[Chris Uppal]

What would be good names for the following interfaces?

Where »good« means: adhering to common naming conventions and
suggesting the contents of the interface just by the name of
the interface to as many readers as possible.

Doesn't that depend on what you are going to do with them ?

For instance, is interface ?0 intended to capture what it is to be a Time or
Timestamp (or DateTime if you are in a culture/environment where undecorated
"time" means "time-of-day") ? Or is it the interface of things that happen
/at/ a time such as events, occasions, or appointments ?

For interface ?1 the question is even more acute. I cannot offhand think of a
use for a write-only Time (or whatever) object. You may well have one, but
since I don't know what they could be used for, I'm correspondingly unable to
think of a sensible name for them.

For interface ?2, it's easier. Either interface ?1 is an ImmutableXxxx (or
ReadableXxxx or ReadonlyXxxx) and interface ?2 is Xxxx. Or interface 2? is the
MutableXxxx. Which gets the long tag depends on how you intend to use them.
E.g. if you normally pass around immutable dates, and only some private code
ever knows about mutable ones, then the interface in common use would be
untagged, and the interface in limited and special use would have the longer
name to indicate the "special" nature of the access they had.

Interface ?4 is unspecified, so there is no way I can even guess at a name for
it.

I suspect that you are over-engineering this. The point of an interface is to
define the operations needed for a pattern of use. Unless there is a pattern
of use then there is no need for the interface ("tagging" interfaces such as
Cloneable excepted -- reluctantly). And if there is a pattern of use then
/that/ will suggest the name, not the contents of the interface. It doesn't
seem to me that you are basing your interfaces on intended uses, but rather on
an abstract "algebra" of interface definitions. That's pretty, but it creates
interfaces with no (obvious) uses, and hence no legitimate names.

-- chris

 

[Stefan Ram]

immutableInstant
mutableInstant
computationalinstant
Instead of Instant -- epoch, timestamp
don't call them Dates the way Sun abuses English.. Dates don't have
associated times.

Thanks for all answers to my above question!

The names I am currently using are as follows.
May be somebody could tell me if they are misleading.

Package name: »de.dclj.ram.system.gregorian«, where
»system« is intended for mutable objects:

PointGetter
The interface with »get« methods.
»Point« means a »time point«.
I hope that in English, »point« can also
mean »instant«.

PointSetter
The interface with »set« methods.

PointCore
The combination of PointGetter and PointSetter.
Should I rename this to »PointBean«?
The »core« reflects the pure »data interface«
without other operations. It kind of resembles
a C structure and thus is not very object-oriented.

PointConversions
Operations to convert the point to data
types like »double«.

PointArithmetics
Operations to add seconds to a point and so.

Point
Combination of all above interfaces.

Java
Well, admittedly a strange interface name.
It contains Java-specific operations like
conversion to a J2SE specific time value.

JavaPointCore
PointCore + Java

JavaPoint
All of the above

The class »DefaultJavaPoint« then implements the interface
»JavaPoint«.

Is this over-engineered? Well, what I like about it is that I
can easily see where to find an operation and write code that
only depends on a smaller interface than »JavaPoint«, so that
this code is more general.

 

[Roedy Green]

PointGetter

Point is already taken to mean an x,y pair.
Perhaps TimePoint

 

[Roedy Green]

PointConversions

The object itself is a Point capable of doing conversions.

A class with lots of static methods for doing conversions might be
called PointConversions but a one with instance methods might better
be called ConvertiblePoint.

 

[Roedy Green]

Java
Well, admittedly a strange interface name.
It contains Java-specific operations like
conversion to a J2SE specific time value

NO NO NO. Don't use words that are almost reserved.

 

[Chris Uppal]

PointGetter
The interface with »get« methods.
»Point« means a »time point«.
I hope that in English, »point« can also
mean »instant«.

You can use "point" to mean a point in time, but it's not very idiomatic. That
usage is pretty much restricted to a handful of special cases.

Also PointGetter is not (IMO) a good name (even conceding "point"). A "point
getter" is something that gets points. I'd expect it to have methods like
numberOfPointsAvailable()
getNextPoint()
findPointNearest(int x, int y)
and that kind of thing.

I suggest ReadablePoint (or GettablePoint) if you must build this algebra of
interfaces.

PointSetter
The interface with »set« methods.

WritablePoint (or SettablePoint). The things don't set points.

PointCore
The combination of PointGetter and PointSetter.

MutablePoint or just Point depending on whether this is the most-used
interface.

Should I rename this to »PointBean«?

Absolutely not! Ugh!

The »core« reflects the pure »data interface«
without other operations. It kind of resembles
a C structure and thus is not very object-oriented.

Which indicates a problem in the design, I think. What are the
/responsibilities/ you are trying to capture ?

PointConversions
Operations to convert the point to data
types like »double«.

What is this for ? Are you trying to do Mixins in Java ? That will not work
(much though I like Mixins). Mixins are a technology for reusing
/implementation/, allowing code to be shared between otherwise independent
classes. Java interfaces are about typing and contracts, there is no
connection. When would you ever want to declare a variable

PointConversions x = // ...whatever

and what sensible name would you give to 'x' ?

PointArithmetics
Operations to add seconds to a point and so.

As above.

Point
Combination of all above interfaces.

OK, but you already have six interfaces with no (at least to me) obvious
justification for more than two.

Java
Well, admittedly a strange interface name.
It contains Java-specific operations like
conversion to a J2SE specific time value.

This could be defensible. Depends on how much infrastructure code needs to be
able to access pretty-much any of your domain objects without caring about
their type other than that they /are/ domain objects. I'm not sure I'd choose
"Java" as a name though.

JavaPointCore
PointCore + Java

See above.

JavaPoint
All of the above

Do you really expect the code that uses these objects to declare variables,
parameter types, etc, as JavaPoints ? Doesn't the weird name make your
design instinct cry "Fowl!" ?

Is this over-engineered?

Yep ;-)

/Eight/ interfaces!

Even in the extreme case I can't see any value in more complexity than:

interface ReadablePoint {...}
interface MutablePoint extends ReadablePoint {...}
interface Persistable {...} // for the infrastructure stuff

abstract class PointAbstract
implements MutablePoint
{
// useful template for Point implementations
}

class DomainPoint
extends PointAbstract
implements Persistable
{
}

And even that is getting well on its way towards becoming unmanagable (though
it might have to /be/ managed).

-- chris

 

[Thomas Weidenfeller]

Yep ;-)

/Eight/ interfaces!

For a feature which already exists in the SE: GregorianCalendar. Much
more than caring about interfaces I would care about semantics. E.g. how
to resolve the following sequence of calls:

date.setMonth(1); // Assuming 1 == January
date.setDay(31);
date.setMonth(2);
System.out.println(date.getDay()); // Hmm ...

Another issue is with

/* time zone information follows */
public int getShiftHours();
[...]
public void add( final double addend );

Usage of time zone data indicates that the objects mix the semantic of
an "absolute" moment in time, and a physical location. This in theory
gives a local time - however, thanks to DST, things like the hour offset
from GMT are no longer a fixed value for a particular time zone. So does
getShiftHour() vary with the date (changes when DST changes), or not
(sticks with the geographical location)?

A related problem is what adding means when crossing the DST/non-DST
borders. E.g. what should result when adding a day to 10AM just at the
day before a DST change? Should the time still be 10AM (so adding a day
actually meant adding 23 or 25 elapsed hours to keep the wall-clock time
the same), or should the time be 9AM or 11AM (really adding 24 elapsed
hours, which, thanks to DST, will change the wall-clock time)?

One probably ends up with a re-implementation of the build-in gregorian
calendar, just with a different interface. Ups, with a set of eight
interfaces. Naming the stuff is really not the problem here. Defining
and then implementing the behavior of the interfaces is. IMHO the
intended API is to naive for handling dates and time, independent of how
many interfaces and which names are used.

As for naming the interface, when having to chose between Point, Date or
Calendar, I would go with Date or Calendar.

/Thomas