Db2
Java
Wednesday, November 26, 2008
Friday, November 21, 2008
Design Patterns
---------Synopsis of Design patterns---------
Java Design Patterns
Design patterns address the recurring design problems that arise in particular
design situations and propose solutions to them. Design patterns are thus
successful solutions to known problems. There are various ways to
implement design patterns.
These implementation details are called strategies.
The GoF (Gang of four ) pattern categories and scopes of design patterns.
****Creational Pattern****
Creational class-Creational class patterns use inheritance as a mechanism to achieve varying class instantiation.
example Factory Method.
Creational object-Creational object patterns are more scalable and
dynamic compared to the class creational patterns. Creational object patterns are more scalable and dynamic compared to the class creational patterns.
example Abstract Factory
Singleton
****Structural Pattern****
Structural class- Structural class patterns use inheritance to provide
more useful program interfaces by combining the functionality
of multiple classes.
example Adapter (class)
Structural object-Structural object patterns create composite objects by
aggregating individual objects to build larger structures.
The composition of the structural object pattern can be
changed at runtime, which gives us added flexibility
over structural class patterns.
example
Adapter (object)
Facade
Bridge
Composite
****Behavioral Pattern****
Behavioral class- Behavioral class patterns use inheritance to distribute
behavior between classes
example
Interpreter
Behavioral object- Behavioral object patterns allow us to analyze the
patterns of communication between interconnected
objects, such as the included objects of a composite object.
example
Iterator
Observer
Visitor
OTHER THAN GOF
Though the GoF patterns served well in designing and developing object-oriented systems
in both distributed and nondistributed environments, they were not created with
the distributed nature of large-scale enterprise systems in mind.
The authors have categorized the design patterns at seven architectural levels:
• Global
• Enterprise
• System
• Application
• Macrocomponent
• Microcomponent
• Object
The authors have two basic arguments.
The first is that software design involves making
choices, such as which details of an object should be abstracted and what should
be exposed, or which aspects of the objects are to be generalized and which one should
be specialized.
The authors’ second argument is that not all design patterns scale well at all seven
architectural levels. Each pattern has a set of applicable levels, which is an important
feature that must be considered when using the pattern.
J2EE Design Pattern
****Presentation Tier****
Decorating Filter/Intercepting Filter
An object that sits between the client and the web components. It pre-processes
a request and post-processes the response.
Front Controller/ Front Component
An object that accepts all the requests from the client and dispatches or routes
them to appropriate handlers. The Front Controller pattern may divide the
above functionality into two different objects: the Front Controller and the Dispatcher.
In that case, the Front Controller accepts all the requests from the client
and does the authentication, and the Dispatcher dispatches or routes them
to the appropriate handlers.
View Helper
A helper object that encapsulates data access logic on behalf of the presentation
components. For example, JavaBeans can be used as View Helper patterns
for JSP pages.
Composite View
A view object that is made up of an aggregate of other view objects. For example,
a JSP page that includes other JSP and HTML pages using the include
directive or the include action is a Composite View pattern.
Service To Worker
A kind of Model-View-Controller with the Controller acting as a Front Controller
but with one important point: here the Dispatcher (which is a part of the Front
Controller) uses View Helpers to a large extent and aids in view management.
Dispatcher View
A kind of Model-View-Controller with the controller acting as a Front
Controller but with one important point: here the Dispatcher (which is a part
of the Front Controller) does not use View Helpers and does very little work in
view management. The view management is handled by the View components
themselves.
****Business Tier****
Business Delegate
An object that resides on the presentation tier and on behalf of other presentation
tier components calls remote methods on the objects in the business tier.
Transfer Object/ Replicate Object
A serializable object for transferring data over the network.
Session Façade/Session EntityFaçade/Distributed Façade
An object that resides in the business tier, acts as an entry point into the business
tier, and manages the workflow of business service objects, such as session
beans, entity beans, and Data Access Objects. The Session Facade itself
is usually implemented as a session bean.
Aggregate Entity
An object (entity bean) that is made up of or is an aggregate of other entity beans.
Transfer Object /Assembler
An object that resides in the business tier and creates Transfer Objects on the
fly as and when required.
Value List Handler/Page-by-PageIterator/Paged List
An object that manages execution of queries, caching, and processing of
results. Usually implemented as a Session Bean, serving a subset of the
fetched result set to the client as and when needed.
Service Locator
An object that performs the task of locating business services on behalf of
other components in the tier. Usually present in the presentation tier, it is used
by Business Delegates to look up business service objects.
****Integration Tier****
Data Access Object
An object that talks to the actual underlying database and provides other application
components. It serves as a clean, simple, and common interface for
accessing the data, and for reducing the dependency of other components on
the details of using the database.
Service Activator
An object that helps in processing of business methods asynchronously.
Expansion-Pune-10 November 2008
Expansion-Pune-10 November 2008
Expansion-Pune-10 November 2008
Expansion-Pune-10 November 2008
1. Contracts between equals and hashCode method?
Answer:The general contract of hashCode is:
1- If two objects are equal according to the equals(Object) method, then calling the hashCode method on each of the two objects must produce the same integer result.
2- Whenever it is invoked on the same object more than once during an execution of a Java application, the hashCode method must consistently return the same integer, provided no information used in equals comparisons on the object is modified. This integer need not remain consistent from one execution of an application to another execution of the same application.
2. Is struts action classes thread safe by default?
Answer:No, by default struts action classes are not thread safe
Our controller servlet creates only one instance of your Action class, and uses this one instance to service all requests. Thus, you need to write thread-safe Action classes. Follow the same guidelines you would use to write thread-safe Servlets. Here are two general guidelines that will help you write scalable, thread-safe Action classes:
1-Only Use Local Variables - Local variables are created on a stack that is assigned (by your JVM) to each request thread.
2-Conserve Resources -You should strive to use pools and release resources (such as database connections) prior to forwarding control to the appropriate View component -- even if a bean method you have called throws an exception.
3-Whats difference between comparator and comaprable interface?
Comparable interface has “compareTo” method which is normally used for natural ordering.
When you need natural sort order you can implement the Comparable interface.Comparator interface has “compare” method which takes two arguments. It can be used where you want to sort objects based of more then one parameter.
If You want an alternate sort order or sorting on different properties then implement aComparator for your class.Code snippet for Difference Between Comparable And Comparator Interface
4) String Pooling?
Answer:String when created using "" representation uses a concept of string pooling in which all same character string thus created holds reference to same object i.e no new object is created but when new String("") constructor is used it creates new object.
for same string created using "" both equals and == are true
for string created using new operator value equality will return true.
5)What pattern is used to implement string pooling concept?
Answer:Flywieght,flyweight is a design pattern that Java itself heavily depends upon.
flyweight pattern is appropriate when "many objects must be manipulated and these cannot afford to have extraneous data." In Java, String objects are managed as flyweight. Java puts all fixed String literals into a literal pool. For redundant literals, Java keeps only one copy in the pool.
You can force a dynamically created string into the literal pool by creating a new String using String's .intern() method.
e.g.
working on a scheduling application that supports appointments. It contains a Time class that encapsulates a time of day, expressed using hour (presuming a 24-hour clock) and minute.
My application must support very large numbers of appointments, perhaps millions, and I'm concerned about the memory requirement. The reality is, however, that appointments during a business day typically start either on the hour, or at quarter hour intervals past the hour. If I use the flyweight pattern so that I only store unique Time instances, I can reduce the maximum number of typical time objects to 96 (24 hours times four possible times per hour). The appointment application will still support odd times, but predictable use suggests that flyweight will dramatically minimize object creation and memory usage.
The key to making flyweight work is by controlling object instantiation using a factory method. The job of a factory method is simply to create objects: given input criteria, return an object of appropriate type.
6) Difference between Factory and AbstractFactory pattern?
Answer:
"Factory Method" is just used to create object of
the same kind (ie. Cats) that have different variations (ie. breeds of
cats).
The difference lies in how dynamic the substitution needs to be. In both
cases the Product and the Factories to produce them are generalizations.
The difference is that in Factory Method the subclasses in each
generalization map 1:1 to each other while in Abstract Factory the
Factory subclasses map 1:* to Product subclasses.
Abstract factory class which contains many factory methods (in other words its dealing with abstractions)
Thus in Factory Method a concrete factory object can instantiate exactly
one flavor of one Product. But in Abstract Factory a single concrete
factory object can instantiate a different flavor of Product from each
of multiple Product generalizations. IOW, one uses Factory Method when
there is only one family of products and one uses Abstract Factory when
there are construction similarities across multiple families of products.
Abstract Factory Usage
Subscribe to:
Posts (Atom)