The programming philosophy of jrql
Download as PPTX, PDF0 likes635 views
The document discusses programming philosophies for writing flexible, reusable, and reliable code. It recommends: (1) writing classes and methods as services with public APIs and private implementations, (2) using descriptive names focused on functionality over implementation, (3) handling all possible usage scenarios, (4) writing thorough documentation, and (5) preventing errors. The document also discusses reducing repetition, writing focused single-task methods, following naming conventions, and not worrying about perceived code complexity from many short methods.
The programming philosophy of jrql
- 1. The programming philosophy of jRQL Frank Leja, May 2012
- 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!