package test.com.one.dao.impl;
import java.util.Calendar;
import java.util.Date;
import java.util.List;
import junit.framework.Assert;
import org.junit.After;
import org.junit.Before;
import org.junit.Ignore;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.AbstractTransactionalJUnit4SpringContextTests;
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;
import com.one.dao.CustomerDAO;
import com.one.model.Customer;
@ContextConfiguration(locations={"/applicationContext.xml"})
@RunWith(SpringJUnit4ClassRunner.class)
public class CustomerDAOHibernateImplTests extends AbstractTransactionalJUnit4SpringContextTests{
@Autowired
private CustomerDAO customerDAO;
@Before
public void setup(){
}
@After
public void clean(){
}
@Test
public void testCRUD(){
Customer customer = new Customer();
customer.setCustomerFirstName("firstName");
customer.setCustomerLastName("lastName");
customer.setEmailAddr("email");
customer.setCreatedOn(new Date());
customer.setUpdatedOn(new Date());
customerDAO.saveOrUpdateCustomer(customer);
Assert.assertNotNull(customer.getCustomerId());
Assert.assertTrue(customer.getCustomerId().intValue() > 0);
customer = (Customer) customerDAO.getCustomerByCustomerId(customer.getCustomerId());
Assert.assertNotNull(customer);
Assert.assertEquals(customer.getCustomerFirstName(), "firstName");
Assert.assertEquals(customer.getCustomerLastName(), "lastName");
Assert.assertEquals(customer.getEmailAddr(), "email");
customerDAO.deleteCustomer(customer);
customer = (Customer) customerDAO.getCustomerByCustomerId(customer.getCustomerId());
Assert.assertNull(customer);
}
@Test
public void testGetCustomersByDateRange(){
Customer customer = new Customer();
customer.setCustomerFirstName("firstName");
customer.setCustomerLastName("lastName");
customer.setEmailAddr("email");
customer.setCreatedOn(new Date());
customer.setUpdatedOn(new Date());
customerDAO.saveOrUpdateCustomer(customer);
Assert.assertNotNull(customer.getCustomerId());
Assert.assertTrue(customer.getCustomerId().intValue() > 0);
Calendar c = Calendar.getInstance();
c.add(Calendar.DAY_OF_YEAR, -1);
Date from = c.getTime();
c.add(Calendar.DAY_OF_YEAR, +2);
Date to = c.getTime();
List list = customerDAO.getCustomersByDateRange(from, to);
Assert.assertNotNull(list);
Assert.assertTrue(list.size() > 0);
}
@Ignore
public void testGetCustomerByFirstnameAndLastnameAndEmail(){
Customer customer = new Customer();
customer.setCustomerFirstName("firstName");
customer.setCustomerLastName("lastName");
customer.setEmailAddr("email");
customer.setCreatedOn(new Date());
customer.setUpdatedOn(new Date());
customerDAO.saveOrUpdateCustomer(customer);
Assert.assertNotNull(customer.getCustomerId());
Assert.assertTrue(customer.getCustomerId().intValue() > 0);
customer = (Customer) customerDAO.getCustomerByFirstnameAndLastnameAndEmail("firstName", "lastName", "email");
Assert.assertNotNull(customer);
Assert.assertEquals(customer.getCustomerFirstName(), "firstName");
Assert.assertEquals(customer.getCustomerLastName(), "lastName");
Assert.assertEquals(customer.getEmailAddr(), "email");
}
}
Thursday, April 2, 2009
Unit Testing Sample with Spring and JUnit Annotations
Tuesday, March 31, 2009
Using Spring BlazeDS Integration 1.0.0.M1
1. Download Spring and BlazeDS.
2. Create a java project, remember to push blazeds configuration files to the properly folder.
3. Add this part to your web.xml:
4. Write your applicationContext.xml like this:
5. Enjoy it.
2. Create a java project, remember to push blazeds configuration files to the properly folder.
3. Add this part to your web.xml:
<!-- The front controller of this Spring Web application, responsible for handling all application requests -->
<servlet>
<servlet-name>Spring MVC Dispatcher Servlet</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
<init-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/applicationContext.xml</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
<!-- Map all /messagbroker requests to the DispatcherServlet for handling -->
<servlet-mapping>
<servlet-name>Spring MVC Dispatcher Servlet</servlet-name>
<url-pattern>/messagebroker/*</url-pattern>
</servlet-mapping>
4. Write your applicationContext.xml like this:
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:aop="http://www.springframework.org/schema/aop"
xmlns:tx="http://www.springframework.org/schema/tx"
xmlns:flex="http://www.springframework.org/schema/flex"
xsi:schemaLocation="
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-2.5.xsd
http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-2.5.xsd
http://www.springframework.org/schema/flex http://www.springframework.org/schema/flex/spring-flex-1.0.xsd">
<!-- Bootstraps and exposes the BlazeDS MessageBroker -->
<bean id="_messageBroker" class="org.springframework.flex.messaging.MessageBrokerFactoryBean" />
<!-- Maps request paths at /* to the BlazeDS MessageBroker -->
<bean class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
<property name="mappings">
<value>
/*=_messageBroker
</value>
</property>
</bean>
<!-- Dispatches requests mapped to a MessageBroker -->
<bean class="org.springframework.flex.messaging.servlet.MessageBrokerHandlerAdapter"/>
<bean id="testService"
class="com.one.service.impl.TestServiceImpl">
<flex:remote-service />
</bean>
</beans>
5. Enjoy it.
Sunday, March 22, 2009
Best Practices for Exception Handling and Logging
The Nature of Exceptions
Broadly speaking, there are three different situations that cause exceptions to be thrown:
Exceptions due to programming errors: In this category, exceptions are generated due to programming errors (e.g., NullPointerException and IllegalArgumentException). The client code usually cannot do anything about programming errors.
Exceptions due to client code errors: Client code attempts something not allowed by the API, and thereby violates its contract. The client can take some alternative course of action, if there is useful information provided in the exception. For example: an exception is thrown while parsing an XML document that is not well-formed. The exception contains useful information about the location in the XML document that causes the problem. The client can use this information to take recovery steps.
Exceptions due to resource failures: Exceptions that get generated when resources fail. For example: the system runs out of memory or a network connection fails. The client's response to resource failures is context-driven. The client can retry the operation after some time or just log the resource failure and bring the application to a halt.
Best Practices for Exception Handling
1. When deciding on checked exceptions vs. unchecked exceptions, ask yourself, "What action can the client code take when the exception occurs?"
If the client can take some alternate action to recover from the exception, make it a checked exception. If the client cannot do anything useful, then make the exception unchecked. By useful, I mean taking steps to recover from the exception and not just logging the exception.
Moreover, prefer unchecked exceptions for all programming errors: unchecked exceptions have the benefit of not forcing the client API to explicitly deal with them. They propagate to where you want to catch them, or they go all the way out and get reported. The Java API has many unchecked exceptions, such as NullPointerException, IllegalArgumentException, and IllegalStateException. I prefer working with standard exceptions provided in Java rather than creating my own. They make my code easy to understand and avoid increasing the memory footprint of code.
2. Preserve encapsulation.
Never let implementation-specific checked exceptions escalate to the higher layers. For example, do not propagate SQLException from data access code to the business objects layer. Business objects layer do not need to know about SQLException. You have two options:
1) Convert SQLException into another checked exception, if the client code is expected to recuperate from the exception.
2) Convert SQLException into an unchecked exception, if the client code cannot do anything about it.
3. Try not to create new custom exceptions if they do not have useful information for client code.
4. Do not use your base exception class for "unkown" exception cases.
actually a follow-up from the first advice above. If you model your own exception hierarchy, you will typically have an exception base class (eg. MyAPIException) and several specific ones that inherit from that one (eg. MyAPIPathNotFoundException). Now it is tempting to throw the base exception class whenever you don't really know what else to throw, because the error case is not clear or very seldom. It's probably a Fault and thus you would start mixing it with your Contingency exception class hierarchy, which is obviously a bad thing.
One of the advantages of an exception base class is that the client has the choice to catch the base class if he does not want to handle the specific cases (although that's probably not the most robust code). But if that exception is also thrown in faulty situations, the client can no longer make a distinction between one-of-those-contingency-cases and all-those-unexcpected-fault-cases. And it obviously brakes your explicit exception design: there are those specific error cases you state and let the client know about, but then there is this generic exception thrown where the client cannot know what it means and is not able to handle it as a consequence.
5. When wrapping or logging exceptions, add your specific data to the message.
6. Don't throw exceptions in methods that are likely to be used for the exception handling itself.
This follows straight from the two previous advices: if you throw or log exceptions, you are typically in exception handling code, because you wrap a lower-level exception. If you add dynamic data to your exceptions, you might access methods from the underlying API. But if those methods throw exceptions, your code becomes ugly.
7. Document exceptions.
Best Practices for Using Exceptions
1. Always clean up after yourself
If you are using resources like database connections or network connections, make sure you clean them up. If the API you are invoking uses only unchecked exceptions, you should still clean up resources after use, with try - finally blocks.
2. Never use exceptions for flow control
Generating stack traces is expensive and the value of a stack trace is in debugging. In a flow-control situation, the stack trace would be ignored, since the client just wants to know how to proceed.
3. Do not suppress or ignore exceptions
When a method from an API throws a checked exception, it is trying to tell you that you should take some counter action. If the checked exception does not make sense to you, do not hesitate to convert it into an unchecked exception and throw it again, but do not ignore it by catching it with {} and then continue as if nothing had happened.
4. Do not catch top-level exceptions
5. Log exceptions just once
Logging the same exception stack trace more than once can confuse the programmer examining the stack trace about the original source of exception. So just log it once.
Logging
When your code encounters an exception, it must either handle it, let it bubble up, wrap it, or log it. If your code can programmatically handle an exception (e.g., retry in the case of a network failure), then it should. If it can't, it should generally either let it bubble up (for unchecked exceptions) or wrap it (for checked exceptions). However, it is ultimately going to be someone's responsibility to log the fact that this exception occurred if nobody in the calling stack was able to handle it programmatically. This code should typically live as high in the execution stack as it can. Some examples are the onMessage() method of an MDB, and the main() method of a class. Once you catch the exception, you should log it appropriately.
The JDK has a java.util.logging package built in, although the Log4j project from Apache continues to be a commonly-used alternative. Apache also offers the Commons Logging project, which acts as a thin layer that allows you to swap out different logging implementations underneath in a pluggable fashion. All of these logging frameworks that I've mentioned have basically equivalent levels:
1) FATAL: Should be used in extreme cases, where immediate attention is needed. This level can be useful to trigger a support engineer's pager.
2) ERROR: Indicates a bug, or a general error condition, but not necessarily one that brings the system to a halt. This level can be useful to trigger email to an alerts list, where it can be filed as a bug by a support engineer.
3) WARN: Not necessarily a bug, but something someone will probably want to know about. If someone is reading a log file, they will typically want to see any warnings that arise.
4) INFO: Used for basic, high-level diagnostic information. Most often good to stick immediately before and after relatively long-running sections of code to answer the question "What is the app doing?" Messages at this level should avoid being very chatty.
5) DEBUG: Used for low-level debugging assistance.
If you are using commons-logging or Log4j, watch out for a common gotcha. The error, warn, info, and debug methods are overloaded with one version that takes only a message parameter, and one that also takes a Throwable as the second parameter. Make sure that if you are trying to log the fact that an exception was thrown, you pass both a message and the exception. If you call the version that accepts a single parameter, and pass it the exception, it hides the stack trace of the exception.
When calling log.debug(), it's good practice to always surround the call with a check for log.isDebugEnabled(). This is purely for optimization. It's simply a good habit to get into, and once you do it for a few days, it will just become automatic.
Do not use System.out or System.err. You should always use a logger. Loggers are extremely configurable and flexible, and each appender can decide which level of severity it wants to report/act on, on a package-by-package basis. Printing a message to System.out is just sloppy and generally unforgivable.
Thanks for these following articles:
Best Practices for Exception Handling
Exception Handling Best Practices Part 1
Exception Handling Best Practices Part 2: Control flow in data oriented APIs
Exception Handling Best Practices Part 3
Exception-Handling Antipatterns
Effective Java Exceptions
Three Rules for Effective Exception Handling
Broadly speaking, there are three different situations that cause exceptions to be thrown:
Exceptions due to programming errors: In this category, exceptions are generated due to programming errors (e.g., NullPointerException and IllegalArgumentException). The client code usually cannot do anything about programming errors.
Exceptions due to client code errors: Client code attempts something not allowed by the API, and thereby violates its contract. The client can take some alternative course of action, if there is useful information provided in the exception. For example: an exception is thrown while parsing an XML document that is not well-formed. The exception contains useful information about the location in the XML document that causes the problem. The client can use this information to take recovery steps.
Exceptions due to resource failures: Exceptions that get generated when resources fail. For example: the system runs out of memory or a network connection fails. The client's response to resource failures is context-driven. The client can retry the operation after some time or just log the resource failure and bring the application to a halt.
Best Practices for Exception Handling
1. When deciding on checked exceptions vs. unchecked exceptions, ask yourself, "What action can the client code take when the exception occurs?"
If the client can take some alternate action to recover from the exception, make it a checked exception. If the client cannot do anything useful, then make the exception unchecked. By useful, I mean taking steps to recover from the exception and not just logging the exception.
Moreover, prefer unchecked exceptions for all programming errors: unchecked exceptions have the benefit of not forcing the client API to explicitly deal with them. They propagate to where you want to catch them, or they go all the way out and get reported. The Java API has many unchecked exceptions, such as NullPointerException, IllegalArgumentException, and IllegalStateException. I prefer working with standard exceptions provided in Java rather than creating my own. They make my code easy to understand and avoid increasing the memory footprint of code.
2. Preserve encapsulation.
Never let implementation-specific checked exceptions escalate to the higher layers. For example, do not propagate SQLException from data access code to the business objects layer. Business objects layer do not need to know about SQLException. You have two options:
1) Convert SQLException into another checked exception, if the client code is expected to recuperate from the exception.
2) Convert SQLException into an unchecked exception, if the client code cannot do anything about it.
3. Try not to create new custom exceptions if they do not have useful information for client code.
4. Do not use your base exception class for "unkown" exception cases.
actually a follow-up from the first advice above. If you model your own exception hierarchy, you will typically have an exception base class (eg. MyAPIException) and several specific ones that inherit from that one (eg. MyAPIPathNotFoundException). Now it is tempting to throw the base exception class whenever you don't really know what else to throw, because the error case is not clear or very seldom. It's probably a Fault and thus you would start mixing it with your Contingency exception class hierarchy, which is obviously a bad thing.
One of the advantages of an exception base class is that the client has the choice to catch the base class if he does not want to handle the specific cases (although that's probably not the most robust code). But if that exception is also thrown in faulty situations, the client can no longer make a distinction between one-of-those-contingency-cases and all-those-unexcpected-fault-cases. And it obviously brakes your explicit exception design: there are those specific error cases you state and let the client know about, but then there is this generic exception thrown where the client cannot know what it means and is not able to handle it as a consequence.
5. When wrapping or logging exceptions, add your specific data to the message.
6. Don't throw exceptions in methods that are likely to be used for the exception handling itself.
This follows straight from the two previous advices: if you throw or log exceptions, you are typically in exception handling code, because you wrap a lower-level exception. If you add dynamic data to your exceptions, you might access methods from the underlying API. But if those methods throw exceptions, your code becomes ugly.
7. Document exceptions.
Best Practices for Using Exceptions
1. Always clean up after yourself
If you are using resources like database connections or network connections, make sure you clean them up. If the API you are invoking uses only unchecked exceptions, you should still clean up resources after use, with try - finally blocks.
2. Never use exceptions for flow control
Generating stack traces is expensive and the value of a stack trace is in debugging. In a flow-control situation, the stack trace would be ignored, since the client just wants to know how to proceed.
3. Do not suppress or ignore exceptions
When a method from an API throws a checked exception, it is trying to tell you that you should take some counter action. If the checked exception does not make sense to you, do not hesitate to convert it into an unchecked exception and throw it again, but do not ignore it by catching it with {} and then continue as if nothing had happened.
4. Do not catch top-level exceptions
5. Log exceptions just once
Logging the same exception stack trace more than once can confuse the programmer examining the stack trace about the original source of exception. So just log it once.
Logging
When your code encounters an exception, it must either handle it, let it bubble up, wrap it, or log it. If your code can programmatically handle an exception (e.g., retry in the case of a network failure), then it should. If it can't, it should generally either let it bubble up (for unchecked exceptions) or wrap it (for checked exceptions). However, it is ultimately going to be someone's responsibility to log the fact that this exception occurred if nobody in the calling stack was able to handle it programmatically. This code should typically live as high in the execution stack as it can. Some examples are the onMessage() method of an MDB, and the main() method of a class. Once you catch the exception, you should log it appropriately.
The JDK has a java.util.logging package built in, although the Log4j project from Apache continues to be a commonly-used alternative. Apache also offers the Commons Logging project, which acts as a thin layer that allows you to swap out different logging implementations underneath in a pluggable fashion. All of these logging frameworks that I've mentioned have basically equivalent levels:
1) FATAL: Should be used in extreme cases, where immediate attention is needed. This level can be useful to trigger a support engineer's pager.
2) ERROR: Indicates a bug, or a general error condition, but not necessarily one that brings the system to a halt. This level can be useful to trigger email to an alerts list, where it can be filed as a bug by a support engineer.
3) WARN: Not necessarily a bug, but something someone will probably want to know about. If someone is reading a log file, they will typically want to see any warnings that arise.
4) INFO: Used for basic, high-level diagnostic information. Most often good to stick immediately before and after relatively long-running sections of code to answer the question "What is the app doing?" Messages at this level should avoid being very chatty.
5) DEBUG: Used for low-level debugging assistance.
If you are using commons-logging or Log4j, watch out for a common gotcha. The error, warn, info, and debug methods are overloaded with one version that takes only a message parameter, and one that also takes a Throwable as the second parameter. Make sure that if you are trying to log the fact that an exception was thrown, you pass both a message and the exception. If you call the version that accepts a single parameter, and pass it the exception, it hides the stack trace of the exception.
When calling log.debug(), it's good practice to always surround the call with a check for log.isDebugEnabled(). This is purely for optimization. It's simply a good habit to get into, and once you do it for a few days, it will just become automatic.
Do not use System.out or System.err. You should always use a logger. Loggers are extremely configurable and flexible, and each appender can decide which level of severity it wants to report/act on, on a package-by-package basis. Printing a message to System.out is just sloppy and generally unforgivable.
Thanks for these following articles:
Best Practices for Exception Handling
Exception Handling Best Practices Part 1
Exception Handling Best Practices Part 2: Control flow in data oriented APIs
Exception Handling Best Practices Part 3
Exception-Handling Antipatterns
Effective Java Exceptions
Three Rules for Effective Exception Handling
Thursday, March 5, 2009
Sample of Java Pattern -- Adapter
LegacyModel.java
ModernModel.java
ModernModelAdapter.java
Order.java
AdapterTest.java
you may download the source code.
package adapter;
public class LegacyModel {
public void ins(String sku){
System.out.println("call ins method.");
}
}
ModernModel.java
package adapter;
public interface ModernModel {
public void save(Order order);
}
ModernModelAdapter.java
package adapter;
public class ModernModelAdapter implements ModernModel{
private LegacyModel legacyModel;
public ModernModelAdapter(LegacyModel legacyModel) {
super();
this.legacyModel = legacyModel;
}
public void save(Order order){
String sku = order.getSku();
legacyModel = new LegacyModel();
legacyModel.ins(sku);
}
}
Order.java
package adapter;
public class Order {
private String sku;
public String getSku() {
return sku;
}
public void setSku(String sku) {
this.sku = sku;
}
}
AdapterTest.java
package adapter;
public class AdapterTest {
public static void main(String[] args) {
LegacyModel legacy = new LegacyModel();
Order order = new Order();
order.setSku("sku");
ModernModelAdapter adapter = new ModernModelAdapter(legacy);
adapter.save(order);
}
}
you may download the source code.
Friday, February 27, 2009
Sample of Java Pattern -- Proxy
Order.java
OrderDAO.java
OrderDAOImpl.java
OrderDAOProxy.java
ProxyTest.java
you may download the source code.
package proxy;
import java.io.Serializable;
import java.util.Date;
public class Order implements Serializable {
private int orderId;
private String sku;
private Date createdOn;
private Date updatedOn;
private int status;
public int getOrderId() {
return orderId;
}
public void setOrderId(int orderId) {
this.orderId = orderId;
}
public String getSku() {
return sku;
}
public void setSku(String sku) {
this.sku = sku;
}
public Date getCreatedOn() {
return createdOn;
}
public void setCreatedOn(Date createdOn) {
this.createdOn = createdOn;
}
public Date getUpdatedOn() {
return updatedOn;
}
public void setUpdatedOn(Date updatedOn) {
this.updatedOn = updatedOn;
}
public int getStatus() {
return status;
}
public void setStatus(int status) {
this.status = status;
}
@Override
public int hashCode() {
final int prime = 31;
int result = 1;
result = prime * result + ((sku == null) ? 0 : sku.hashCode());
return result;
}
@Override
public boolean equals(Object obj) {
if (this == obj)
return true;
if (obj == null)
return false;
if (getClass() != obj.getClass())
return false;
Order other = (Order) obj;
if (sku == null) {
if (other.sku != null)
return false;
} else if (!sku.equals(other.sku))
return false;
return true;
}
}
OrderDAO.java
package proxy;
import java.util.List;
public interface OrderDAO {
public List<Order> getAllOrders();
}
OrderDAOImpl.java
package proxy;
import java.util.ArrayList;
import java.util.List;
public class OrderDAOImpl implements OrderDAO{
public List<Order> getAllOrders(){
List<Order> list = new ArrayList<Order>();
for(int i =0; i<10; i++){
Order order = new Order();
order.setSku("sku"+i);
list.add(order);
}
return list;
}
}
OrderDAOProxy.java
package proxy;
import java.util.List;
public class OrderDAOProxy implements OrderDAO{
public List<Order> getAllOrders(){
long stTime = System.currentTimeMillis();
OrderDAO orderDAOImpl = new OrderDAOImpl();
List<Order> list = orderDAOImpl.getAllOrders();
long endTime = System.currentTimeMillis();
System.out.println("took " + (endTime - stTime) + " milliseconds.");
return list;
}
}
ProxyTest.java
package proxy;
public class ProxyTest {
public static void main(String[] args) {
OrderDAO orderDAOProxy = new OrderDAOProxy();
orderDAOProxy.getAllOrders();
}
}
you may download the source code.
Saturday, February 21, 2009
Sample of Java Pattern -- State
OrderState.java
OrderOpendState.java
OrderInProgressState.java
OrderCancelledState.java
OrderClosedState.java
OrderStateMgmt.java
OrderStateTest.java
you may download the source code.
package state;
public interface OrderState {
public void handleOrder(String orderNo);
public void cancelOrder(String orderNo);
public void completeOrder(String orderNo);
}
OrderOpendState.java
package state;
public class OrderOpendState implements OrderState {
OrderStateMgmt orderStateMgmt;
public OrderOpendState(OrderStateMgmt orderStateMgmt){
this.orderStateMgmt = orderStateMgmt;
}
public void handleOrder(String orderNo){
System.out.println("handle this order, orderNo=" + orderNo);
orderStateMgmt.setState(orderStateMgmt.getOrderInProgressState());
}
public void cancelOrder(String orderNo){
System.out.println("cancel this order, orderNo=" + orderNo);
orderStateMgmt.setState(orderStateMgmt.getOrderCancelledState());
}
public void completeOrder(String orderNo){
System.out.println("could not complete this order under opend status, orderNo=" + orderNo);
}
}
OrderInProgressState.java
package state;
public class OrderInProgressState implements OrderState {
OrderStateMgmt orderStateMgmt;
public OrderInProgressState(OrderStateMgmt orderStateMgmt){
this.orderStateMgmt = orderStateMgmt;
}
public void handleOrder(String orderNo){
System.out.println("could not handle this order under in progress status, orderNo=" + orderNo);
}
public void cancelOrder(String orderNo){
System.out.println("cancel this order, orderNo=" + orderNo);
orderStateMgmt.setState(orderStateMgmt.getOrderCancelledState());
}
public void completeOrder(String orderNo){
System.out.println("complete this order, orderNo=" + orderNo);
orderStateMgmt.setState(orderStateMgmt.getOrderClosedState());
}
}
OrderCancelledState.java
package state;
public class OrderCancelledState implements OrderState {
OrderStateMgmt orderStateMgmt;
public OrderCancelledState(OrderStateMgmt orderStateMgmt){
this.orderStateMgmt = orderStateMgmt;
}
public void handleOrder(String orderNo){
System.out.println("could not handle this order under cancelled status, orderNo=" + orderNo);
}
public void cancelOrder(String orderNo){
System.out.println("could not cancel this order under cancelled status, orderNo=" + orderNo);
}
public void completeOrder(String orderNo){
System.out.println("could not complete this order under cancelled status, orderNo=" + orderNo);
}
}
OrderClosedState.java
package state;
public class OrderClosedState implements OrderState {
OrderStateMgmt orderStateMgmt;
public OrderClosedState(OrderStateMgmt orderStateMgmt){
this.orderStateMgmt = orderStateMgmt;
}
public void handleOrder(String orderNo){
System.out.println("could not handle this order under closed status, orderNo=" + orderNo);
}
public void cancelOrder(String orderNo){
System.out.println("could not cancel this order under closed status, orderNo=" + orderNo);
}
public void completeOrder(String orderNo){
System.out.println("could not complete this order under closed status, orderNo=" + orderNo);
}
}
OrderStateMgmt.java
package state;
public class OrderStateMgmt {
private OrderOpendState orderOpendState;
private OrderInProgressState orderInProgressState;
private OrderCancelledState orderCancelledState;
private OrderClosedState orderClosedState;
private OrderState orderState;
public OrderStateMgmt(){
this.orderOpendState = new OrderOpendState(this);
this.orderInProgressState = new OrderInProgressState(this);
this.orderCancelledState = new OrderCancelledState(this);
this.orderClosedState = new OrderClosedState(this);
this.orderState = this.orderOpendState;
System.out.println("The order inital status is: opend.");
}
public void setState(OrderState orderState){
this.orderState = orderState;
}
public OrderOpendState getOrderOpendState() {
return orderOpendState;
}
public OrderInProgressState getOrderInProgressState() {
return orderInProgressState;
}
public OrderCancelledState getOrderCancelledState() {
return orderCancelledState;
}
public OrderClosedState getOrderClosedState() {
return orderClosedState;
}
public void handleOrder(String orderNo){
orderState.handleOrder(orderNo);
}
public void cancelOrder(String orderNo){
orderState.cancelOrder(orderNo);
}
public void completeOrder(String orderNo){
orderState.completeOrder(orderNo);
}
}
OrderStateTest.java
package state;
public class OrderStateTest {
public static void main(String[] args) {
OrderStateMgmt orderStateMgmtA = new OrderStateMgmt();
orderStateMgmtA.handleOrder("01");
orderStateMgmtA.completeOrder("01");
OrderStateMgmt orderStateMgmtB = new OrderStateMgmt();
orderStateMgmtB.handleOrder("02");
orderStateMgmtB.cancelOrder("02");
OrderStateMgmt orderStateMgmtC = new OrderStateMgmt();
orderStateMgmtC.completeOrder("03");
}
}
you may download the source code.
Friday, February 13, 2009
Sample of Java Pattern -- Composite
Department.java
CompositeDepartment.java
SingleDepartment.java
CompositeTest.java
you may download the source code.
package composite;
import java.util.List;
public interface Department {
public Department getDepartment();
public String getDepartmentname();
public void add(Department department);
public void remove(Department department);
public boolean hasSubDepartments();
public List<Department> getSubDepartments();
}
CompositeDepartment.java
package composite;
import java.util.ArrayList;
import java.util.List;
public class CompositeDepartment implements Department {
private String name;
private List<Department> departments = new ArrayList<Department>();
public CompositeDepartment(String name) {
super();
System.out.println("Department " + name + " is created.");
this.name = name;
}
public Department getDepartment() {
return this;
}
public String getDepartmentname() {
return this.name;
}
public void add(Department department){
System.out.println("Department " + department.getDepartmentname() + " is added to Department " + this.name + ".");
departments.add(department);
}
public void remove(Department department){
System.out.println("Department " + department.getDepartmentname() + " is removed from Department " + this.name + ".");
departments.remove(department);
}
public boolean hasSubDepartments(){
if(departments == null || departments.isEmpty())
return false;
return true;
}
public List<Department> getSubDepartments(){
if(hasSubDepartments())
return departments;
return null;
}
}
SingleDepartment.java
package composite;
import java.util.List;
public class SingleDepartment implements Department {
private String name;
public SingleDepartment(String name) {
super();
System.out.println("Department " + name + " is created.");
this.name = name;
}
public Department getDepartment() {
return this;
}
public String getDepartmentname() {
return this.name;
}
public void add(Department department){
System.out.println("Could not add a child department in Department " + this.name + ".");
}
public void remove(Department department){
System.out.println("Department " + department.getDepartmentname() + " doesn't belong to Department " + this.name + ".");
}
public boolean hasSubDepartments(){
return false;
}
public List<Department> getSubDepartments(){
return null;
}
}
CompositeTest.java
package composite;
public class CompositeTest {
public static void main(String[] args) {
Department hq = new CompositeDepartment("HQ");
Department financing = new SingleDepartment("Financing");
Department marketing = new CompositeDepartment("Marketing");
Department preSales = new SingleDepartment("PreSales");
Department sales = new SingleDepartment("Sales");
Department postSales = new SingleDepartment("PostSales");
Department techSupport = new SingleDepartment("TechSupport");
hq.add(financing);
hq.add(marketing);
hq.add(techSupport);
marketing.add(preSales);
marketing.add(sales);
marketing.add(postSales);
System.out.println("hq has sub departments: " + hq.hasSubDepartments());
System.out.println("marketing has sub departments: " + marketing.hasSubDepartments());
System.out.println("techSupport has sub departments: " + techSupport.hasSubDepartments());
marketing.remove(preSales);
marketing.remove(sales);
marketing.remove(postSales);
sales.remove(preSales);
hq.remove(financing);
hq.remove(marketing);
hq.remove(techSupport);
}
}
you may download the source code.
Subscribe to:
Posts (Atom)
