j2ee design pattern

J2EE Design Pattern: Part I (Basic OOPS Concept & Introduction to Patterns)

Sunny Ratra http://sunnyratra.me/

Course Prerequisites & Objec1ves

•  Prerequisites –  Basic knowledge of OOPS concept –  Basic knowledge of J2EE framework

•  Objec1ves –  To provide an overview of OOPS Concept & Introduc1on to J2EE Design PaEern

http://sunnyratra.me/

Session Outline •  Design Goals •  Basic Object-‐Oriented Design Concepts •  Object-‐Oriented Design Principles •  J2EE and Design PaEerns •  Mul1-‐1ered J2EE applica1ons •  Architectural PaEerns : Details of MVC Design PaEern •  J2EE Technologies in Tiers •  J2EE PaEern Catalog •  Presenta1on Tier PaEerns •  Integra1on Tier PaEerns •  Business Tier PaEerns


Design Goals

The design principles and paEerns are tools that help us to achieve the following design goals : •  Adaptability •  Extensibility •  Maintainability •  Reusability •  Performance •  Scalability •  Reliability •  Security


Basic Object-‐Oriented Design Concepts

Effec1ve use of the fundamental object-‐oriented concepts can improve an applica1on’s design. These fundamental concepts are the founda1on that object-‐oriented design paEerns and J2EE paEerns build upon. The following object-‐oriented concepts are presented: •  Encapsula1on •  Polymorphism •  Implementa1on inheritance •  Interface inheritance •  Cohesion •  Coupling •  Composi1on


Interface Inheritance Interface inheritance is the separa1on of an interface defini1on from its Implementa1on. While implementa1on inheritance can cause 1ght coupling, interface implementa1on can help maintain loose coupling. When a class implements a Java interface, the class does not inherit any implementa1on, only the interface. Thus, there is a separa1on of the interface and the implementa1on.


Cohesion

Cohesion is the degree to which the methods and aEributes of a class focus on only one purpose in the system. The following describes the two ends of the cohesion con1nuum: four different levels of coupling are shown: •  Low cohesion – Many unrelated func1ons within the same component Big classes with many unrelated func1ons are usually hard to maintain. •  High cohesion – Only related func1ons within the same component Small classes with fewer, highly related func1ons are usually easier to maintain.


Advantages for maintaining high Cohesion

Maintaining high cohesion has the following advantages: •  Avoids side affects of changing unrelated code within the same class. •  Improves code readability by clarifying the role of a class. •  Facilitates the crea1on of small reusable components.


Coupling

Coupling is a measure of how dependent classes are on other classes. The 1ghter The coupling between two classes, the more likely that a change in one class will require a change in the second class. four different levels of coupling are shown: •  Tight coupling – The Client class is a subclass of the Service class. Subclasses are exposed to the internal implementa1on of their superclass. •  Looser coupling – A Client class directly references the Service class and is exposed to all of the Service classes’ public methods and aEributes. •  Looser abstract coupling – The Client class references the ServiceImpl class through an interface. It is only exposed to the parts of the ServiceImpl class exposed to the interface. •  No coupling – The Client class has no reference to the Service class at all.


Coupling


Coupling

The following methods can help us to reduce coupling between classes: •  Hide the implementa1on of the classes. •  Couple the first class to only the abstract interface of the second class. •  Reduce the number of methods in the interface of the class. Some1mes, it is more worthwhile to look at the coupling of the en1re system, than between individual classes. It is impossible to eliminate coupling and retain a useful system. Without coupling, classes cannot communicate with other classes. Therefore, the goal is to keep reasonably loose coupling between objects, while not limi1ng the func1onality of the system.


Composi1on

Composi1on is a loosely coupled rela1onship between classes based on delega1on rather than reliance on implementa1on details. The composi1on aggrega1on rela1onship is just another form of the aggrega1on rela1onship, but the child class's instance lifecycle is dependent on the parent class's instance lifecycle. A company class instance will always have at least one Department class instance. Because the rela1onship is a composi1on rela1onship, when the Company instance is removed/destroyed, the Department instance is automa1cally removed/destroyed as well.


Difference between Aggrega1on, Composi1on and Delega1on

•  Aggrega7on: When object consists of other objects which can live even aZer object is destroyed. This type of rela1onship applies to designs where the "part" object can exist in other places in the system and does not en1rely depend upon a par1cular "whole" object for its existence.

•  Composi7on: When object consists of other objects which in turn cannot exist aZer my object is destroyed-‐garbage collected. This type of rela1onship applies to designs where the "part" object cannot exist in other places in the system and is en1rely dependent upon a par1cular "whole" object for its existence.

•  Delega7on: When object uses another object's func1onality as is without changing it.


Object-‐Oriented Design Principles

The following GoF principles can help you achieve the J2EE pla\orm design goals. These design principles build upon the fundamental object-‐oriented concepts and provide a founda1on for the Gang of Four design paEerns: •  Favoring composi1on •  Programming to an interface •  Designing for change


Favoring Composi1on

Favor object composi1on over [implementa1on] inheritance. •  Implementa7on inheritance is white-‐box reuse : In other words, the subclass is Exposed to the internal implementa1on of the superclass through inheritance. •  Composi7on is black-‐box reuse : In other words, the client class is Exposed only to the interface of the class that it uses. Thus the coupling between the Classes that use composi1on is looser.


Favoring Composi1on


Programming to an Interface

Program to an interface, not an implementa1on. This principle is more formally stated as the Dependency Inversion Principle. This principle says that classes should depend upon abstrac1ons, not on implementa1ons.


Designing for Change

This principle is more formally stated as the Open-‐Closed Principle. It states That soZware en11es, such as classes, should be open for extension, but closed for Modifica1on. The requirements for applica1ons always change, you should create systems that are adaptable and support new and changing requirements, without having major redesigns or having changes ripple through large parts of the system.


J2EE and Design PaEerns

•  J2EE: AN OPERATING SYSTEM FOR THE WEB Enterprise web applica1ons, which live on networks and are accessible through browsers, are redefining Enterprise Web SoZware. This is the next wave of compu1ng.

•  Design PaEerns capture solu1ons that have developed and evolved over 1me . They reflect untold redesign and recoding as developers have struggled for greater reuse and flexibility in their soZware.”-‐ GOF in Design PaEerns -‐ Elements of Reusable Object Oriented SoZware.

•  The J2EE architecture is built to enable component developers to use a Model View Controller (MVC) Design PaHern.


J2EE Application I J2EE Application II

Client tier

Web tier

Business tier

EIS tier

Client machine

J2EE Server machine

DataBase Server machine

Application Client

Dynamic HTML pages

JSP/Servlet

Enterprise Beans

Database Database

Enerprise Beans

Mul1-‐1ered J2EE applica1ons


Architectural PaHerns : Details of MVC Design PaHern

The Model View Controller (MVC) paEern is an architectural paEern. •  Name (essence of the paEern)

–  Model View Controller MVC

•  Context (where does this problem occur) –  MVC is an architectural paEern that is used when developing

interac1ve applica1on such as a shopping cart on the Internet.

•  Problem (defini1on of the reoccurring difficulty)

–  User interfaces change oZen, especially on the internet where look-‐and-‐feel is a compe11ve issue. Also, the same informa1on is presented in different ways. The core

business logic and data is stable. http://sunnyratra.me/

MVC con1nued Solu7on (how do you solve the problem)

–  Use the soZware engineering principle of “separa1on of concerns” to divide the applica1on into three areas:

•  Model encapsulates the core data and functionality

•  View encapsulates the presentation of the data there can be many views of the common data

•  Controller accepts input from the user and makes request from the model for the data to produce a new view.


MVC Structure for J2EE


J2EE Technologies in Tiers


The separa1on of the soZware system into five major 1ers: •  Client – Provides user interac1on with the system.The Client 1er

encompasses all of the components used by the user to interact with the system

•  Presenta7on – Provides the Web pages and forms that are sent to the

Web browser and processes the user’s requests.The Presenta1on 1er provides a buffer between a thin client and the Business 1er.

•  Business – Provides the business services and en11es.The Business 1er

provides the components that manage the business logic, rules, and en11es of the applica1on.



•  Integra7on – Provides components to integrate the Business 1er with the Resources 1er.The Integra1on 1er provides components that perform the fundamental create, retrieve, update, and delete (CRUD) opera1ons for a given business en1ty. •  Resource – Contains all back-‐end resources, such as a DataBase Management System (DBMS) or Enterprise Informa1on System (EIS).The Resource 1er includes all external systems that record business data.



J2EE PaEern Catalog

The J2EE paEerns catalog is grouped into 1ers. This par11oning is logical rather than physical. The three 1ers are:

•  Presenta1on 1er •  Business 1er •  Integra1on 1er


Presenta1on Tier PaEerns The presenta1on 1er manages the user interface to the applica1on. This 1er is primarily implemented with servlets, JSP pages, helper beans, and custom tags. Presenta1on Tier paEerns focus on achieving these goals:

•  Provide guidance for designing individual presenta1on 1er components by role.

•  Provide mechanisms to reduce copy-‐and-‐paste reuse. •  Enforce role separa1on between logic and presenta1on components.


Presenta1on Tier PaEerns


Model 2 Architecture


Integra1on Tier PaEerns Integra1on 1er paEerns are one set of J2EE paEerns provided by the Java Center program. Integra1on 1er paEerns encapsulate access to the data stores used by a J2EE pla\orm applica1on. This encapsula1on focuses on managing

the details needed to load and store data, frequently rela1onal data, on behalf of enterprise classes. The integra1on 1er also maintains responsibility for providing access to auxiliary services such as messaging to the business 1er. Finally, integra1on 1er paEerns deal with integra1ng web services with business 1er components.


Integra1on Tier PaEerns


Business 1er paEerns have a twofold role, stemming from their posi1on between the integra1on and presenta1on 1ers. It provide the logic that operates on stored data and shapes it to reflect a business purpose. Business 1er paEerns: •  Organize business logic so that it is simple and uniform. •  Reduce coupling among components in different 1ers. •  Reduce network overhead.

Business Tier PaEerns


Business Tier PaEerns


Thank You !! Have A Nice Day


j2ee design pattern

Documents