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

http://sunnyratra.me/

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

http://sunnyratra.me/

Basic Object-Oriented Design Concepts

Eec1ve use of the fundamental object-oriented concepts can improve an applica1ons 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
http://sunnyratra.me/

Interface Inheritance
Interface inheritance is the separa1on of an interface deni1on 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.

http://sunnyratra.me/

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

http://sunnyratra.me/

Advantages for maintaining high Cohesion

Maintaining high cohesion has the following advantages: Avoids side aects 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.

http://sunnyratra.me/

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 dierent 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.
http://sunnyratra.me/

Coupling

http://sunnyratra.me/

Coupling
The following methods can help us to reduce coupling between classes: Hide the implementa1on of the classes. Couple the rst 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.
http://sunnyratra.me/

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.
http://sunnyratra.me/

Dierence 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.
http://sunnyratra.me/

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
http://sunnyratra.me/

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.
http://sunnyratra.me/

Favoring Composi1on

http://sunnyratra.me/

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.

http://sunnyratra.me/

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

http://sunnyratra.me/

J2EE and Design PaEerns

J2EE: AN OPERATING SYSTEM FOR THE WEB Enterprise web applica1ons, which live on networks and are accessible through browsers, are redening Enterprise Web SoZware. This is the next wave of compu1ng. Design PaEerns capture solu1ons that have developed and evolved over 1me . They reect untold redesign and recoding as developers have struggled for greater reuse and exibility 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.

http://sunnyratra.me/

Mul1-1ered J2EE applica1ons

J2EE Application I
Application Client

J2EE Application II
Dynamic HTML pages

Client tier

Client machine

JSP/Servlet

Web tier

J2EE Server machine

Enerprise Beans

Enterprise Beans

Business tier DataBase Server machine

Database

Database
http://sunnyratra.me/

EIS tier

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 (deni1on of the reoccurring diculty)

User interfaces change oZen, especially on the internet where look-and-feel is a compe11ve issue. Also, the same informa1on is presented in dierent 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.

http://sunnyratra.me/

MVC Structure for J2EE

http://sunnyratra.me/

MVC Structure for J2EE

http://sunnyratra.me/

J2EE Technologies in Tiers

http://sunnyratra.me/

J2EE Technologies in Tiers

The separa1on of the soZware system into ve 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 users requests.The Presenta1on 1er provides a buer 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.

http://sunnyratra.me/

J2EE Technologies in Tiers

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.

http://sunnyratra.me/

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

http://sunnyratra.me/

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.

http://sunnyratra.me/

Presenta1on Tier PaEerns

http://sunnyratra.me/

Model 2 Architecture

http://sunnyratra.me/

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.

http://sunnyratra.me/

Integra1on Tier PaEerns

http://sunnyratra.me/

Business 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 reect a business purpose. Business 1er paEerns: Organize business logic so that it is simple and uniform. Reduce coupling among components in dierent 1ers. Reduce network overhead.

http://sunnyratra.me/

Business Tier PaEerns

http://sunnyratra.me/

 Thank You !! Have A Nice Day

http://sunnyratra.me/