You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Karthik Abram <ka...@neovera.com> on 2005/04/23 23:46:21 UTC
Naming intefaces and abstract classes
So why does having "Abstract" in an abstract class make sense? Clearly
"public abstract class" is equally unequivocal.
-----Original Message-----
From: news [mailto:news@sea.gmane.org]On Behalf Of Kent Tong
Sent: Friday, April 22, 2005 9:25 PM
To: tapestry-user@jakarta.apache.org
Subject: Re: If we call it Tapestry 4.0, not 3.x, Maybe we would do much
Mind Bridge <mindbridgeweb <at> yahoo.com> writes:
> Interfaces and classes are two rather different concepts. It seems to me
> that they need to be distinguished clearly. Removing the 'I' in front of
> the name and the characters that saves are a much smaller win compared
> to the loss of clarity and the time wasted in figuring out what can be
> done with that type.
Using "I" is bad because it violates the DRY (Don't Repeat Yourself)
principle. If the fact that Foo is an interface is already stated
in:
interface Foo { ... }
There is no need to state it again in its name. Similarly, you won't
duplicate the methods in Foo into its name, right?
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Naming intefaces and abstract classes
Posted by "T.Mikov" <tm...@gmail.com>.
The same logic would seem to apply for IPage and Page, doesn't it ? One
is an interface, while the other is an implementation that could be used
or extended.
Howard Lewis Ship wrote:
> The distinction, in my mind, is that AbstractEngine is incomplete (it has
> unimplemented abstract methods), while DefaultEngine would be a complete
> implementation that could be used as-is or extended.
>
> On 4/23/05, Kent Tong <ke...@cpttm.org.mo> wrote:
>
>>Karthik Abram <karthik.abram <at> neovera.com <http://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: tapestry-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: Naming intefaces and abstract classes
Posted by Patrick Casey <pa...@adelphia.net>.
Ideally a name should tell you two things:
Function
Implementation
IFoo tells you nothing about function, but tells you a lot about
implementation (it's an interface).
AbstractDieselEngine tells you A) it's a diesel engine and B) it's
abstract.
DieselEngine tells you A) it's a diesel engine and B) it's concrete
(but only if your convention is that "naked" names indicate concreteness.
If we're looking for a way to determine behavior (function)
differences based on names, I don't think prefix or suffix conventions are
going to do the job. These sorts of conventions are, imho, good at
describing implementation, but near useless at describing function.
That's a whole other question e.g. how to assign functionally
meaningful names.
--- Pat
-----Original Message-----
From: news [mailto:news@sea.gmane.org] On Behalf Of Kent Tong
Sent: Monday, April 25, 2005 6:32 PM
To: tapestry-user@jakarta.apache.org
Subject: Re: Naming intefaces and abstract classes
Patrick Casey <patcasey <at> adelphia.net> writes:
> > What if later you have a DieselEngine class (probably
> > implementing AbstractDieselEngine), how can you tell
> > the semantic difference between the two?
>
> I'm not sure I understand what you're asking here.
I'm saying if we have both DieselEngine and AbstractDieselEngine,
how can we tell their behavioral difference from their names?
For example, we have both Map and HashMap, from their names we
know that HashMap is using hashing to implement the map. So
the behavioral difference between Map and HashMap is pretty
clear.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Naming intefaces and abstract classes
Posted by Kent Tong <ke...@cpttm.org.mo>.
Patrick Casey <patcasey <at> adelphia.net> writes:
> > What if later you have a DieselEngine class (probably
> > implementing AbstractDieselEngine), how can you tell
> > the semantic difference between the two?
>
> I'm not sure I understand what you're asking here.
I'm saying if we have both DieselEngine and AbstractDieselEngine,
how can we tell their behavioral difference from their names?
For example, we have both Map and HashMap, from their names we
know that HashMap is using hashing to implement the map. So
the behavioral difference between Map and HashMap is pretty
clear.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Naming intefaces and abstract classes
Posted by Eli Doran <el...@gmail.com>.
I believe the difference between using the prefix with ISomeName and
AbstractSomeName is that you commonly use the interface to refer to an
instance but you do not refer to an instance using the Abstract* name.
So the "I" prefix is undesirable because of frequent use. The "Abstract"
prefix denotes an important distinction and even dissuades people from
using its name.
For example, we frequenly use Map to refer to map instances. How often
do we refer to them as AbstractMap ? Sometimes you do need to access the
concrete class and in this case, HashMap, it is a good name. It would
not be as *nice* to type IMap often or use MapImpl. Also, Naming
AbstractMap BaseMap or DefaultMap hides that it's a partial
implementation. Base* and Default* are good uses to define the commonly
used implementation of the interface its name implies exists. It also
shows that it was written to be extended or swapped out for a completely
different implementation of the interface.
I like it this way :)
enjoy,
eli
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: Naming intefaces and abstract classes
Posted by Patrick Casey <pa...@adelphia.net>.
<snip>
> AbstractEngine
> AbstractDieselEngine
> AbstractTurbineEngine
> AbstractPistonEngine
>
> ....
>
> At least that's the convention I generally go with.
What if later you have a DieselEngine class (probably
implementing AbstractDieselEngine), how can you tell
the semantic difference between the two?
I'm not sure I understand what you're asking here. When we're reading API
type code we're likely to run into either:
AbstractDieselEngine anEngine = (AbstractDieselEngine) MotorPool.getNext();
Or (more rarely in code using an API)
DieselEngine d = new DieselEngine();
In the former context, we don't care what the concrete class name is because
we're casting the class as abstract. We do however get a useful hint that
anEngine is an abstraction which we wouldn't get without the leading
Abstract in the classname.
In the latter case we know its concrete because we can see the constructor.
So in each case we have sufficient information to understand the code.
Or are you hoping to develop a naming convention that includes a hint for
concreteness in the name e.g. ConcreteDieselEngine? (I've read code like
that before and never liked it. It seems easier and more natural to me at
least to assume concreteness in the absence of other modifiers, but as
others have pointed out ymmv).
--- Pat
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Naming intefaces and abstract classes
Posted by Kent Tong <ke...@cpttm.org.mo>.
Patrick Casey <patcasey <at> adelphia.net> writes:
> > This is fine until we need a subclass extending AbstractEngine that
> > still keeps some methods abstract. Then we'll have trouble naming
> > that subclass because they're abstract too.
>
> AbstractEngine
> AbstractDieselEngine
> AbstractTurbineEngine
> AbstractPistonEngine
>
> ....
>
> At least that's the convention I generally go with.
What if later you have a DieselEngine class (probably
implementing AbstractDieselEngine), how can you tell
the semantic difference between the two?
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Naming intefaces and abstract classes
Posted by Jamie Orchard-Hays <ja...@dang.com>.
Excellent comments, Brian.
Jamie
On Apr 24, 2005, at 1:40 AM, Brian K. Wallace wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I think, aside from the brace positioning, we're going around in
> circles
> on things about which we just need to agree to disagree. If you have
> one
> developer, and one only, you're most likely to find a unanimous vote
> for
> or against names, or braces, or variables - but only "most likely".
> Things I do today are not what I see in code I wrote 10 years ago -
> part
> is experience - part is personal taste. Now we look at not just "more
> than one" developer, but a world-wide community? OMG if we could only
> get a unanimous vote for *anything* with diversity like that.
>
> I personally detest "I" for interfaces and "_" for variable prefixes.
> I'm not fond of "braces should line up" but it's better than seeing "I"
> in front of every interface. And I really like having "Abstract" ahead
> of anything... well... abstract. That said, I detest paying so much for
> gas and dealing with people who have no clue yet claim to be the
> "expert". Do I buy gas? yes. Do I deal with such people? yes. And I put
> "I" ahead of interfaces and use "_" as prefixes (for class-level) and
> my
> braces line up. Why? Because it works. I've grown very tired of "Impl"
> suffixes, and if you use "Page" for the interface, and you code only
> one
> implementation - what is it? BasePage? No, we went all the way and
> aren't using "Abstract" to denote an abstract class and BasePage
> already
> exists as an Abstract class. How about "DefaultPage"? Ok. Now look at
> your files: Page, BasePage, and DefaultPage. Without opening up your
> IDE
> - - what is what? And now we start adding more and more
> interfaces/abstract classes/implementations. What is "nice" ends up
> being an IDE-preferred view of the world. I love Eclipse (as others,
> I'm
> sure, love their IDE), but I do *occasionally* look at the JavaDoc even
> for projects where I'm the only person working on it - even more so for
> projects I do no development on. You can say "just look at the code -
> it's open source - that's the beauty of open source". And I'll say "no
> thank you - I just need clarification on the API". (Then I find out, of
> course, that since it's "open source" the JavaDoc sucks and I _have_ to
> look at the source [personal pet peeve about bad/lacking documentation
> for many projects, not just OS - as noted by many users and
> acknowledged
> by many developers], but that's missing the point.)
>
> I'd much rather have my interfaces grouped with my default
> implementation (which "Page" and "PageImpl" provides in my lovely IDE),
> but when every other file or so is "Impl" this or "Impl" that - *ugh*.
> I
> also like having my API jar'ed up separate from my implementation in
> some instances - completely throws my "grouped together" out the window
> if I have two separate source paths in "my lovely IDE". We give, we
> take, we drive on. I don't think most users care as much about the
> class/interface naming conventions as the do about API method naming
> ("rewind" anyone? - no dig there Howard, just that it's the single most
> 'misunderstood' method I see on the list). As a developer, I love
> knowing that any abstract class starts with "Abstract" - I'm a
> key-phrase junkie. "Starts with Abstract - hmmm... might have to
> subclass that one" - seems pretty simple to me. "AbstractDieselEngine"
> -
> hmmm... Bet I could subclass that one for a DieselEngine
> implementation.
> No JavaDoc needed, no source code to peruse at my leisure. Does that
> mean that I wouldn't work with "Engine" as the abstract, and "DEngine"
> as an abstract implementation of "Engine" intended for "Diesel"
> engines?
> Nope. Sure doesn't. Just nicer as a personal - non-IDE view the first
> way. And believe it or not, 99% of all developers I know have naming
> issues. "I have a class that does this, what should I name it?" It's an
> unwritten rule - you design, you code, you test (hopefully) - and you
> just run out of names that 1) apply and 2) make sense. But of those
> 99%,
> 100% don't really care how long it took me to name files any more than
> I
> care how long it took them. We do our best with what we have, and
> grumble about it later.
>
> So -
> +1 to any name you choose - we adapt and grumble about it regardless of
> what's chosen
> +1 to any code convention you choose - we adapt and grumble about it
> regardless of what's chosen
> - -1 to "but this is best because of my lovely IDE" - give a _real_
> answer
> not an IDE specific answer
> - -1 to breaking backward compatibility because "we've grown so we know
> now IPage is annoying where Page is not"
>
> and a resounding
> +1*** to "document it as a project level developer convention and
> revisit on the developer list if there are true (not imagined) reasons
> for changes." Hell, go ahead and document (as Howard has done) "This
> was
> a bad idea, but changing it would break compatibility." Nothing wrong
> with that. And those grumblings in the back with be there regardless.
>
> My .02... .03... $1.50
>
> Patrick Casey wrote:
> | Howard Lewis Ship <hlship <at> gmail.com> writes:
> |
> |
> |>The distinction, in my mind, is that AbstractEngine is incomplete
> (it has
> |>unimplemented abstract methods), while DefaultEngine would be a
> complete
> |>implementation that could be used as-is or extended.
> |
> |
> | This is fine until we need a subclass extending AbstractEngine that
> | still keeps some methods abstract. Then we'll have trouble naming
> | that subclass because they're abstract too.
> |
> | AbstractEngine
> | AbstractDieselEngine
> | AbstractTurbineEngine
> | AbstractPistonEngine
> |
> | ....
> |
> | At least that's the convention I generally go with.
> |
> |
> |
> | ---------------------------------------------------------------------
> | To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> | For additional commands, e-mail:
> tapestry-user-help@jakarta.apache.org
> |
> |
> |
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.5 (MingW32)
>
> iD8DBQFCazFNaCoPKRow/gARAjetAJ9C08c+b3gdbv3G34Bu1OHi4CNvFACg03BH
> 9l5je5nOTUudEkbAHr8JAfU=
> =OCn9
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Naming intefaces and abstract classes
Posted by Kent Tong <ke...@cpttm.org.mo>.
Brian K. Wallace <brian <at> transmorphix.com> writes:
> I think, aside from the brace positioning, we're going around in circles
> on things about which we just need to agree to disagree.
I agree the need to adopt a uniform coding convention for
a project. However, this doesn't contradict with the need
to discuss the pros and cons of the various coding
conventions.
> and if you use "Page" for the interface, and you code only one
> implementation - what is it? BasePage? No, we went all the way and
> aren't using "Abstract" to denote an abstract class and BasePage already
> exists as an Abstract class. How about "DefaultPage"? Ok. Now look at
> your files: Page, BasePage, and DefaultPage. Without opening up your IDE
> what is what?
This is indeed a problem. We have to ask how DefaultPage/AbstractPage
differs from BasePage. If we're talking about the Tapestry, I think
AbstractPage should be called DefaultPage or BasePage, while
BasePage should be called HTMLPage.
Or better still, currently in my opinion Tapestry uses too much
inheritance. I believe by using delegation most of the naming difficulties
can be solved. For example, the only difference between AbstractPage
and BasePage is just the use of an HTMLWriter. If AbstractPage
used delegation:
class AbstractPage {
public AbstractPage() {
useHTMLWriter();
}
public AbstractPage(MarkupWriter writer) { ... }
public void useHTMLWriter() {
writer = new HTMLWriter();
}
public void useWAPWriter() {
writer = new WAPWriter();
}
}
Then we can eliminate BasePage entirely. Our regular pages can
be like:
class Home extends AbstractPage {
}
class WAPHome extends AbstractPage {
public WAPHome() {
useWAPWriter();
}
}
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Naming intefaces and abstract classes
Posted by "Brian K. Wallace" <br...@transmorphix.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I think, aside from the brace positioning, we're going around in circles
on things about which we just need to agree to disagree. If you have one
developer, and one only, you're most likely to find a unanimous vote for
or against names, or braces, or variables - but only "most likely".
Things I do today are not what I see in code I wrote 10 years ago - part
is experience - part is personal taste. Now we look at not just "more
than one" developer, but a world-wide community? OMG if we could only
get a unanimous vote for *anything* with diversity like that.
I personally detest "I" for interfaces and "_" for variable prefixes.
I'm not fond of "braces should line up" but it's better than seeing "I"
in front of every interface. And I really like having "Abstract" ahead
of anything... well... abstract. That said, I detest paying so much for
gas and dealing with people who have no clue yet claim to be the
"expert". Do I buy gas? yes. Do I deal with such people? yes. And I put
"I" ahead of interfaces and use "_" as prefixes (for class-level) and my
braces line up. Why? Because it works. I've grown very tired of "Impl"
suffixes, and if you use "Page" for the interface, and you code only one
implementation - what is it? BasePage? No, we went all the way and
aren't using "Abstract" to denote an abstract class and BasePage already
exists as an Abstract class. How about "DefaultPage"? Ok. Now look at
your files: Page, BasePage, and DefaultPage. Without opening up your IDE
- - what is what? And now we start adding more and more
interfaces/abstract classes/implementations. What is "nice" ends up
being an IDE-preferred view of the world. I love Eclipse (as others, I'm
sure, love their IDE), but I do *occasionally* look at the JavaDoc even
for projects where I'm the only person working on it - even more so for
projects I do no development on. You can say "just look at the code -
it's open source - that's the beauty of open source". And I'll say "no
thank you - I just need clarification on the API". (Then I find out, of
course, that since it's "open source" the JavaDoc sucks and I _have_ to
look at the source [personal pet peeve about bad/lacking documentation
for many projects, not just OS - as noted by many users and acknowledged
by many developers], but that's missing the point.)
I'd much rather have my interfaces grouped with my default
implementation (which "Page" and "PageImpl" provides in my lovely IDE),
but when every other file or so is "Impl" this or "Impl" that - *ugh*. I
also like having my API jar'ed up separate from my implementation in
some instances - completely throws my "grouped together" out the window
if I have two separate source paths in "my lovely IDE". We give, we
take, we drive on. I don't think most users care as much about the
class/interface naming conventions as the do about API method naming
("rewind" anyone? - no dig there Howard, just that it's the single most
'misunderstood' method I see on the list). As a developer, I love
knowing that any abstract class starts with "Abstract" - I'm a
key-phrase junkie. "Starts with Abstract - hmmm... might have to
subclass that one" - seems pretty simple to me. "AbstractDieselEngine" -
hmmm... Bet I could subclass that one for a DieselEngine implementation.
No JavaDoc needed, no source code to peruse at my leisure. Does that
mean that I wouldn't work with "Engine" as the abstract, and "DEngine"
as an abstract implementation of "Engine" intended for "Diesel" engines?
Nope. Sure doesn't. Just nicer as a personal - non-IDE view the first
way. And believe it or not, 99% of all developers I know have naming
issues. "I have a class that does this, what should I name it?" It's an
unwritten rule - you design, you code, you test (hopefully) - and you
just run out of names that 1) apply and 2) make sense. But of those 99%,
100% don't really care how long it took me to name files any more than I
care how long it took them. We do our best with what we have, and
grumble about it later.
So -
+1 to any name you choose - we adapt and grumble about it regardless of
what's chosen
+1 to any code convention you choose - we adapt and grumble about it
regardless of what's chosen
- -1 to "but this is best because of my lovely IDE" - give a _real_ answer
not an IDE specific answer
- -1 to breaking backward compatibility because "we've grown so we know
now IPage is annoying where Page is not"
and a resounding
+1*** to "document it as a project level developer convention and
revisit on the developer list if there are true (not imagined) reasons
for changes." Hell, go ahead and document (as Howard has done) "This was
a bad idea, but changing it would break compatibility." Nothing wrong
with that. And those grumblings in the back with be there regardless.
My .02... .03... $1.50
Patrick Casey wrote:
| Howard Lewis Ship <hlship <at> gmail.com> writes:
|
|
|>The distinction, in my mind, is that AbstractEngine is incomplete (it has
|>unimplemented abstract methods), while DefaultEngine would be a complete
|>implementation that could be used as-is or extended.
|
|
| This is fine until we need a subclass extending AbstractEngine that
| still keeps some methods abstract. Then we'll have trouble naming
| that subclass because they're abstract too.
|
| AbstractEngine
| AbstractDieselEngine
| AbstractTurbineEngine
| AbstractPistonEngine
|
| ....
|
| At least that's the convention I generally go with.
|
|
|
| ---------------------------------------------------------------------
| To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
| For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
|
|
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
iD8DBQFCazFNaCoPKRow/gARAjetAJ9C08c+b3gdbv3G34Bu1OHi4CNvFACg03BH
9l5je5nOTUudEkbAHr8JAfU=
=OCn9
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: Naming intefaces and abstract classes
Posted by Patrick Casey <pa...@adelphia.net>.
Howard Lewis Ship <hlship <at> gmail.com> writes:
>
> The distinction, in my mind, is that AbstractEngine is incomplete (it has
> unimplemented abstract methods), while DefaultEngine would be a complete
> implementation that could be used as-is or extended.
This is fine until we need a subclass extending AbstractEngine that
still keeps some methods abstract. Then we'll have trouble naming
that subclass because they're abstract too.
AbstractEngine
AbstractDieselEngine
AbstractTurbineEngine
AbstractPistonEngine
....
At least that's the convention I generally go with.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Naming intefaces and abstract classes
Posted by Kent Tong <ke...@cpttm.org.mo>.
Howard Lewis Ship <hlship <at> gmail.com> writes:
>
> The distinction, in my mind, is that AbstractEngine is incomplete (it has
> unimplemented abstract methods), while DefaultEngine would be a complete
> implementation that could be used as-is or extended.
This is fine until we need a subclass extending AbstractEngine that
still keeps some methods abstract. Then we'll have trouble naming
that subclass because they're abstract too.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Naming intefaces and abstract classes
Posted by Howard Lewis Ship <hl...@gmail.com>.
The distinction, in my mind, is that AbstractEngine is incomplete (it has
unimplemented abstract methods), while DefaultEngine would be a complete
implementation that could be used as-is or extended.
On 4/23/05, Kent Tong <ke...@cpttm.org.mo> wrote:
>
> Karthik Abram <karthik.abram <at> neovera.com <http://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: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
RE: Naming intefaces and abstract classes
Posted by Patrick Casey <pa...@adelphia.net>.
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:news@sea.gmane.org] On Behalf Of Kent Tong
Sent: Saturday, April 23, 2005 6:05 PM
To: tapestry-user@jakarta.apache.org
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: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Naming intefaces and abstract classes
Posted by Kent Tong <ke...@cpttm.org.mo>.
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: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org