Bean Introspection  «Prev  Next»
Lesson 4Types of design patterns
ObjectiveWhat are some of the various types of design patterns?

Design Pattern Types

There are a variety of different design patterns for specifying everything from simple properties to event sources.
All design patterns rely on some type of consistent naming convention for methods and their related arguments and data types.
Keep in mind that the automatic approach to introspection provided by design patterns is not only convenient from the perspective of JavaBeans, but it also has the intended side effect of encouraging Bean developers to write more structured code.
Following are the two major types of design patterns:
  1. Property design patterns
  2. Event design patterns
In the J2EE programming domain there are two major types of design patterns.
  1. Web-Centric Design Patterns
  2. EJB Centric Design Patterns

Difference Between Web-Centric and EJB-Centric Design Patterns in Java EE

In the multifaceted domain of Java EE, design patterns play a pivotal role in fostering robust and scalable application architecture. Web-centric and EJB-centric (Enterprise JavaBeans) design patterns emerge as two distinctive paradigms within this framework, each serving unique sets of requirements and concerns. This comprehensive discourse delineates the fundamental disparities between Web-Centric and EJB-Centric design patterns, elaborating on their architecture, use cases, and practical implications.

1. Web-Centric Design Patterns

Architecture

Web-Centric design patterns predominantly focus on the presentation and interaction layer of an application. These patterns deal with the user interface, navigation, and the interaction between the client and server.

Characteristics

  1. UI-Oriented: Prioritize user interface and user experience aspects.
  2. Client-Server Interaction: Focus on efficient client-server communication and data exchange.
  3. Front-End Technology Integration: Often integrated with various front-end technologies for dynamic and responsive user interfaces.
Examples
  1. Model-View-Controller (MVC): Separates application logic into three interconnected components, enhancing modularity and scalability.
  2. Front Controller: Centralizes request handling to ensure controlled and managed request processing.

Use Cases

Optimal for applications with intricate user interface requirements, client-side functionality, and real-time data presentation.

2. EJB-Centric Design Patterns

Architecture

EJB-Centric design patterns are centered on the business logic and data layer of an enterprise application. They facilitate seamless and efficient communication, data processing, and business rule enforcement.

Characteristics

  1. Business Logic Focused: Prioritize the encapsulation and execution of business operations.
  2. Scalability and Transaction Management: Ensure scalable and transaction-safe business processing.
  3. Integration with Middleware Services: Facilitate interaction with various enterprise services and resources.
Examples
  1. Session Facade: Provides a unified interface to a set of interfaces in a subsystem, ensuring loose coupling and layer abstraction.
  2. Data Access Object (DAO): Abstracts and encapsulates all access to the data source, promoting flexibility and maintainability.

Use Cases

Ideal for complex enterprise applications necessitating robust business logic execution, transaction management, and enterprise service integration.

Comparative Analysis

Design Focus

  1. Web-Centric: Primarily centered on user interface and experience.
  2. EJB-Centric: Emphasizes robust business logic and data handling.

Complexity and Scope

  1. Web-Centric: Manages the complexity of user interactions and front-end operations.
  2. EJB-Centric: Addresses the complexity of business operations, data processing, and enterprise service interaction.

Technological Integration

  1. Web-Centric: Leverages front-end technologies for enhanced UI/UX.
  2. EJB-Centric: Integrates with enterprise services and middleware for efficient business processing.
In essence, while Web-Centric design patterns are instrumental in shaping the interface and interactive dimensions of a Java EE application, EJB-Centric patterns are quintessential for fortifying the business logic and data layer. Discerning the nuanced differences between these patterns and employing them judiciously is paramount for architecting resilient and scalable Java EE applications, aligning with both functional and non-functional requirements.

Design Patterns for Properties

Simple properties
By default, we use design patterns to locate properties by looking for methods of the form: 
public <PropertyType> get<PropertyName>();
public void set<PropertyName>(<PropertyType> a);
If we discover a matching pair of get<PropertyName> and set<PropertyName> methods that take and return the same type, then we regard these methods as defining a read-write property whose name will be <propertyName>.
We will use the get <PropertyName> method to get the property value and the set<PropertyName> method to set the property value. The pair of methods may be located either in the same class or one may be in a base class and the other may be in a derived class. If we find only one of these methods, then we regard it as defining either a read-only or a writeonly property called <propertyName> By default we assume that properties are neither bound nor constrained. So a simple read-write property "data" might be represented by a pair of methods: 

public Wombat getData();
public void setData(Wombat w);

Boolean properties

In addition, for boolean properties, we allow a getter method to match the pattern: 
public boolean is <PropertyName>();

This is<PropertyName> method may be provided instead of a get<PropertyName> method, or it may be provided in addition to a get<PropertyName> method. In either case, if the is<PropertyName> method is present for a boolean property then we will use the is<PropertyName> method to read the property value. An example boolean property might be: 
public boolean isMarsupial();
public void setMarsupial(boolean m);


JavaBeans Naming Conventions Quiz

You are asked to create a Lion class that exposes the String name and int breed to other code as read-only attributes, provides encapsulation, and adheres to the standard JavaBeans naming conventions.
Which approach implements these requirements?
  1. Provide public name() and public breed() methods in the Lion class, and mark the name and breed instance variables private.
  2. Provide private getName() and private getBreed() methods in the Lion class, and mark the name and breed instance variables private.
  3. Provide public getName() and public getBreed() methods in the Lion class, and mark the name and breed instance variables private.
  4. Provide private name() and private breed() methods in the Lion class, and mark the name and breed instance variables public.
  5. Provide public getName()/setName() and public getBreed()/setBreed() methods in the Lion class, and mark the name and breed instance variables private.

Answer: C
Explanation:
Option C is correct because Encapsulation is the technique of making the fields in a class private and providing access to the fields via public methods. If a field is declared private, it cannot be accessed by anyone outside the class, thereby hiding the fields within the class. For this reason, encapsulation is also referred to as data hiding. Besides, here we do not wish to provide write access to the outside code. Hence only public getName() and public getBreed() methods are made. Option A and option D is incorrect because name() and breed() are not proper setter/getter method.
Option B is incorrect because private getName() and private getBreed() methods will not even provide the read only access to outside code. Option E is incorrect because public setName() and public setBreed() methods will modify and allow write access to the outside code.

In the next lesson, you define and use property design patterns