Java | Constructor vs. Method

If you are within your first year of application development in Java you may have asked yourself this question. I know I did.

What is the difference?

Java

Here is a reference list that I have compiled for your convenience.

Download the excel file and build upon other comparisons you need to keep track of –>constructor-vsmethods.xlsx

Topic

Constructors

Methods

Purpose

Create an instance of a class – Object Initialization Grouped Java statements – Each performs a small unit or task

Modifiers

No – Cannot be abstract, final, native, static, or synchronized, already marked as final & static. Yes – Can be abstract, final, native, static, or synchronized

Has a Return type

No – not even void Yes – void or a valid return type

Naming Convention

Same name as the class, first letter is capitalized by convention) — usually a noun Any name except the class. Method names begin with a lowercase letter by convention — usually the name of an action

Inheritance

No – Constructors are not inherited Yes – Methods are inherited

Compiler automatically supplies a default constructor

If the class has no constructor, a no-argument constructor is automatically supplied Does not apply

Compiler automatically supplies a default call to the super-class constructor

If the constructor makes no zero-or-more argument calls to super, a no-argument call to super is made Does not apply

Can be Overloaded/Overwritten?

Yes Yes

Can be public, protected, private?

Yes Yes

Must be same name as Class?

Yes No, arbitrary

chained and they are called in a particular order

Yes No

Model View Control

Introduction

MVC

MVC

Model View Control (MVC)  is a 3 level architecture that decouples the interface from navigation and application behavior, mostly because keeping the applications together creates a huge mess when it is time to redesign you program. MVC patterns will simplify implementation and greatly enhance re-usability. It should always be used in O.O.P. (object oriented programming)

Model

The term Model stands for Data Module Objects, it holds all the application state information (ie data) and all operations that can modify the data.

A model is a computational approximation or abstraction of real world process, entity, or system. An example is the shopping cart when you order an item on-line using e-commerce. It would hold the information of the order number, what is being ordered, the quantity being ordered, and all the code that could interact with this data usually in SQL code. It is also called business logic and provides the connections to the data source as well as to the controller.

View

The view contains the interface functions, it is the GUI code. It will produce all the visual components of your program. It provides the access to the data and processing logic to the user.

It needs to allow the user enough functionality to provide the user with the tools the program is being developed for.

The view is tied into the Data model, if you delete an item from a shopping cart it will be removed immediate or upon a page refresh usually from an Event Object handler that contains the change and then updates the cart to show a page in HTML with the previously deleted item gone.

For an inexpensive home server try a Linux server with Apache Web-server, a MySQL database and PHP coding. All the software can be installed for free.

Controller

As its name implies, the controller component controls the overall flow. The controller code interacts with the view and model components to deliver a modular yet integrated solution.

It is the Controller that accepts input from the user in a particular modality, interprets that input (the interpretation may depend on the View), and invokes the appropriate operation on the Model.

For example, when the Controller detects a mouse click event on the “remove” button of an item it invokes the remove operation on that item. Any state changes that this operation causes on the

Model are sent by the Model to the registered Views via events. The controller component is normally written in Java and implemented as a Servlet.

 MVC usage rules

In order to support reusability, the interactions which do occur should be well defined and the dependencies between the elements (M-V-C) should be minimized. One of the goals of the MVC pattern is to enable the combination of a single Model with multiple Views and Controllers. The MVC pattern ensures that the Views are kept synchronized. When the Controller recognizes a valid command from the user’s input, it invokes the corresponding method on the Model. The

Model verifies that the operation is compatible with its current state, executes it and changes the state of the Views correspondingly. The views, as they have registered themselves as observers, get now informed about the Model’s state change and update their rendering correspondingly.

 The dependencies must be kept minimal

To support multiple views and controllers the dependencies must be kept minimal.

 Note: A is said to be dependent on B when the code of A embeds knowledge about B.

This leads to the following rules:

  1.  The Model does not have any dependency on Views or Controllers.
  2.   A View depends on its associated Model. It has to know the structure of the Model’s state to be able to render it.
  3.   A View does not have a dependency on Controllers. Therefore several different Controllers can be associated with the same View.
  4.  A Controller depends on its associated Model and View. The Model defines the operations the Controller can invoke and the View defines the context in which the Controller interprets the user input. This makes the Controller tightly coupled to the View.

 The interactions must be kept minimal

Another precondition to support multiple Views and Controllers is to keep interactions minimal.

In particular a Controller must never directly affect the rendering of its associated View. Instead user input must make a complete round trip through the Model before its effects become visible in the View. This rule guarantees that a state change updates all Views and that the Views remain synchronized. Often implementations with a single Controller violate this rule because of sloppy

thinking: “I already know that this state change will occur, and therefore do not need wait for the Model to tell me about it”. This is wrong for two reasons:

1. The Model can veto the operation for some reason. The operation will not occur.

2. Other Controllers may concurrently invoke operations on the Model. Some other operation can slip in between, which fundamentally changes the rendering and makes any assumptions about it invalid.

In addition it is impossible to extend such shortcut implementations later with additional Controllers.

 The MVC pattern in Web applications

Although the MVC pattern was originally devised for the organization of fat client GUI libraries, it has in the past several years received widespread acceptance as a suitable architectural pattern for implementing Web based solutions, too. Its structure has been applied, (with limitations), in recent Web applications. This is not surprising, since in both cases the separation of concerns is the driving force behind architectural choices.

 Extending the MVC pattern to distributed applications

Although the MVC pattern was originally devised for GUIs running on a single machine, it can be extended relatively straightforward to distributed systems, where some interfaces between Model, View and Controller may cross the network. The placement of the Model, the View and the Controller then becomes a crucial issue.

The client-centric approach puts all three functions: Model, View and Controller on each client device. The Model, which exists conceptually only in one instance, is “replicated” among the devices. A replication protocol keeps the copies of the Model synchronized.

The server-centric approach puts both Controller and Model on a server. The client devices contain only the Views.

 Why you should MVC

  • Separation of data from presentation

Drawbacks on MVC

  • Is not easy and requires planning
  • Thorough testing and more files needed
  • May overkill small applications

Develope a Web Based CMS Using PHP

Download this File Here

Abstract
The Content Management System (CMS) is a web based application using a Linux Server,
Apache Web-server, MySQL Database, and PHP Programming Language (LAMP). The
objective of managing users, and information in any given network environment can only be
hindered by the creativity of an information technology professional and not by technology. The
main objective of this thesis is to develop the early development steps of a LAMP software bundleCMS. By creating the
building blocks for developing, and taking into consideration basic methods for creating the core
platform of a CMS for further development. All information gathered, and experience gained will
assist with developing and offering my own personal e-commerce business solutions in the future
and to obtain additional business and practical knowledge in an open source software and ecommerce.
Continue reading