The following are some questions that you might encounter when you face an Interview for a position of a Senior Java/J2EE Developer. Design Patterns are very exciting and useful and most managers expect their developers to have a sound understanding of the most important patterns.
Also, as part of my series of chapters on the SCWCD Certification Series, there were a few articles posted on Design Patterns. You can use them to revise/understand these patterns better.
They are:
Introduction to Design Patterns
Elements of a Design Pattern
Value Object Pattern
DAO Pattern
Business Delegate Pattern
MVC Pattern
Front Controller Pattern
Questions:
What are design patterns?
A pattern is a proven (and recurring) solution to a problem in a context. Each pattern describes a problem which occurs time and again in our environment, and describes its solution to this problem in such a way that we can use this solution any number of times. In simple words, there are a lot of common problems which a lot of developers have faced over time. These common problems ideally should have a common solution too. It is this solution when documented and used over and over becomes a design pattern.
Can we always apply the same solution to different problems at hand?
No. Design patterns would study the different problems at hand. To these problems then it would suggest different design patterns to be used. However, the type of code to be written in that design pattern is solely the discretion of the Project Manager who is handling that project.
What should be the level of detail/abstraction which should be provided by a design pattern?
Design patterns should present a higher abstraction level though it might include details of the solution. However, these details are lower abstractions and are called strategies. There may be more than one way to apply these strategies in implementing the patterns. The details of implementation are usually upto the developer who is coding at the ground level.
What are the most common problems which one faces during the application design phase that are solved by design patterns?
Some are:
1. Identifying components, internal structures of the components, and relationships between components.
2. Determining component granularity and appropriate interactions
3. Defining component interfaces.
How does one decide which Design pattern to use in our application?
We need to follow these steps:
1. We need to understand the problem at hand. Break it down to finer grained problems. Each design pattern is meant to solve certain kinds of problems. This would narrow down our search for design patterns.
2. Read the problem statement again along with the solution which the design pattern will provide. This may instigate to change a few patterns that we are to use.
3. Now figure out the interrelations between different patterns. Also decide what all patterns will remain stable in the application and what all need to change (with respect to Change Requests received from the clients).
What is Refactoring?
Learning different design patterns is not sufficient to becoming a good designer. We have to understand these patterns and use them where they have more benefits. Using too many patterns (more than required) would be over-engineering and using less design patterns than required would be under-engineering. In both these scenarios we use refactoring. Refactoring is a change made to the internal structure of the software to make it easier to understand and cheaper to modify, without changing its observable behaviour.
What are Antipatterns?
Though the use of patterns fulfils our objectives in the applications; there are also several instances where several applications did not fulfill their goals. The architects of these applications too need to document these wrong decisions. This helps others by preventing them from repeating these mistakes in their applications. Such documented mistakes are called antipatterns.
As we do development in tiers, how do we divide patterns in tiers?
The Sun Java Center has classified the patterns in three tiers. These are:
Presentation tier patterns for web-component tier,
Business tier patterns for business logic (EJB) tier, and
Integration tier patterns for connection to the databases.
What are the Presentation Tier Patterns?
The presentation tier patterns are:
Intercepting filter, Front Controller, View Helper, Composite View, Service-to-Worker, and Dispatcher View.
What are the Business Tier Patterns?
The business tier patterns are:
Business delegate, Value Object, Session Façade, Composite Entity, Value Object Assembler, Value List Handler, and Service Locator.
What are the Integration Tier Patterns?
Integration tier patterns are:
Data Access Object (DAO) and Service Activator
What is Intercepting Filter pattern?
Provides a solution for pre-processing and post-processing a request. It allows us to declaratively apply filters for intercepting requests and responses. For ex. Servlet filters.
What is Front Controller pattern?
It manages and handles requests through a centralized code. This could either be through a servlet or a JSP (through a Java Bean). This Controller takes over the common processing which happens on the presentation tier. The front controller manages content retrieval, security, view management and retrieval.
What is View Helper pattern?
There generally are two parts to any application – the presentation and the business logics. The “View” is responsible for the output-view formatting whereas “Helper” component is responsible for the business logic. Helper components do content retrieval, validation and adaptation. Helper components generally use Business delegate pattern to access business classes.
What is Composite View pattern?
This pattern is used for creating aggregate presentations (views) from atomic sub-components. This architecture enables says piecing together of elementary view components which makes the presentation flexible by allowing personalization and customization.
What is Service to Worker pattern?
This is used in larger applications wherein one class is used to process the requests while the other is used to process the view part. This differentiation is done for maintainability.
What is Dispatcher View pattern?
This is similar to Service to Worker pattern except that it is used for smaller applications. In this one class is used for both request and view processing.
What is Business Delegate pattern?
This pattern is used to reduce the coupling between the presentation and business-logic tier. It provides a proxy to the façade from where one could call the business classes or DAO class. This pattern can be used with Service Locator pattern for improving performance.
What is Value Object pattern?
Value Object is a serializable object which would contain lot of atomic values. These are normal java classes which may have different constructors (to fill in the value of different data) and getter methods to get access to these data. VOs are used as a course grained call which gets lots of data in one go (this reduces remote overhead). The VO is made serializable for it to be transferred between different tiers within a single remote method invocation
What is Session Façade pattern?
This pattern hides the complexity of business components and centralizes the workflow. It provides course-grained interfaces to the clients which reduces the remote method overhead. This pattern fits well with declarative transactions and security management.
What is Value Object Assembler pattern?
This pattern allows for composing a Value Object from different sources which could be EJBs, DAOs or Java objects.
What is Value List Handler pattern?
This pattern provides a sound solution for query execution and results processing.
What is Service Locator pattern?
It provides a solution for looking-up, creating and locating services and encapsulating their complexity. It provides a single point of control and it also improves performance.
What is Data Access Object pattern?
It provides a flexible and transparent access to the data, abstracts the data sources and hides the complexity of Data persistence layer. This pattern provides for loose coupling between business and data persistence layer.
What is EJB Command pattern?
Session Façade and EJB Command patterns are competitor patterns. It wraps business logic in command beans, decouples the client and business logic tier, and reduces the number of remote method invocations.
What is Version Number pattern?
This pattern is used for transaction and persistence and provides a solution for maintaining consistency and protects against concurrency. Every time a data is fetched from the database, it comes out with a version number which is saved in the database. Once any update is requested on the same row of the database, this version is checked. If the version is same, the update is allowed else not.
What all patterns are used to improve performance and scalability of the application?
Value Object, Session Façade, Business Delegate and Service Locator.
What design patterns could be used to manage security?
Single Access Point, Check point and Role patterns
If you have any more questions on Design Patterns that you have faced during your interviews and wish to add them to this collection - pls drop a note to [email protected] and I shall be glad to add them to this list.
Topics Covered in the Blog - Synopsis
Showing posts with label design patterns. Show all posts
Showing posts with label design patterns. Show all posts
Tuesday, May 3, 2011
Friday, April 29, 2011
Chapter 57: Front Controller Pattern
This chapter is going to deal with the last pattern on the SCWCD exam – The Front Controller Pattern.
What is Front Controller Pattern?
The Front Controller pattern presents one entry point to a Web site or service. It provides a centralized entry point that controls and manages Web request handling. It eliminates the dependency of the user on a direct resource. Suppose you wanted to get the latest version of the servlet specification. You would be better off going to a central page that presents options that change over time than bookmarking the servlet specification directly as your bookmark might get outdated if a new version of the specification is hosted in a different page.
Is
This pattern is a presentation controller that allows the resources to change without breaking all the bookmarks to a given resource. Many sites use this. For example, Microsoft often changes the content in its MSDN library. However, there is front end for it that rarely changes. This way, you can bookmark that front-end URL and not worry about what they do behind it.
Is Not
This is not a pattern for a data storage viewer. It isn't a way for you to control data retrieval. Rather, it is a steady interface to the underlying Web resources that behave as the presentation tier.
Analogy
This pattern is like a travel agent. On every trip you start by stopping at the agency. You tell the agent where you want to go and she will take care of the arrangements. The actual flight, train, bus, and hotel details change between trips, but she always helps you get there.
Problem
When the user accesses resources directly without going through a centralized mechanism, the resource may have moved. Also, each view is on its own and required to provide its own system services. Lastly, each view has to provide navigation, but this is a problem as it doesn't know about the context or the global site.
Responsibility
This controller must delegate the request to the proper resource and view.
Aim
This pattern isolates the actual resources from direct access by the user.
Primary Activity
This pattern matches the correct resource to the request.
Context
Simplified Web sites expose all its resources directly. As a site grows, there comes a time when it is better to decouple the navigation from the resources. There needs to be a controller that manages the requests and decides which resource best satisfies the request.
Benefits
• It is better to have a central controller allocate shared resources rather than have individual resources fend for themselves independently.
• The location of resources may change.
• This pattern adds only a little more work to building a Web site at first.
• Multiple resources share common needs such as security (that is, authentication and authorization).
Usage
Large Web sites especially benefit from a front controller.
Consequences
• Caching is always good between parts that exchange a lot of data.
• This pattern changes the interface with the intent of making the API more stable from the presentation tier perspective.
• This pattern will now handle any exceptions, whether from the business tier itself or from the plumbing between it and the requester.
• This pattern isolates the presentation and the business tiers by adding a mediator between the two, making it easier to manage changes on either side.
Uses
• Servlet Front Strategy— This pattern is implemented as a servlet, which manages the aspects of request handling that are related to business processing and control flow. Because this strategy is not specifically related to display formatting, it is a bad idea to implement this component as a JSP page.
• Command and Controller Strategy— This strategy provides a generic interface to the helper components. The controller delegates responsibility to the helper components, which minimizes the coupling among these components.
• Logical Resource Mapping Strategy— In this case users request logical names rather than physical locations. This way the physical location can be mapped to the logical names dynamically, say, in a database or XML document.
Other Related Patterns
• View Helper Pattern— The Front Controller is combined with the View Helper pattern to provide containers for factoring business logic out of the view and to provide a central point of control and dispatch. Logic is factored forward into the front controller and back into the Helpers.
• Service to Worker— The Service to Worker pattern is the result of combining the View Helper Pattern with a Dispatcher, in coordination with the Front Controller pattern.
• Dispatcher View— The Dispatcher View pattern is the result of combining the View Helper Pattern with a Dispatcher, in coordination with the Front Controller pattern.
Previous Chapter: Chapter 56 - MVC Pattern
Next chapter: Chapter 58 - Other Design Patterns
What is Front Controller Pattern?
The Front Controller pattern presents one entry point to a Web site or service. It provides a centralized entry point that controls and manages Web request handling. It eliminates the dependency of the user on a direct resource. Suppose you wanted to get the latest version of the servlet specification. You would be better off going to a central page that presents options that change over time than bookmarking the servlet specification directly as your bookmark might get outdated if a new version of the specification is hosted in a different page.
Is
This pattern is a presentation controller that allows the resources to change without breaking all the bookmarks to a given resource. Many sites use this. For example, Microsoft often changes the content in its MSDN library. However, there is front end for it that rarely changes. This way, you can bookmark that front-end URL and not worry about what they do behind it.
Is Not
This is not a pattern for a data storage viewer. It isn't a way for you to control data retrieval. Rather, it is a steady interface to the underlying Web resources that behave as the presentation tier.
Analogy
This pattern is like a travel agent. On every trip you start by stopping at the agency. You tell the agent where you want to go and she will take care of the arrangements. The actual flight, train, bus, and hotel details change between trips, but she always helps you get there.
Problem
When the user accesses resources directly without going through a centralized mechanism, the resource may have moved. Also, each view is on its own and required to provide its own system services. Lastly, each view has to provide navigation, but this is a problem as it doesn't know about the context or the global site.
Responsibility
This controller must delegate the request to the proper resource and view.
Aim
This pattern isolates the actual resources from direct access by the user.
Primary Activity
This pattern matches the correct resource to the request.
Context
Simplified Web sites expose all its resources directly. As a site grows, there comes a time when it is better to decouple the navigation from the resources. There needs to be a controller that manages the requests and decides which resource best satisfies the request.
Benefits
• It is better to have a central controller allocate shared resources rather than have individual resources fend for themselves independently.
• The location of resources may change.
• This pattern adds only a little more work to building a Web site at first.
• Multiple resources share common needs such as security (that is, authentication and authorization).
Usage
Large Web sites especially benefit from a front controller.
Consequences
• Caching is always good between parts that exchange a lot of data.
• This pattern changes the interface with the intent of making the API more stable from the presentation tier perspective.
• This pattern will now handle any exceptions, whether from the business tier itself or from the plumbing between it and the requester.
• This pattern isolates the presentation and the business tiers by adding a mediator between the two, making it easier to manage changes on either side.
Uses
• Servlet Front Strategy— This pattern is implemented as a servlet, which manages the aspects of request handling that are related to business processing and control flow. Because this strategy is not specifically related to display formatting, it is a bad idea to implement this component as a JSP page.
• Command and Controller Strategy— This strategy provides a generic interface to the helper components. The controller delegates responsibility to the helper components, which minimizes the coupling among these components.
• Logical Resource Mapping Strategy— In this case users request logical names rather than physical locations. This way the physical location can be mapped to the logical names dynamically, say, in a database or XML document.
Other Related Patterns
• View Helper Pattern— The Front Controller is combined with the View Helper pattern to provide containers for factoring business logic out of the view and to provide a central point of control and dispatch. Logic is factored forward into the front controller and back into the Helpers.
• Service to Worker— The Service to Worker pattern is the result of combining the View Helper Pattern with a Dispatcher, in coordination with the Front Controller pattern.
• Dispatcher View— The Dispatcher View pattern is the result of combining the View Helper Pattern with a Dispatcher, in coordination with the Front Controller pattern.
Previous Chapter: Chapter 56 - MVC Pattern
Next chapter: Chapter 58 - Other Design Patterns
Chapter 55: Business Delegate Pattern
In this chapter, we are going to take a detailed look at the Business Delegate Pattern.
What is Business Delegate Pattern?
The Business Delegate pattern reduces the dependency between tiers. It is an attempt to make tiers interchangeable so one can access or utilize the services of any other.
Is
This pattern is a proxy that hides the complexity of remote service lookup and error recovery. It makes it easier to communicate requests and results from one layer to another.
Is Not
This is not a pattern for a layer itself. It isn't a way for you to create a business logic component or structure. Rather, it is an interface to a tier so that you can change the underlying components and not disturb the presentation tier.
Analogy
This pattern is like an ambassador. Like all good ambassadors, it can pass on the message from the host country to any other.
Problem
Whenever there is a dependency on a remote service, the probability of change between the caller and the called increases. How can you reduce the chances of the layer depending on the remote service breaking should the remote service change? This pattern helps protect the local layer from changes made to the remote service.
Ex: Lets say, the presentation tier interacts directly with a remote business logic layer. What if the business services change and the old API becomes invalid? If this happens the presentation tier will break.
Responsibility
This delegate is the proxy between the local layer and the remote service layer. It is responsible for reliably allowing the front layer to access the remote service.
Aim
This pattern isolates the presentation layer from changes in the business tier API.
Primary Activity
This pattern matches presentation component calls to the correct business tier methods.
Context
The current approach to multi-tier systems is to couple the presentation tier directly to the entire business service API; sometimes this coupling is made across a network.
Benefits
• Presentation-tier clients (including devices) need access to business services.
• The business tier API may change.
• The industry trend for large systems is to minimize coupling between presentation-tier clients and the business service API. This isolates the two so that a change in either side can be managed by the middle layer.
• There is a need for a cache between tiers.
• This pattern adds more work to building a system.
Usage
Large systems change components often. There is often a change in the business tier that breaks the access portion of clients.
Consequences
• Caching is always good between parts that exchange a lot of data.
• This pattern changes the interface with the intent of making the API more stable from the presentation tier perspective.
• This pattern will now handle any exceptions, whether from the business tier itself or from the plumbing between it and the requester.
• This pattern isolates the presentation and the business tiers from each other by adding a director between the two, making it is easier to manage changes on either side.
Uses
• B2B systems usually employ an XML exchange for communicating between disparate systems.
• Proxy services represent this pattern.
• Look up services usually represent this pattern, too.
• This pattern can be thought of as an underlying design feature of Java's overloading capability such as the System.out.print() group of methods. Using the same method name, you can print almost anything to the console, because the printing service handles the different data types. This pattern is bigger than that, but overloading illustrates the idea.
Other Related Patterns
• Service Locator Pattern— This pattern provides a common API for any business service lookup and access code.
• Proxy Pattern— Provides a stand-in for objects in the business tier.
• Adapter Pattern— You can use the Adapter pattern to provide coupling for disparate systems.
Previous Chapter: Chapter 54 - DAO Pattern
Next Chapter: Chapter 56 - MVC Pattern
What is Business Delegate Pattern?
The Business Delegate pattern reduces the dependency between tiers. It is an attempt to make tiers interchangeable so one can access or utilize the services of any other.
Is
This pattern is a proxy that hides the complexity of remote service lookup and error recovery. It makes it easier to communicate requests and results from one layer to another.
Is Not
This is not a pattern for a layer itself. It isn't a way for you to create a business logic component or structure. Rather, it is an interface to a tier so that you can change the underlying components and not disturb the presentation tier.
Analogy
This pattern is like an ambassador. Like all good ambassadors, it can pass on the message from the host country to any other.
Problem
Whenever there is a dependency on a remote service, the probability of change between the caller and the called increases. How can you reduce the chances of the layer depending on the remote service breaking should the remote service change? This pattern helps protect the local layer from changes made to the remote service.
Ex: Lets say, the presentation tier interacts directly with a remote business logic layer. What if the business services change and the old API becomes invalid? If this happens the presentation tier will break.
Responsibility
This delegate is the proxy between the local layer and the remote service layer. It is responsible for reliably allowing the front layer to access the remote service.
Aim
This pattern isolates the presentation layer from changes in the business tier API.
Primary Activity
This pattern matches presentation component calls to the correct business tier methods.
Context
The current approach to multi-tier systems is to couple the presentation tier directly to the entire business service API; sometimes this coupling is made across a network.
Benefits
• Presentation-tier clients (including devices) need access to business services.
• The business tier API may change.
• The industry trend for large systems is to minimize coupling between presentation-tier clients and the business service API. This isolates the two so that a change in either side can be managed by the middle layer.
• There is a need for a cache between tiers.
• This pattern adds more work to building a system.
Usage
Large systems change components often. There is often a change in the business tier that breaks the access portion of clients.
Consequences
• Caching is always good between parts that exchange a lot of data.
• This pattern changes the interface with the intent of making the API more stable from the presentation tier perspective.
• This pattern will now handle any exceptions, whether from the business tier itself or from the plumbing between it and the requester.
• This pattern isolates the presentation and the business tiers from each other by adding a director between the two, making it is easier to manage changes on either side.
Uses
• B2B systems usually employ an XML exchange for communicating between disparate systems.
• Proxy services represent this pattern.
• Look up services usually represent this pattern, too.
• This pattern can be thought of as an underlying design feature of Java's overloading capability such as the System.out.print() group of methods. Using the same method name, you can print almost anything to the console, because the printing service handles the different data types. This pattern is bigger than that, but overloading illustrates the idea.
Other Related Patterns
• Service Locator Pattern— This pattern provides a common API for any business service lookup and access code.
• Proxy Pattern— Provides a stand-in for objects in the business tier.
• Adapter Pattern— You can use the Adapter pattern to provide coupling for disparate systems.
Previous Chapter: Chapter 54 - DAO Pattern
Next Chapter: Chapter 56 - MVC Pattern
Chapter 54: Data Access Object Pattern
In this chapter, we are going to take a detailed look at the DAO or Data Access Object Design Pattern.
What is Data Access Object Pattern?
The DAO pattern provides the connection between the business logic tier and the resource (usually a database) tier. The Data Access Object represents a general interface to the resources layer: It handles all calls to it. JDBC is the most commonly used example of this. Almost all J2EE Applications that access the database have a direct or indirect implementation of the DAO Pattern.
Is
This pattern is an object that encapsulates a set of behaviors for accessing databases, files, and other resources. This way you have only one API to deal with rather than a different one for every type of resource.
Is Not
This is not a pattern for a resource itself. Frankly speaking, this isn't a way to build a database or file manager.
Analogy
This is like using an ATM machine. The same interface will fetch the information requested from the back end, even though the bank changed database products the previous week.
Problem
Applications often need to use persistent data. This data persists in many forms such as files, relational databases, XML storage, and other types of repositories. All these stores have different APIs. Interfacing with so many APIs presents a problem when designing clients.
Responsibility
This pattern provides a uniform API to any persistent data storage.
Aim
This pattern attempts to consolidate the accessing of data from a complex source or set of sources to one object. This will reduce the network overhead by minimizing the number of network calls to get data, but the reduction of network traffic is not the main intention of this pattern.
Primary Activity
Getting and setting data from and to a permanent data source.
Context
Access methods to data vary between types of storage and vendor.
Benefits
Various parts of an application require access to persistent stores like databases and files. The APIs are inconsistent between types of stores and even between different vendors of the same type of storage. There needs to be a layer that has a uniform API to access these disparate data sources.
Usage
Any application that requires access to several data source types or even an application that accesses only one, but may switch in the future. The SQL is encapsulated in the method. That way if the SQL or datasource change, the layers above won't because the API remains constant.
Consequences
• Clients and components can now access data with the same API, which makes the variety of sources transparent and reduces complexity.
• This makes changing data sources easy and reduces errors.
Uses
At one level, JDBC uses an Abstract Factory technique to provide one API to many databases and types of files; the very essence of this pattern. However, the emphasis Sun places on this pattern is that of encapsulating the SQL so the implementation of actually querying the database is hidden from the next layer.
Other Related Patterns
Abstract Factory: Sun uses this factory for data access object strategy. They base it on the abstract factory method.
Previous Chapter: Chapter 53 - Value Object Pattern
Next Chapter: Chapter 55 - Business Delegate Pattern
What is Data Access Object Pattern?
The DAO pattern provides the connection between the business logic tier and the resource (usually a database) tier. The Data Access Object represents a general interface to the resources layer: It handles all calls to it. JDBC is the most commonly used example of this. Almost all J2EE Applications that access the database have a direct or indirect implementation of the DAO Pattern.
Is
This pattern is an object that encapsulates a set of behaviors for accessing databases, files, and other resources. This way you have only one API to deal with rather than a different one for every type of resource.
Is Not
This is not a pattern for a resource itself. Frankly speaking, this isn't a way to build a database or file manager.
Analogy
This is like using an ATM machine. The same interface will fetch the information requested from the back end, even though the bank changed database products the previous week.
Problem
Applications often need to use persistent data. This data persists in many forms such as files, relational databases, XML storage, and other types of repositories. All these stores have different APIs. Interfacing with so many APIs presents a problem when designing clients.
Responsibility
This pattern provides a uniform API to any persistent data storage.
Aim
This pattern attempts to consolidate the accessing of data from a complex source or set of sources to one object. This will reduce the network overhead by minimizing the number of network calls to get data, but the reduction of network traffic is not the main intention of this pattern.
Primary Activity
Getting and setting data from and to a permanent data source.
Context
Access methods to data vary between types of storage and vendor.
Benefits
Various parts of an application require access to persistent stores like databases and files. The APIs are inconsistent between types of stores and even between different vendors of the same type of storage. There needs to be a layer that has a uniform API to access these disparate data sources.
Usage
Any application that requires access to several data source types or even an application that accesses only one, but may switch in the future. The SQL is encapsulated in the method. That way if the SQL or datasource change, the layers above won't because the API remains constant.
Consequences
• Clients and components can now access data with the same API, which makes the variety of sources transparent and reduces complexity.
• This makes changing data sources easy and reduces errors.
Uses
At one level, JDBC uses an Abstract Factory technique to provide one API to many databases and types of files; the very essence of this pattern. However, the emphasis Sun places on this pattern is that of encapsulating the SQL so the implementation of actually querying the database is hidden from the next layer.
Other Related Patterns
Abstract Factory: Sun uses this factory for data access object strategy. They base it on the abstract factory method.
Previous Chapter: Chapter 53 - Value Object Pattern
Next Chapter: Chapter 55 - Business Delegate Pattern
Chapter 53: Value Object Pattern
Value Object
In this chapter, we are going to take a detailed look at the Value Object Pattern.
What is Value Object Pattern?
The Value Object pattern provides the best way to exchange data across tiers or system boundaries, especially when there is network communication involved. This is a pattern that solves performance issues around network latency. Do I have to tell you that, this is a very useful pattern?
Is
This pattern is an object that encapsulates a set of values that is moved across the boundary so that attempts to get the values of those attributes are local calls.
Is Not
This pattern is not a concrete object. You wouldn't use it to create an object. You could use it to hold values of that object.
Analogy
This would be like placing several letters in a box to be mailed once a week instead of mailing the letters separately and multiple times over the week. The box is mailed once. When the box arrives, the mail carrier can just reach in the box for the next letter; she doesn't have to contact the origin, which would take a long time.
Problem
In J2EE, server-resident business applications often use session beans and entity beans. The session beans are responsible for functionality that is involved in one-to-one transactions with the client. In contrast, the entity beans are used to handle persistent data. So, the client will make many calls to the session bean to get data. That represents a lot of traffic, to and from a remote location because the bean may be at a server at a remote location. Likewise, the session bean may make many calls to the entity bean getting and setting attributes. The Value Object pattern encapsulates the data fields of an entity bean; VO has nothing to do with session beans (except that it is usually a session method call that returns a VO, instead of a remote entity reference).
This activity is inefficient. We need a way to eliminate all these potential network calls reducing overhead and providing a more direct access approach.
Responsibility
This pattern provides a mechanism to exchange many remote calls to local, direct calls.
Aim
This pattern attempts to reduce the network overhead by minimizing the number of network calls to get data from the business tier.
Primary Activity
Used to collect remote data into an object that is sent to the client, so now the client makes local calls to get values rather than remote ones.
Context
Multi-tier applications that need to exchange sets of data between the client and server often.
Benefits
• J2EE applications often use enterprise beans. All calls to these beans are performed via remote interfaces to the bean due to Java's architecture. This introduces overhead.
• The frequency of reads is greater than updates because the client gets the data from the business tier for presentation.
• The client usually needs a set of data, not just one attribute.
• Client calls to enterprise beans accessed over the network affects WebApp performance because of the sum of network latency of multiple attribute access to the entity bean.
• Regardless of Java's bean architecture, it would be better to collect attributes into one object and get them from it rather than make invoking remote methods for the same information.
Usage
This pattern is useful when you need a collection of data from a remote source or, more likely, when a client has to make several calls for data from entity beans.
Consequences
• Simplifies Entity Bean and Remote Interface— Sun suggests using getData() and setData() methods on certain entity beans as a way to get and set a value object containing the set of attribute values. Calling the getData() method once replaces multiple calls to get methods. Likewise, the setData() method replaces many set calls.
• Using this pattern transfers a set of values in one method call improving overall performance, especially over the network. It represents coarse versus fine-grained interfaces.
• The client can update, delete, and read the values that are now local at will. When done, it can update the data source in one call. However, there may be a problem with synchronization as the other clients won't know about the changes until the update call. In the case of updates, there can be two conflicting update calls by two clients, so this must be synchronized somehow.
Uses
The ResultSet of JDBC is a collection of data returned from the data source resulting from a query. The data is now local in the ResultSet object so all calls to it are local rather than many calls to the data source directly.
Other Related Patterns
• Aggregate Entity that uses Value Object to get data across tiers.
• Session Façade, which is the business interface for clients of J2EE applications. This pattern often uses value objects as an exchange mechanism with participating entity beans.
• Value List Handler is another pattern that provides lists of value objects constructed dynamically by accessing the persistent store at request time.
• Value Object Assembler builds composite value objects from different data sources. The data sources are usually session beans or entity beans that may be requested to provide their data as value objects.
Previous Chapter: Chapter 52 - Design Pattern Elements
Next Chapter: Chapter 54 - Data Access Object Pattern
In this chapter, we are going to take a detailed look at the Value Object Pattern.
What is Value Object Pattern?
The Value Object pattern provides the best way to exchange data across tiers or system boundaries, especially when there is network communication involved. This is a pattern that solves performance issues around network latency. Do I have to tell you that, this is a very useful pattern?
Is
This pattern is an object that encapsulates a set of values that is moved across the boundary so that attempts to get the values of those attributes are local calls.
Is Not
This pattern is not a concrete object. You wouldn't use it to create an object. You could use it to hold values of that object.
Analogy
This would be like placing several letters in a box to be mailed once a week instead of mailing the letters separately and multiple times over the week. The box is mailed once. When the box arrives, the mail carrier can just reach in the box for the next letter; she doesn't have to contact the origin, which would take a long time.
Problem
In J2EE, server-resident business applications often use session beans and entity beans. The session beans are responsible for functionality that is involved in one-to-one transactions with the client. In contrast, the entity beans are used to handle persistent data. So, the client will make many calls to the session bean to get data. That represents a lot of traffic, to and from a remote location because the bean may be at a server at a remote location. Likewise, the session bean may make many calls to the entity bean getting and setting attributes. The Value Object pattern encapsulates the data fields of an entity bean; VO has nothing to do with session beans (except that it is usually a session method call that returns a VO, instead of a remote entity reference).
This activity is inefficient. We need a way to eliminate all these potential network calls reducing overhead and providing a more direct access approach.
Responsibility
This pattern provides a mechanism to exchange many remote calls to local, direct calls.
Aim
This pattern attempts to reduce the network overhead by minimizing the number of network calls to get data from the business tier.
Primary Activity
Used to collect remote data into an object that is sent to the client, so now the client makes local calls to get values rather than remote ones.
Context
Multi-tier applications that need to exchange sets of data between the client and server often.
Benefits
• J2EE applications often use enterprise beans. All calls to these beans are performed via remote interfaces to the bean due to Java's architecture. This introduces overhead.
• The frequency of reads is greater than updates because the client gets the data from the business tier for presentation.
• The client usually needs a set of data, not just one attribute.
• Client calls to enterprise beans accessed over the network affects WebApp performance because of the sum of network latency of multiple attribute access to the entity bean.
• Regardless of Java's bean architecture, it would be better to collect attributes into one object and get them from it rather than make invoking remote methods for the same information.
Usage
This pattern is useful when you need a collection of data from a remote source or, more likely, when a client has to make several calls for data from entity beans.
Consequences
• Simplifies Entity Bean and Remote Interface— Sun suggests using getData() and setData() methods on certain entity beans as a way to get and set a value object containing the set of attribute values. Calling the getData() method once replaces multiple calls to get methods. Likewise, the setData() method replaces many set calls.
• Using this pattern transfers a set of values in one method call improving overall performance, especially over the network. It represents coarse versus fine-grained interfaces.
• The client can update, delete, and read the values that are now local at will. When done, it can update the data source in one call. However, there may be a problem with synchronization as the other clients won't know about the changes until the update call. In the case of updates, there can be two conflicting update calls by two clients, so this must be synchronized somehow.
Uses
The ResultSet of JDBC is a collection of data returned from the data source resulting from a query. The data is now local in the ResultSet object so all calls to it are local rather than many calls to the data source directly.
Other Related Patterns
• Aggregate Entity that uses Value Object to get data across tiers.
• Session Façade, which is the business interface for clients of J2EE applications. This pattern often uses value objects as an exchange mechanism with participating entity beans.
• Value List Handler is another pattern that provides lists of value objects constructed dynamically by accessing the persistent store at request time.
• Value Object Assembler builds composite value objects from different data sources. The data sources are usually session beans or entity beans that may be requested to provide their data as value objects.
Previous Chapter: Chapter 52 - Design Pattern Elements
Next Chapter: Chapter 54 - Data Access Object Pattern
Chapter 52: Design Pattern Elements
Before we dig into the specifics of the Design Patterns that are part of the SCWCD Exam, we need to know one important thing. “The Elements of a Design Pattern”. This is what you are going to learn in this chapter.
So, lets get started!!!
Elements of a Design Pattern:
There are many ways to define a pattern, but the classical way is to describe its elements, or the aspects of a pattern.
The 3 main elements in any Design pattern are:
• Context
• Problem and
• Solution
The following are their definitions:
• Context is the recurring situation in which a problem to be solved is found.
• Problems are the so-called forces, such as marketing and technological forces, that occur in this context.
• Solution is the defined design that reorganizes or manipulates, some say resolves, the problem forces into a desired outcome within that context.
The design pattern is not only these three, but the relationship between the three and the formal language that describes the whole business.
For the sake of easy understanding & explanation, the following are the elements that would be used while explaining each of the design patterns that are covered in this series:
• Is — A direct explanation of what the pattern is.
• Is Not — An attempt at contrasting the concept because it is often helpful to understand what something is by looking at what it isn't.
• Analogy — This provides a comparison based on general aspects. Analogies, hopefully, give you a way to connect what you already know to these patterns which may be new to you.
• Problem — A statement of the problem that describes the patterns reason/purpose and intent.
• Responsibility — This describes what the pattern is accountable for; the primary things it accomplishes.
• Aim — These are the goals and objectives the pattern should reach within the given context.
• Primary Activity — What the main activities done by the pattern are.
• Context — The conditions and environment in which the problem and its solution recur. In other words, where should you consider and apply this pattern?
• Benefits — Why use a particular pattern, its benefits or advantages.
• Usage — Which kinds of situations are good candidates for this pattern.
• Consequences — This describes the result of using the pattern, the final state of the system. There are good and bad consequences of applying the pattern. It may solve one problem, but give rise to a new one.
• Uses — This tells you one or more examples of how this pattern is being used.
• Other Related Patterns — This names other patterns that are related by context, solution, or consequences. The related pattern may solve the same problem in another way or share the same context, but resolve different forces.
Patterns on the Exam
From the SCWCD Exam perspective, you need to worry about only 5 patters and we will be covering all of them, one by one. As a precursor, the 5 patters are:
1. Value Object
2. Data Access Object
3. Business Delegate
4. Front Controller &
5. Model View Controller (MVC)
Previous Chapter: Chapter 51 - Introduction to Design Patterns
Next chapter: Chapter 53 - Value Object Pattern
So, lets get started!!!
Elements of a Design Pattern:
There are many ways to define a pattern, but the classical way is to describe its elements, or the aspects of a pattern.
The 3 main elements in any Design pattern are:
• Context
• Problem and
• Solution
The following are their definitions:
• Context is the recurring situation in which a problem to be solved is found.
• Problems are the so-called forces, such as marketing and technological forces, that occur in this context.
• Solution is the defined design that reorganizes or manipulates, some say resolves, the problem forces into a desired outcome within that context.
The design pattern is not only these three, but the relationship between the three and the formal language that describes the whole business.
For the sake of easy understanding & explanation, the following are the elements that would be used while explaining each of the design patterns that are covered in this series:
• Is — A direct explanation of what the pattern is.
• Is Not — An attempt at contrasting the concept because it is often helpful to understand what something is by looking at what it isn't.
• Analogy — This provides a comparison based on general aspects. Analogies, hopefully, give you a way to connect what you already know to these patterns which may be new to you.
• Problem — A statement of the problem that describes the patterns reason/purpose and intent.
• Responsibility — This describes what the pattern is accountable for; the primary things it accomplishes.
• Aim — These are the goals and objectives the pattern should reach within the given context.
• Primary Activity — What the main activities done by the pattern are.
• Context — The conditions and environment in which the problem and its solution recur. In other words, where should you consider and apply this pattern?
• Benefits — Why use a particular pattern, its benefits or advantages.
• Usage — Which kinds of situations are good candidates for this pattern.
• Consequences — This describes the result of using the pattern, the final state of the system. There are good and bad consequences of applying the pattern. It may solve one problem, but give rise to a new one.
• Uses — This tells you one or more examples of how this pattern is being used.
• Other Related Patterns — This names other patterns that are related by context, solution, or consequences. The related pattern may solve the same problem in another way or share the same context, but resolve different forces.
Patterns on the Exam
From the SCWCD Exam perspective, you need to worry about only 5 patters and we will be covering all of them, one by one. As a precursor, the 5 patters are:
1. Value Object
2. Data Access Object
3. Business Delegate
4. Front Controller &
5. Model View Controller (MVC)
Exam Trivia:
If you see any other pattern name, ignore it unless the question is one of those about which one is not a pattern.
Previous Chapter: Chapter 51 - Introduction to Design Patterns
Next chapter: Chapter 53 - Value Object Pattern
Chapter 51: Introduction to Design Patterns
Design Patterns are a very important topic from the SCWCD Exam perspective as well as from being a J2EE Programmer perspective. Any experienced J2EE programmer is expected to know about a few of the J2EE Design Patterns. These patterns are used extensively and are very useful to create enterprise class J2EE Web Applications. In this next few chapters, we are going to look in detail, some of the most commonly used Design Patters (Of Course, only the ones that are part of the SCWCD Exam)
This chapter, is going to be a short and sweet introduction to the J2EE Design Patterns.
So, lets get started!!!
A word of Caution: This chapter assumes you've read the previous chapters (well, obviously) and that you are familiar with object-oriented programming concepts, including the popular UML diagramming notation.
History of Design Patterns
The term “pattern” comes from the architect Christopher Alexander who wrote several books on Construction and Building. Although he was interested in urban planning and building architecture, his notions were clearly useful in many areas. Alexander, a building architect, was the first to “codify” patterns for architecture. Alexander didn't invent the idea of patterns nor was he the first to see them in designs. Of course, they were there before him, but his work on urban planning and building architecture isolated the idea better than anyone before him. Alexander was an architect extraordinaire. He is one of those rare people who take a step back and question why people do things the way they do. He gave the result of his inquiry the name Pattern Language and defined it at length in his seminal book by the same name.
While Alexander was thinking buildings and foundations, it became clear to many that his design patterns were abstract enough to be useful elsewhere. That is when the Gang of Four (GoF as we will refer to them henceforth), as Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides are now known, applied his patterns to software in their classic Design Patterns: Elements of Reusable Object-Oriented Software (1995, Addison-Wesley). It took a while, but the GoF have started a ground swell. There are now dozens of books, and numerous websites in the internet, about design patterns.
What is a Design Pattern?
Design patterns are often defined as “a solution to a problem in a context.” This falls short of the abstract definition that experts prefer.
Sun defines them in the following way: “A design pattern describes a proven solution to a recurring design problem, placing particular emphasis on the context and forces surrounding the problem, and the consequences and impact of the solution.”
Design Patterns are everywhere and are used (knowingly or unknowingly) by almost all J2EE Developers. Don’t worry my friend, you will be using them too and by the time you are done reading the next few chapters, you will be a Design Pattern Expert.
Previous Chapter: Self Test - Chapters 47 to 50
Next Chapter: Chapter 52 - Design Pattern Elements
This chapter, is going to be a short and sweet introduction to the J2EE Design Patterns.
So, lets get started!!!
A word of Caution: This chapter assumes you've read the previous chapters (well, obviously) and that you are familiar with object-oriented programming concepts, including the popular UML diagramming notation.
History of Design Patterns
The term “pattern” comes from the architect Christopher Alexander who wrote several books on Construction and Building. Although he was interested in urban planning and building architecture, his notions were clearly useful in many areas. Alexander, a building architect, was the first to “codify” patterns for architecture. Alexander didn't invent the idea of patterns nor was he the first to see them in designs. Of course, they were there before him, but his work on urban planning and building architecture isolated the idea better than anyone before him. Alexander was an architect extraordinaire. He is one of those rare people who take a step back and question why people do things the way they do. He gave the result of his inquiry the name Pattern Language and defined it at length in his seminal book by the same name.
While Alexander was thinking buildings and foundations, it became clear to many that his design patterns were abstract enough to be useful elsewhere. That is when the Gang of Four (GoF as we will refer to them henceforth), as Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides are now known, applied his patterns to software in their classic Design Patterns: Elements of Reusable Object-Oriented Software (1995, Addison-Wesley). It took a while, but the GoF have started a ground swell. There are now dozens of books, and numerous websites in the internet, about design patterns.
What is a Design Pattern?
Design patterns are often defined as “a solution to a problem in a context.” This falls short of the abstract definition that experts prefer.
Sun defines them in the following way: “A design pattern describes a proven solution to a recurring design problem, placing particular emphasis on the context and forces surrounding the problem, and the consequences and impact of the solution.”
Design Patterns are everywhere and are used (knowingly or unknowingly) by almost all J2EE Developers. Don’t worry my friend, you will be using them too and by the time you are done reading the next few chapters, you will be a Design Pattern Expert.
Previous Chapter: Self Test - Chapters 47 to 50
Next Chapter: Chapter 52 - Design Pattern Elements
Subscribe to:
Posts (Atom)
ShareThis
Followers