The programming philosophy of jrql

706 views
645 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
706
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

The programming philosophy of jrql

  1. 1. The programming philosophy of jRQLFrank Leja, May 2012
  2. 2. My goalsYou 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. 3. You write services!Think of every class and methodas a service you providefor users not having your knowledge of the domain. unmistakableMeans• 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. 4. think on options: see thisProjectDetailsFormBean 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. 5. Think on all options and decide wisely and consiousthere are always options how to solve a problem or implement a task1. think on all possible options you could imagine2. for every option think on the pros and cons3. choose the option which best matches the goals given in this guide
  6. 6. DryNever break this rule! Easy toDon‘t repeat yourself! or Once and Only Once (see wikipedia) changepublic method1() {if (getOwnerProfile() != null) { public boolean hasOwnerProfile() {… return getOwnerProfile() != null;public method2() { }if (getOwnerProfile() != null) {… Safe to changeStringBuilder 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. 7. One method = one task!Every method should solve only ONE task! flexibleOne method = one taskThis will result typically into many short methods with only some lines of code (<10 w/ocatches), 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 toBenefits? 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. 8. naming convention for getterprivate Entity getEntity() {…} keeppublic 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 encapsulationif you do it, think carefully on the consequences!no conversion possible (show blank, if entity could not found)no lazy initialisation possible
  9. 9. How I implement a method1. 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 signature7. write the methods javadoc explanation (sometimes a better method name comes into my mind, than adjust)8. implement functionality9. 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. 10. Monitor cheat sheet hang on your monitorIssues Recommended actionmethod name tell about how implemented? rename to tell what it does, not howlong method? refactor | extract methods to shorten itexposing entity? implement getter for all needed attributesfirst thought implemented? think on other options and decide wiselymethod called twice for return value refactor | extract local variableall (instance var) caches maintained? update when set, or set to nullcheckstyle complaints? fix them all!unused or unwanted methods still there? remove first thought not needed anymore
  11. 11. You are free!there is no limitation for the number• of methods of a class• of method parametersA class represents an item from your domain, regardless how many methods itneeds.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 thecode completion feature of your IDE.Instead implement methods on your API classes you can re-use!
  12. 12. forget about complainsThe most often complain I heard for this programming style is:too many methods on a class are not maintainableThis 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. 13. ConclusionIf 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!

×