Design Patterns

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).
For example, this code can generate a NullPointerException if myString is null (bad):

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
{
string Color { set; }
int Height { set; }
int Length { set; }
int Depth { set; }
}

public class ConfigurationFluent : IConfigurationFluent
{
string color;
int height;
int length;
int depth;

public IConfigurationFluent SetColor(string color)
{
this.color = color;
return this;
}

public IConfigurationFluent SetHeight(int height)
{
this.height = height;
return this;
}

public IConfigurationFluent SetLength(int length)
{
this.length = length;
return this;
}

public IConfigurationFluent SetDepth(int depth)
{
this.depth = depth;
return this;
}
}

IConfigurationFluent fluentConfig =
new ConfigurationFluent().SetColor("blue")
.SetHeight(1)
.SetLength(2)
.SetDepth(3);

MVC

Model: 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 Configuration

For 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.











Subpages (3): AOP Code Style IoC
Comments