You can avoid many NullPointerExceptions by simply always placing
hardcoded string and constants on the left side of an object comparison.
This works well for any object constants (not just strings). if (myString.equals("hardcodedstring")) { // do something } This example code can never generate a NullPointerException (good): if ("hardcodedstring".equals(myString)) { // do something } Fluent Interface (Method Chaining)As in Jquery, implemented by using method chaining to relay the instruction context of a subsequent call public interface IConfiguration MVCModel: business entity objects, and their relationships rules. (reusable plain old java class) Control: Receives the request from the View and translates it to a Model understandable form. View: Translates user actions to a unique application-specific protocol and sends it to the Control. Receives an object(set of objects) and just displays them. no method call or logic is performed. - to maintain replace-ability, separation from control duties that might change later on. separate control from GUI that might change later on. - easier version control, non-mixed up of display & logic Separation of Model, Control and View; so that each one is separate and replaceable without altering others. We can use interfaces between these to ensure independence. - if a servlet (as a controller) gets in direct calls to a JSP file for view purposes, then we can not have our application for mobile phones or plain local application GUIs without servlets or web servers. View-Interface-Control-Model-Interface(ORM)-DB * With MVC the business logic is not only separate from the presentation ... It doesn't even know there IS a presentation. InputSignUpModel-InputSignUpServlet-InputSignUpJSP (for each page, there is a Servlet controller, a Java class model, and a JSP GUI tomcat is a web container in a web server called apache * The model shouldn't be tied down to being used by a single web application, so it should be in its own utility packages. (usually in different package structures from the control.) Convention over ConfigurationFor example, if there's a class Sale in the model, the corresponding table in the database is called sales by default. It is only if one deviates from this convention, such as calling the table "products_sold", that one needs to write code regarding these names. <<<When the convention implemented by the tool you are using matches your desired behavior, you enjoy the benefits without having to write configuration files. When your desired behavior deviates from the implemented convention, then you configure your desired behavior.>>> Some frameworks need multiple configuration files, each with many settings. These provide information specific to each project, ranging from URLs to mappings between classes and database tables. A large number of configuration files with lots of parameters is often an indicator of an unnecessarily complex application design. e.g. Hibernate XML vs annotations or java beans. |