I dunno, I kind of like having a hint as to the class type in the
name. That way if I see a reference in code or javadoc I know what it is
without having to dig up the source for the class in question. If I'm
reading some source and run into:
IPage p = (IPage) cycle.getPage("pageName")
I immediately know that cycle has a collection of object who
implement the IPage interface. Conversely, if I see:
Page p = (Page) cycle.getPage("pageName")
I assumed (potentially erroneously), that Page is a concrete class
as it's the natural assumption to make.
I agree when you're reading the primary source it's sort of
redundant, but most users of a package aren't going to read the primary
source. They'll end up reading the higher level API and sample code, where
having Abstract or I in the name is a useful crib as to what's going on.
It's sort of like using _ or f for field variables. Sure I could
scroll up to the top of the class and see if something is defined there or
not, but if the information is contained within the name, I don't have to.
--- Pat
-----Original Message-----
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Kent Tong
Sent: Saturday, April 23, 2005 6:05 PM
To: [email protected]
Subject: Re: Naming intefaces and abstract classes
Karthik Abram <karthik.abram <at> neovera.com> writes:
>
> So why does having "Abstract" in an abstract class make sense? Clearly
> "public abstract class" is equally unequivocal.
That's right. In my opinion names like AbstractEngine, AbstractPage are
poor names. For example, AbstractPage should just be called DefaultPage
or something else.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
