Hit List
The Factory Method Design Pattern in Java
Parent Class:
public interface Shape {
public String draw();
}
Derived Class 1
public class Circle implements Shape {
@Override
public String draw() {
return “Circle draw ...“;
}
}
Derived Class 2:
public class Triangle implements Shape {
@Override
public String draw() {
return “Triangle draw …”;
}
}
Derived Class 3:
public class Rectangle implements Shape {
@Override
public String draw() {
return “Rectangle draw …”;
}
}
Factory Class:
public class ShapeFactory {
public Shape getShape(String shapeType) {
Shape shape = null;
if (“circle”.equals(shapeType))
shape = new Circle();
else if (“triangle “.equals(shapeType))
shape = new Triangle ();
else if (“rectangle “.equals(shapeType))
shape = new Rectangle ();
return shape;
}The Abstract Factory Method Design Pattern in Java
public interface Shape {
void draw();
}
public class Square implements Shape {
@Override
public void draw() {
System.out.println("Inside Square::draw() method.");
}
}
public class Circle implements Shape {
@Override
public void draw() {
System.out.println("Inside Circle::draw() method.");
}
}
public interface Color {
void fill();
}
public class Red implements Color {
@Override
public void fill() {
System.out.println("Inside Red::fill() method.");
}
}
public class Green implements Color {
@Override
public void fill() {
System.out.println("Inside Green::fill() method.");
}
}
public class Blue implements Color {
@Override
public void fill() {
System.out.println("Inside Blue::fill() method.");
}
}
public abstract class AbstractFactory {
abstract Color getColor(String color);
abstract Shape getShape(String shape) ;
}
public class ShapeFactory extends AbstractFactory {
@Override
public Shape getShape(String shapeType){
if(shapeType == null){
return null;
}
if(shapeType.equalsIgnoreCase("CIRCLE")){
return new Circle();
} else if(shapeType.equalsIgnoreCase("RECTANGLE")){
return new Rectangle();
} else if(shapeType.equalsIgnoreCase("SQUARE")){
return new Square();
}
return null;
}
@Override
Color getColor(String color) {
return null;
}
}
public class ColorFactory extends AbstractFactory {
@Override
public Shape getShape(String shapeType){
return null;
}
@Override
Color getColor(String color) {
if(color == null){
return null;
}
if(color.equalsIgnoreCase("RED")){
return new Red();
} else if(color.equalsIgnoreCase("GREEN")){
return new Green();
} else if(color.equalsIgnoreCase("BLUE")){
return new Blue();
}
return null;
}
}
public class FactoryProducer {
public static AbstractFactory getFactory(String choice){
if(choice.equalsIgnoreCase("SHAPE")){
return new ShapeFactory();
} else if(choice.equalsIgnoreCase("COLOR")){
return new ColorFactory();
}
return null;
}
}
public class AbstractFactoryPatternDemo {
public static void main(String[] args) {
//get shape factory
AbstractFactory shapeFactory = FactoryProducer.getFactory("SHAPE");
//get an object of Shape Circle
Shape shape1 = shapeFactory.getShape("CIRCLE");
//call draw method of Shape Circle
shape1.draw();
//get an object of Shape Rectangle
Shape shape2 = shapeFactory.getShape("RECTANGLE");
//call draw method of Shape Rectangle
shape2.draw();
//get an object of Shape Square
Shape shape3 = shapeFactory.getShape("SQUARE");
//call draw method of Shape Square
shape3.draw();
//get color factory
AbstractFactory colorFactory = FactoryProducer.getFactory("COLOR");
//get an object of Color Red
Color color1 = colorFactory.getColor("RED");
//call fill method of Red
color1.fill();
//get an object of Color Green
Color color2 = colorFactory.getColor("Green");
//call fill method of Green
color2.fill();
//get an object of Color Blue
Color color3 = colorFactory.getColor("BLUE");
//call fill method of Color Blue
color3.fill();
}
}
Parent Class:
public interface Shape {
public String draw();
}
Derived Class 1
public class Circle implements Shape {
@Override
public String draw() {
return “Circle draw ...“;
}
}
Derived Class 2:
public class Triangle implements Shape {
@Override
public String draw() {
return “Triangle draw …”;
}
}
Derived Class 3:
public class Rectangle implements Shape {
@Override
public String draw() {
return “Rectangle draw …”;
}
}
Factory Class:
public class ShapeFactory {
public Shape getShape(String shapeType) {
Shape shape = null;
if (“circle”.equals(shapeType))
shape = new Circle();
else if (“triangle “.equals(shapeType))
shape = new Triangle ();
else if (“rectangle “.equals(shapeType))
shape = new Rectangle ();
return shape;
}The Abstract Factory Method Design Pattern in Java
public interface Shape {
void draw();
}
public class Square implements Shape {
@Override
public void draw() {
System.out.println("Inside Square::draw() method.");
}
}
public class Circle implements Shape {
@Override
public void draw() {
System.out.println("Inside Circle::draw() method.");
}
}
public interface Color {
void fill();
}
public class Red implements Color {
@Override
public void fill() {
System.out.println("Inside Red::fill() method.");
}
}
public class Green implements Color {
@Override
public void fill() {
System.out.println("Inside Green::fill() method.");
}
}
public class Blue implements Color {
@Override
public void fill() {
System.out.println("Inside Blue::fill() method.");
}
}
public abstract class AbstractFactory {
abstract Color getColor(String color);
abstract Shape getShape(String shape) ;
}
public class ShapeFactory extends AbstractFactory {
@Override
public Shape getShape(String shapeType){
if(shapeType == null){
return null;
}
if(shapeType.equalsIgnoreCase("CIRCLE")){
return new Circle();
} else if(shapeType.equalsIgnoreCase("RECTANGLE")){
return new Rectangle();
} else if(shapeType.equalsIgnoreCase("SQUARE")){
return new Square();
}
return null;
}
@Override
Color getColor(String color) {
return null;
}
}
public class ColorFactory extends AbstractFactory {
@Override
public Shape getShape(String shapeType){
return null;
}
@Override
Color getColor(String color) {
if(color == null){
return null;
}
if(color.equalsIgnoreCase("RED")){
return new Red();
} else if(color.equalsIgnoreCase("GREEN")){
return new Green();
} else if(color.equalsIgnoreCase("BLUE")){
return new Blue();
}
return null;
}
}
public class FactoryProducer {
public static AbstractFactory getFactory(String choice){
if(choice.equalsIgnoreCase("SHAPE")){
return new ShapeFactory();
} else if(choice.equalsIgnoreCase("COLOR")){
return new ColorFactory();
}
return null;
}
}
public class AbstractFactoryPatternDemo {
public static void main(String[] args) {
//get shape factory
AbstractFactory shapeFactory = FactoryProducer.getFactory("SHAPE");
//get an object of Shape Circle
Shape shape1 = shapeFactory.getShape("CIRCLE");
//call draw method of Shape Circle
shape1.draw();
//get an object of Shape Rectangle
Shape shape2 = shapeFactory.getShape("RECTANGLE");
//call draw method of Shape Rectangle
shape2.draw();
//get an object of Shape Square
Shape shape3 = shapeFactory.getShape("SQUARE");
//call draw method of Shape Square
shape3.draw();
//get color factory
AbstractFactory colorFactory = FactoryProducer.getFactory("COLOR");
//get an object of Color Red
Color color1 = colorFactory.getColor("RED");
//call fill method of Red
color1.fill();
//get an object of Color Green
Color color2 = colorFactory.getColor("Green");
//call fill method of Green
color2.fill();
//get an object of Color Blue
Color color3 = colorFactory.getColor("BLUE");
//call fill method of Color Blue
color3.fill();
}
}
OOPS Principles
Cohesion and Coupling deal with the quality of an OO design. Generally, good OO design should be loosely coupled and highly cohesive. Lot of the design principles, design patterns which have been created are based on the idea of “Loose coupling and high cohesion”.
The aim of the design should be to make the application:
If on the other hand class A apart from interacting class B by means of its interface also interacts through the non-interface stuff of class B then they are said to be tightly coupled. Suppose the developer changes the class B‘s non-interface part i.e non API stuff then in case of loose coupling class A does not breakdown but tight coupling causes the class A to break.
So its always a good OO design principle to use loose coupling between the classes i.e all interactions between the objects in OO system should use the APIs. An aspect of good class and API design is that classes should be well encapsulated.
Cohesion:
Cohesion is used to indicate the degree to which a class has a single, well-focused purpose. Coupling is all about how classes interact with each other, on the other hand cohesion focuses on how single class is designed. Higher the cohesiveness of the class, better is the OO design.
Benefits of Higher Cohesion:
Single Responsibility principle aims at creating highly cohesive classes.
The aim of the design should be to make the application:
- easier to develop
- easier to maintain
- easier to add new features
- less Fragile.
If on the other hand class A apart from interacting class B by means of its interface also interacts through the non-interface stuff of class B then they are said to be tightly coupled. Suppose the developer changes the class B‘s non-interface part i.e non API stuff then in case of loose coupling class A does not breakdown but tight coupling causes the class A to break.
So its always a good OO design principle to use loose coupling between the classes i.e all interactions between the objects in OO system should use the APIs. An aspect of good class and API design is that classes should be well encapsulated.
Cohesion:
Cohesion is used to indicate the degree to which a class has a single, well-focused purpose. Coupling is all about how classes interact with each other, on the other hand cohesion focuses on how single class is designed. Higher the cohesiveness of the class, better is the OO design.
Benefits of Higher Cohesion:
- Highly cohesive classes are much easier to maintain and less frequently changed.
- Such classes are more usable than others as they are designed with a well-focused purpose.
Single Responsibility principle aims at creating highly cohesive classes.
Webservice
We can build web service using below softwares
1. JAX-WS (Java XML webservice
2. Apache CXF
3. Apache Axis
**OASIS is provider of web service security
Component vs Services
1.Both are self executed.
2.Component can be extended within a platform like .NET/JAVA,but services can use in cross platform too(it will communicate through XML/SOAP).
SOAP vs REST
Transport is platform & protocol neutral. Supports multiple protocols like HTTP(S), Messaging, TCP, UDP, SMTP, etc.
1. JAX-WS (Java XML webservice
2. Apache CXF
3. Apache Axis
**OASIS is provider of web service security
Component vs Services
1.Both are self executed.
2.Component can be extended within a platform like .NET/JAVA,but services can use in cross platform too(it will communicate through XML/SOAP).
SOAP vs REST
Transport is platform & protocol neutral. Supports multiple protocols like HTTP(S), Messaging, TCP, UDP, SMTP, etc.
SOAPTransport is platform & protocol neutral. Supports multiple protocols like HTTP(S), Messaging, TCP, UDP, SMTP, etc.
Permits only XML data format, hence language neutral. You define operations, which tunnels through thePOST or GET. The focus is on accessing the named operations and exposing the application logic as a service. Defines the contract via WSDL. SOAP based reads cannot be cached. The applicationthat uses SOAP needs to provide cacheing. Supports both SSL security and WS-security, which adds some enterprise security features. Supports identity through intermediaries, not just point to point SSL. WS-Security maintains its encryption right up to the point where the request is being processed. WS-Security allows you to secure parts (e.g. only credit card details) of the message that needs to be secured. Given that encryption/decryption is not a cheap operation, this can be a performance boost for larger messages. It is also possible with WS-Security to secure different parts of the message using different keys or encryption algorithms. This allows separate parts of the message to be read by different people without exposing other, unneeded information. SSL security can only be used with HTTP. WS-Security can be used with other protocols like UDP, SMTP, etc. Has comprehensive support for both ACID based transaction management for short-lived transactions and compensation based transaction managementfor long-running transactions. It also supports two-phase commit across distributed resources. SOAP has success or retry logic built in and provides end-to-end reliability even through SOAP intermediaries. SOAP is favored where service requires comprehensive support for security, transactional reliability and stricter contract. |
RESTTransport is protocol specific. Supports only HTTP or HTTPS protocols.
Permits multiple data formats like XML, JSON data, text, HTML, atom, RSS, etc. Any browser can be used because the REST approach uses the standard GET, PUT, POST, and DELETEweb operations. The focus is on accessing the named resources and exposing the data as a service. WSDL 2.0 defining non SOAP bindings and the emergence of WADL. Simpler to implement. REST has Ajax support. It can use the XMLHttpRequest object. Good for stateless CRUD (Create, Read, Update, and Delete) operations. REST based reads can be cached. Performs and scales better. Supports only point-to-point SSL security. The basic mechanism behind SSL is that the client encrypts all of the requests based on a key retrieved from a third party. When the request is received at the destination, it is decrypted and presented to the service. This means the request is only encrypted while it is traveling between the client and the server. Once it hits the server (or a proxy which has a valid certificate), it is decrypted from that moment on. The SSL encrypts the whole message, whether all of it is sensitive or not. REST supports transactions, but it is neither ACID compliant nor can provide two phase commit across distributed transactional resources as it is limited by its HTTP protocol. REST does not have a standard messaging system, and expects clients invoking the service to deal with communication failures by retrying. In general, a REST based web service is preferred due to its simplicity, performance, scalability, and support for multiple data formats. |
Important FAQ
Can you describe the high level architecture of the application that you had worked on recently? or Can you give a 100 feet bird's eye view of the application you were involved in as a developer or designer?
- 3 to n-tier enterprise Java architecture, the MVC-2 design pattern, the distinction between physical and logical tiers, and the layered architecture.The logical tiers shown in the diagrams for the above link are basically layers, and the layers are used for organizing your code. Typical layers include Presentation, Business and Data – the same as the traditional 3-tier model. But when talk about layers, we’re only talking about logical organization of code. Physical tiers however, are only about where the code gets deployed and run as war, ear or jar. Specifically, tiers are places where layers are deployed and where layers run. In other words, tiers are the physical deployment of layers.
- high level architectural patterns and the pros and cons of each approach. Discusses a number different architectual styles like MVC, SOA, UI Component, RESTful data composition, HTML data composition, Plug-in architecture, and Event Driven Architecture (EDA). Also, covers a sample enterprise architecture, which is a hybrid of a number of architectural styles.
- knowing the difference between a component and a service. Covers the differences between components and services and CBA (Component Based Architecture) Vs, SOA (Service Oriented Architecture). Also, briefly covers single page web design and SCA (Service Component Architecture)
- Understanding of various types of application integration styles. Enterprise applications need to be integrated with other systems, and this post covers different integration styles like sharing the same database, feed based, RPC style (e.g. web services), and exchanging JMS messages.
- Good working knowledge of popular and sought-after technologies and frameworks like Maven, Spring, Hibernate, JSF, etc. Covers a number of tutorials using sought-after frameworks and technologies like like Spring, Maven, JSF, JDBC, and RESTful web service.
Project Management
- SMAC - > Social , Mobile , Analytics and Cloud
- Effort Estimation - FP / Cosmic
- Cost - Cocomo / Rate Card
- Risk - Avoidance, Acceptance, Mitigation, Transfer
- PERT - Program Evaluation Mitigation and transfer
Time Management
- Define Activity
- Sequence Activity
- Resource Estimation
- Effort Estimation
- Development
- Control Schedule
Scope Management
- Collect Requirement
- Define Scope
- Create WBS
- Verify Scope
- Control Scope
Cost Management
- Earned Value - SV , CV , SPV ,CPV
Triple Constraints
- Cost/Resource
- Schedule/Time
- Scope/Quality
RAID - Risks, Assumption, Issues , Dependencies
Inheritance vs Composition
is a vs has a relationship
If you understand the difference, it's easier to explain.
Procedural Code
An example of this is PHP without the use of classes (particularly before PHP5). All logic is encoded in a set of functions. You may include other files containing helper functions and so on and conduct your business logic by passing data around in functions. This can be very hard to manage as the application grows. PHP5 tries to remedy this by offering more object oriented design.
Inheritance
This encourages the use of classes. Inheritance is one of the three tenets of OO design (inheritance, polymorphism, encapsulation).
class Person
{
String Title;
String Name;
Int Age
}
class Employee : Person {
Int Salary;
String Title;
}
This is inheritance at work. The Employee "is a" Person or inherits from Person. All inheritance relationships are "is-a" relationships. Employee also shadows the Title property from Person, meaning Employee.Title will return the Title for the Employee not the Person.
Composition
Composition is favoured over inheritance. To put it very simply you would have:
class Person
{
String Title;
String Name;
Int Age;
public Person(String title, String name, String age) {
this.Title = title;
this.Name = name;
this.Age = age;
}
}
class Employee {
Int Salary;
private Person person;
public Employee(Person p, Int salary) {
this.person = p;
this.Salary = salary;
}
}
Person johnny = new Person ("Mr.", "John", 25);
Employee john = new Employee (johnny, 50000);
Composition is typically "has a" or "uses a" relationship. Here the Employee class has a Person. It does not inherit from Person but instead gets the Person object passed to it, which is why it "has a" Person.
Composition over InheritanceNow say you want to create a Manager type so you end up with:
class Manager : Person, Employee { ... }
This example will work fine, however, what if Person and Employee both declared Title? Should Manager.Title return "Manager of Operations" or "Mr."? Under composition this ambiguity is better handled:
Class Manager {
public Title;
public Manager(Person p, Employee e) {
this.Title = e.Title;
} }
The Manager object is composed as an Employee and a Person. The Title behaviour is taken from employee. This explicit composition removes ambiguity among other things and you'll encounter fewer bugs.
is a vs has a relationship
If you understand the difference, it's easier to explain.
Procedural Code
An example of this is PHP without the use of classes (particularly before PHP5). All logic is encoded in a set of functions. You may include other files containing helper functions and so on and conduct your business logic by passing data around in functions. This can be very hard to manage as the application grows. PHP5 tries to remedy this by offering more object oriented design.
Inheritance
This encourages the use of classes. Inheritance is one of the three tenets of OO design (inheritance, polymorphism, encapsulation).
class Person
{
String Title;
String Name;
Int Age
}
class Employee : Person {
Int Salary;
String Title;
}
This is inheritance at work. The Employee "is a" Person or inherits from Person. All inheritance relationships are "is-a" relationships. Employee also shadows the Title property from Person, meaning Employee.Title will return the Title for the Employee not the Person.
Composition
Composition is favoured over inheritance. To put it very simply you would have:
class Person
{
String Title;
String Name;
Int Age;
public Person(String title, String name, String age) {
this.Title = title;
this.Name = name;
this.Age = age;
}
}
class Employee {
Int Salary;
private Person person;
public Employee(Person p, Int salary) {
this.person = p;
this.Salary = salary;
}
}
Person johnny = new Person ("Mr.", "John", 25);
Employee john = new Employee (johnny, 50000);
Composition is typically "has a" or "uses a" relationship. Here the Employee class has a Person. It does not inherit from Person but instead gets the Person object passed to it, which is why it "has a" Person.
Composition over InheritanceNow say you want to create a Manager type so you end up with:
class Manager : Person, Employee { ... }
This example will work fine, however, what if Person and Employee both declared Title? Should Manager.Title return "Manager of Operations" or "Mr."? Under composition this ambiguity is better handled:
Class Manager {
public Title;
public Manager(Person p, Employee e) {
this.Title = e.Title;
} }
The Manager object is composed as an Employee and a Person. The Title behaviour is taken from employee. This explicit composition removes ambiguity among other things and you'll encounter fewer bugs.