Adam Bien's Weblog

Monday Sep 21, 2009

Abstract, If, Impl, Default, Bean Conventions - Just For Lazy Developers

Using the prefix "abstract" to mark abstract classes is more a workaround or a shortcoming, than a best practice. Even worse is the introduction of naming conventions for interfaces with the only purpose: avoidance of interface naming collisions with their implementations. The convention "Default" is superfluous as well (what is "Default"?). Even the Remote and Local, Bean suffixes for EJBs are no more that interesting - the Beans are already annotated with the corresponding annotations. 

In general: all technical naming conventions are just too convenient. Instead of naming an artifact (class, interface etc.) after its essential responsibilities, it is lot easier to introduce some artificial conventions... It is better to avoid naming conventions and provoke so naming collisions. A naming collision could be an indicator of a superfluous class, interface or another artifact, which could be removed after such naming collision.

Exceptions from the rule: Some frameworks / code generators / patterns may require you to rely on technical naming conventions. This fact should be clearly documented - but it is still just a workaround.  


NEW: Java EE 7 Testing and Quality Workshop

A book about rethinking Java EE Patterns

Comments:

"Exceptions from the rule: Some frameworks / code generators / patterns may require you to rely on technical naming conventions. This fact should be clearly documented - but it is still just a workaround."

It's just a workaround but sometimes it saves a lot of necessary bundling.
For example ZKoss framework relies heavily on "convention coding". This allows you do something like this:

form.zul (html like markup):
<textbox id="firstName" />

Form.java (page logic behinf form.zul):
public void onClick$firstName(Event aEvent) {
firstName.setValue("Dracula");
}

And second good example (at least for me) which speeds up developing is searching for a particular class in IDE. It's much more easier if you know that class name starts/ends/contains some string e.g. UserInterface vs. UserBean. In class selector you can then just type UI or UB and you are in the intended class without inspecting annotations.

Posted by BladeRunner on September 21, 2009 at 07:22 PM CEST #

@BladeRunner,

"t's just a workaround but sometimes it saves a lot of necessary bundling.
For example ZKoss framework relies heavily on "convention coding". This allows you do something like this:

form.zul (html like markup):
<textbox id="firstName" />"

But this isn't redundant and perfect - it is DRY. But I wouldn't use an annotation or keyword AND a naming convention.

"It's much more easier if you know that class name starts/ends/contains some string e.g. UserInterface vs. UserBean"

I go even further, than that. E.g. in most projects I put the UI stuff into a ...presentation... package and the implementation of the business logic into ...business...

thank you!,

adam

Posted by Adam Bien on September 21, 2009 at 11:46 PM CEST #

neine neine neine

Posted by 80.1.94.250 on September 22, 2009 at 12:36 PM CEST #

Service service = new ServiceImpl();

mostly because my interfaces are exposed to the client while its implementations are hidden in the server side..

I also use the pattern of the classes to name it most of the time..

and you are right, we don't need that.. but far beyond the naming collision we have the purpose clarification and the educational powers of the type names. Otherwise, we can just name our classe like A, B, C .. :)

imho: it is really not so important :)

Posted by Felipe Gaúcho on September 23, 2009 at 03:21 PM CEST #

Post a Comment:
  • HTML Syntax: NOT allowed
realworldpatterns.com
...the last 150 posts
...the last 10 comments
Links
License