Win a copy of liveProject: Build an ML Recommender System this week in the Artificial Intelligence and Machine Learning forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • paul wheaton
  • Devaka Cooray
Sheriffs:
  • Jeanne Boyarsky
  • Tim Cooke
  • Liutauras Vilda
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
  • Piet Souris
Bartenders:
  • salvin francis
  • Mikalai Zaikin
  • Himai Minh

Java Code Conventions

 
Ranch Hand
Posts: 584
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Fellow Ranchers,

I'm not sure whether this is the best forum for asking this. So, if not, please moderators redirect me to the correct one.

My question is simple : Where can I find the code conventions guide lines for coding Java apps ? Specially regarding interfaces and concrete class names.

For instance, what is more correct ?



I've already see both approaches but, what is the best approach if I'm planning to submit code for SCJD certification ?

TIA,
Edisandro Bessa.
[ October 03, 2006: Message edited by: Edisandro Bessa ]
 
author and iconoclast
Posts: 24203
44
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The first is definitely more common in Java.
 
Ranch Hand
Posts: 385
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
They usually call default implementations like "DefaultCellEditor", in JDK.
 
Ranch Hand
Posts: 1855
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Edisandro,

it's not good practice to name your Interfaces with a prefix like I or your abstract classes with A because it disturbs the readibility of your architecture.

I didn't use this practice at all in my SCJD and got a high score.

Regards,
Darya
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Darya Akbari:

it's not good practice to name your Interfaces with a prefix like I or your abstract classes with A because it disturbs the readibility of your architecture.



I thought that too, until I actually tried it. We are now using the I prefix for interfaces since, I think, two to three years, and I'm now of the opinion that it actually *helps*. Interfaces and classes work differently enough that it seems to be helpful to know what you are currently using.
 
Ranch Hand
Posts: 580
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Interfaces and classes work differently enough that it seems to be helpful to know what you are currently using.



In what ways do you mean? I would have thought that it is best to not know or care if an interface is concrete or abstract.

D.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Don Kiddick:

In what ways do you mean? I would have thought that it is best to not know or care if an interface is concrete or abstract.



I would have thought that, too. In fact I was totally surprised by that experience - and I can't really tell where it's coming from. I just know that, when using thirdparty libraries or old code that hasn't been moved to the new convention yet, I keep finding myself thinking "rats, why isn't the type of that variable an interface? Oh, well, it is - thanks god."

Mhh, as I think about it, it's probably because then I know that I can easily assign that variable a totally different implementation, such as a null implementation or something.

With other words, using interfaces makes the code so much more flexible, and often it's important to know whether the code is that flexible or not.
 
Sheriff
Posts: 6920
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I agree with Don (and many others). You should be free to change from an interface to a class without affecting the client code. Just give it a name which describes its intent, and don't bother with "warts" which say how it is implemented.

On a slightly separate note I have a personal (minor) crusade against the term "impl" and the way it is used in so much Java code.

"Impl" is (in effect) a way of saying that this is the only implementation of an interface, and you can't imagine any other. This is almost always a poor choice - the whole point of Java interfaces is to allow multiple interchangeable implementations. "Impl" is a redundant term, which communicates nothing new to a reader (for example in the declaration class ActionImpl implements Action we know it is an implemntation of interface "Action" from the "implements Action".) Why waste a valuable name saying again something which is written right next to it.

Please reconsider using "impl" and think of a way of describing what makes this implementation special.

My personal preference is to use prefix terms; so for an interface DatabaseModel I might name a first implementation SimpleDatabaseModel, or MockDatabaseModel or ProductionDatabaseModel or TestDatabaseModel or LiveDatabaseModel or whatever.

Help stamp out "impl".
 
Edisandro Bessa
Ranch Hand
Posts: 584
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi dudes.

I'm glad to see your so prompt replies.

I'd really to thank everyone.

Many things were pointed out here but I'm particularly tempted to agree with Frank.

Without explicitly putting the word Impl your code remains cleaner and even clients who use these classes or interfaces in fact don't know whether or not they are using an interface or class at all.



Frank Carver Wrote ...

"Impl" is (in effect) a way of saying that this is the only implementation of an interface, and you can't imagine any other. This is almost always a poor choice - the whole point of Java interfaces is to allow multiple interchangeable implementations. "Impl" is a redundant term, which communicates nothing new to a reader (for example in the declaration class ActionImpl implements Action we know it is an implemntation of interface "Action" from the "implements Action".) Why waste a valuable name saying again something which is written right next to it.

Please reconsider using "impl" and think of a way of describing what makes this implementation special.

My personal preference is to use prefix terms; so for an interface DatabaseModel I might name a first implementation SimpleDatabaseModel, or MockDatabaseModel or ProductionDatabaseModel or TestDatabaseModel or LiveDatabaseModel or whatever.



Lucky words.

Thank you very much guys for your prompt replies.
[ October 04, 2006: Message edited by: Edisandro Bessa ]
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Frank Carver:
I agree with Don (and many others). You should be free to change from an interface to a class without affecting the client code.



In theory, I agree. In practice, this hasn't been much of a problem for us. The balance turned out to be different from what I expected.

On a slightly separate note I have a personal (minor) crusade against the term "impl" and the way it is used in so much Java code.



That's where I'm happy to join!
 
Ranch Hand
Posts: 308
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
i switched to the prefix I for interface some time ago. and i think it greatly helps readablity if you just look at packages and classes (as filenames) and not directly inside the class.
further more inside code (production and tests) it is just plain clear if you got fields of interfaces or real implementations.

in former times i got a bit annoyed by C++ classes (where this naming is quite common) with prefixed I until i just tried it out myself with java and after a while i got to appreciate it.

so i totally agree with Ilja Preuss.

so try it out and decide after a while if you like it or not.
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I believe there is no "right" answer, just what works for you, but I've been removing the I prefix (learned in PowerBuilder I think) from my things. When you use List do you care whether it's a class or an interface? I want to not care for as long as possible.

I have recently made some hierarchies with interface Whatever and an AbstractWhatever. The intent (not enforced) is that nobody would ever reference type AbstractWhatever outside an extends clause, only the interface. I started to make a DefaultWhatever the other day but decided to give it a more descriptive name like NonValidatingWhatever.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Stan James:
I believe there is no "right" answer, just what works for you



I agree. As I said, it's a balance, and it's not hard to imagine that the balancing point is different depending on circumstances and personal taste.

I've been removing the I prefix (learned in PowerBuilder I think) from my things. When you use List do you care whether it's a class or an interface? I want to not care for as long as possible.



That's interesting. As I tried to indicate above, I find that using interfaces adds convenient flexibility, so often enough I *do* care.

Can you elaborate on what makes you not to want to care? Thanks!

I have recently made some hierarchies with interface Whatever and an AbstractWhatever. The intent (not enforced) is that nobody would ever reference type AbstractWhatever outside an extends clause, only the interface. I started to make a DefaultWhatever the other day but decided to give it a more descriptive name like NonValidatingWhatever.



Sounds good!
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Can you elaborate on what makes you not to want to care?



I'm old, losing brain cells right and left, and just want to know as little as possible. It kind of works well with that whole abstraction thing.
[ October 05, 2006: Message edited by: Stan James ]
 
Don Kiddick
Ranch Hand
Posts: 580
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Argueing with myself now, but I guess one way in which you care if something is an interface or a class is how you can extend it. I have to extend a class, using my 'one-shot' concrete inheritance whereas I have to implement an interface. Anyway as stated, it's a matter of taste.

Totally agree on the impl thing. I use things like SimpleWhatever, BasicWhatever and DefaultWhatever - not sure how much information this gives then WhateverImpl though!

D.
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I wonder if this would have different answers if the abstraction's whole purpose in life is for future generations of coders to extend and implement like ActionListener (without an I) vs an abstraction that is meant to hide details, like ResultSet. Or not.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Stan James:
I wonder if this would have different answers if the abstraction's whole purpose in life is for future generations of coders to extend and implement like ActionListener (without an I) vs an abstraction that is meant to hide details, like ResultSet. Or not.



Good question! My first gut feel says "no, not", but I'm really not sure. In fact I'm not sure whether the distinction feels reasonable to me...
 
Frank Carver
Sheriff
Posts: 6920
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It just occurred to me that perhaps this is a slightly broader design and naming issue too.

Thinking about my own designs, I guess the reason I never use an "i" prefix is because I can almost always tell from the name whether something is a class or an interface. Something with a simple name (Fetcher, Repository, Request, ...) is usually an interface. Anything with a decorated name (DirectoryFetcher, MapRepository, ProductPurchaseRequest, ...) is usually a concrete class

The same approach can often be seen in the standard java APIs, too. Stan mentioned List, which is obviously an interface, just as ArrayList is obviously a class.

For those of you who find yourself using an "i" prefix, do you use a different naming convention? What value might a prefix give beyond the value of simple naming techniques such as I have described?
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Frank Carver:
What value might a prefix give beyond the value of simple naming techniques such as I have described?



I think I would have trouble coming up with a simpled, but still descriptive name for every one of our interfaces.
 
It's never done THAT before. Explain it to me tiny ad:
Thread Boost feature
https://coderanch.com/t/674455/Thread-Boost-feature
reply
    Bookmark Topic Watch Topic
  • New Topic