2. My goals
You wanna …
• be flexible and agile for changing customer demands?
• develop faster in the long run without reducing quality?
• don‘t invent the wheel again and again?
• write reliable code?
• write errorless code?
• write highly reusable code?
… check out this guide, if you want to improve your style!
take the chance
… follow these small steps to improve yourself …
3. You write services!
Think of every class and method
as a service you provide
for users not having your knowledge of the domain. unmistakable
Means
• your classes and methods forms an API
• tell your users with your code what they can do (public)
• how you do it (implementation) is private (encapsulation), could be changed!
• public method and parameter names focus on what not how
• take 10s to think on good names!
reliable
• all possible usage scenarios should work! (formBean setter problem)
• or force user for only one usage possibility (method calling order)
• caches has to be maintained transparently (for the user) (e.g. in instance variables)
• full javadoc with all parameters and possible return values described
• handle every problem, even it „could not happen“ (prevent NullPointerExceptions)
4. think on options: see this
ProjectDetailsFormBean public void saveProjectDetails(ProjectDetailsFormBean formBean) {
.setBpm(String)
.setDescription(String) // write the data into CRX
this.setProperty(ProjectConstants.DESCRIPTION, formBean.getDescription());
.setEndDate(Calendar) this.setProperty(ProjectConstants.OWNER, formBean.getBpm());
.setItm(String) this.setProperty(ProjectConstants.OWNER2, formBean.getItm());
.setName(String) this.setProperty(ProjectConstants.START_DATE, formBean.getStartDate());
.setStartDate(Calendar) this.setProperty(ProjectConstants.END_DATE, formBean.getEndDate());
.setStatus(String) this.setProperty(ProjectConstants.STATUS, formBean.getStatus());
If not all set* methods used, the save method will go wrong.
How can this problem be solved?
1. with FormBean? my option:
2. without FormBean? • no form bean at all, bc only used once for all attributes
• direct usage of parameter values in method
What do you prefer and why?
5. Think on all options and decide wisely and
consious
there are always options how to solve a problem or implement a task
1. think on all possible options you could imagine
2. for every option think on the pros and cons
3. choose the option which best matches the goals given in this guide
6. Dry
Never break this rule!
Easy to
Don‘t repeat yourself! or Once and Only Once (see wikipedia) change
public method1() {
if (getOwnerProfile() != null) {
public boolean hasOwnerProfile() {
…
return getOwnerProfile() != null;
public method2() {
}
if (getOwnerProfile() != null) {
… Safe to
change
StringBuilder sb = … StringBuilder sb = …
If (sb.toString().length() >5) { String currentName = sb.toString();
node.getNode(sb.toString()); If (currentName.length() >) {
node.getNode(currentName);
reusable
• every check should go into a new check method (is*, has*, exists*)
• every repetition within a method should use a local variable or new method
• find the right class for the new method to re-use it from everywhere you need it
7. One method = one task!
Every method should solve only ONE task!
flexible
One method = one task
This will result typically into many short methods with only some lines of code (<10 w/o
catches), often <5 lines
• check methods return boolean (is*, has*, exists*)
• very short attribute methods (get*, set*) reusable
• every conversion as gettter too (date formatting)
• new types of method parameters supported with new method
• action methods with other verbs
easy to
Benefits? understand
• better possibility for reusing a task
• easy to assemble into new tasks with more power (more abstract)
• even the main program code could be only 1 page long!
8. naming convention for getter
private Entity getEntity() {
…
}
keep
public String getEntityName() { control
return getEntity().getName();
}
public String getEntityDescription() {
return getEntity ().getDescription();
}
public String getEntityEmail() {
return getEntity ().getEmail();
}
prevent exposing an entity, because you break encapsulation
if you do it, think carefully on the consequences!
no conversion possible (show blank, if entity could not found)
no lazy initialisation possible
9. How I implement a method
1. visibility of method
(public, private)
2. name of method
(think on WHAT not how; the kind of implementation is never stated in the name!)
3. how many input parameters?
4. type of input parameters?
(prefer an object over primitive types like String to keep signature stable)
5. return value
(reduce void, return what makes sense, even you don‘t need it yet)
6. now write the method‘s signature
7. write the methods javadoc explanation
(sometimes a better method name comes into my mind, than adjust)
8. implement functionality
9. sit back and check the method‘s implementation
(all possible return values of used methods handled?)
10. sit back and think on the big picture
(can this method be used at any time and all circumstances?)
10. Monitor cheat sheet hang on your
monitor
Issues Recommended action
method name tell about how implemented? rename to tell what it does, not how
long method? refactor | extract methods to shorten it
exposing entity? implement getter for all needed attributes
first thought implemented? think on other options and decide wisely
method called twice for return value refactor | extract local variable
all (instance var) caches maintained? update when set, or set to null
checkstyle complaints? fix them all!
unused or unwanted methods still there? remove first thought not needed anymore
11. You are free!
there is no limitation for the number
• of methods of a class
• of method parameters
A class represents an item from your domain, regardless how many methods it
needs.
A class should not be splitted only because of the number of methods!
By the way, prevent static helper methods, because you will never get them in the
code completion feature of your IDE.
Instead implement methods on your API classes you can re-use!
12. forget about complains
The most often complain I heard for this programming style is:
too many methods on a class are not maintainable
This comes, because you try to understand all code of a class at the same time.
I think on a method as a service I offer to the users of my class.
For implementing a new service (method) I only have to understand how to achieve this.
I can concentrate of implementing this one service (method) right,
without a need to understand all the other methods available.
Of course, I can call other methods to provide the new service (method).
(This might be a Java specific problem, because Java handle a whole classes source into 1 file.
In Smalltalk a file for class doesn‘t exists, only a list of methods you have to check one-by-one.)
13. Conclusion
If you want to
• be agile and flexible
• write safe and reliable code and
• develop fast at still high quality,
you have to re-use your code as much as you can!
In the long term you would be faster as a programmer doing the same stuff again and again.
Only because of the consequent usage of these principles jRQL
• can offer functions from such a wide range
• is reliable and stable
• and still easy to enhance!
