if (myString.equals("hardcodedstring")) {
    // do something
}

if ("hardcodedstring".equals(myString)) {
    // do something
}

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);
 

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

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