RDO,ADO & TDO IN ORPOS

After completing this lesson, you should be able to: Differentiate between Retail Domain Objects, Application Domain Objects, and Tour Data Objects Instantiate and use the different object types Explain hierarchical relationships in objects necessary to represent a new tender type

RETAIL DOMAIN OBJECTS Every business entity has a class ITEM TENDER CUSTOMER EMPLOYEE Retail Domain objects are primary objects in POS , mainly stored in the cargo of the bus and contain the business logic for the entity. Base has many RDOs written in domain.jar file.

HOW TO CREATE OBJECTS OF RDO

RETAIL DOMAIN OBJECT DOMAIN OBJECT FACTORY

INSTANCE OF RDO CAN BE CREATED IN 2 WAYS Object can be obtained from DOMAIN OBJECT FACTORY

DOMAIN GATEWAY

A handle to the domain object factory can be obtained from Domain Gateway (singleton class)which maintains the application state information(like currency types, locales,logger etc).
RDOS own clone method.

Domain Object Factory

Common object model used by the POS follows the factory design pattern
Domain Object factory object is created from Domain Gateway as follows: DomainObjectFactory domainFactory= DomainGateway.getFactory();

The getFactory() method of Domain Gateway looks up the domain.properties file. It finds the path of the DomainObjectFactory implementation and creates its instance. This instance is returned by the getFactory() method.

DOMAIN.PROPERTIES
This file contains Domain Level Information such as:
Country specific information such as length of postal code , phone numbers etc Registry of DataTransactionIfc implementations. Other parameters and their values eg DiscountIncludedInSubtotal whose boolean value decides whether the discount to be included in subtotal or not

DOMAIN OBJECT FACTORY pseudocode

public class DomainObjectFactory implements DomainObjectFactoryIfc { public DomainObjectFactory() { } public myRetailDomainObjectIfc getMyRetailDomainObjectIfc () { return (new myRetailDomainObject()); } Other methods }

It contains get______Instance() methods for each of the RDOs which would return a new instance of the particular object. Eg. getTenderInstance()

EntityRDO code for ex TenderRDO

public class NewTenderRetailDomainObject extends NewTenderRetailDomainObject implements AbstractTenderLineItem { protected String newTenderAttribute=null;

public NewTenderRetailDomainObject () { typeCode=TenderLineItemIfc.NEW_TENDER_RDO; amountTender=DomainGateway.getBaseCurrencyInstance(); } Public Sring getTenderAttribute() { return (this.tenderAttribute); } } All the tenderRDO extends AbstractTenderLineItem, the amount of the tender must be set at the proper level for it to function correctly. The attribute newTenderAttribute in the above code is specific to this new tender type. Getters and setters are declared for these newly created attributes. The type code is a constant that needs to be set to let the system know which tender type this RDO represents.

RDO INTERFACE CODE

Public interface NewTenderRetailDomainObjectIfc extends TenderLineItemIfc { public String getNewTenderAttribute(); public void setNewTenderAttribute(String value); public boolean equals(Object obj); public Object clone(); public String toString(); }

All the tender RDO interfaces extend the standard TenderLineItemIfc interface. Getters and setters for the new attributes of the RDO along with clone(), equals() and toString() methods are also declared in this interface.

KEY INTERFACE FOR ALL RDOs

public interface EYSDomainIfc extends Serializable, Cloneable { // the following methods must be derfined for all // domain classes public Object clone(); public boolean equals(Object obj); public String toString(); }

Every Retail Domain Object implements either the EYSDomainIfc interface or one of the other interfaces that extends EYSDomainIfc. Since EYSDomainIfc contains the methods clone(), equals() and toString() methods declared, all the classes that implement it or one of its subclasses, will have to implement them. The clone() method is especially important because the framework calls it frequently in base product and hence should be implemented correctly for the Retail Domain Object to function properly.

APPLICATION DOMAIN OBJECTS

Application Domain Objects are an additional layer of abstraction provided to RDO s. An ADO contains application logic for dealing with tender types and operates on the tender RDOS For ex. Getting new instance types from Factory, validating an RDO , setting up tender attributes from hashmap. validate(); initializeTenderRDO(); get/setTenderAttributes(); getJournalMemento(); etc.. Every ADO is associated with a tender RDO (except for StoreADO and RegisterADO). E.g. check whether credit card can be accepted for the given transaction

The initializeTenderRDO() Method

This method is used to get an instance of the RDO from the factory.

protected void initializeTenderRDO() { DomainObjectFactoryIfc domainFactory = DomainGeteway.getFactory(); tenderRDO = domainFactory.getMyRetailDomainObjectInsta

nce(); }

This method sets the tenderRDO attribute to the appropriate tender RDO type.

The getTenderType() Method

This method is used to get the type of Tender that the ADO represents
public TenderTypeEnum getTenderType() { return TenderTypeEnum.MINE; }

The getTenderType() method of an ADO returns a constant defined in the com._360commerce.pos.ado.tender.TenderTypeEnum class. Every ADO has a constant which depicts its type, hard coded in it. This value is returned by the getTenderType() method.

The validate() Method

This method is used to perform tender specific validation on the RDO. public void validate() throws TenderException { //If the tender is valid, this function exits //without incident. Otherwise, a TenderException //is thrown. }

TENDER GROUPS
Every ADO belongs to a particular Tender Group Tender Group code takes extraneous manager/technician code out of the Tour code to more strongly enforce the MVC pattern Tender Group contains parameters and methods that are used by several tender types

Tender Groups Often, several tender types make use of the same parameters. Tender Groups are the ideal objects for these methods because they can deal with the ADOs directly

TENDER GROUP FUNCTIONS

public void validateLimits(HashMap tenderAttributes, CurrencyIfc balanceDue); public TenderTypeEnum getGroupType(); public TenderTypeEnum getVoidType(); public EYSDomainIfc toLegacy(); public EYSDomainIfc toLegacy(Class type); public void fromLegacy(EYSDomainIfc rdo);

TENDER GROUP FUNCTIONS

Tender Group objects have many common methods, such as the following:
validateLimits(): Checks to see whether the tender type referred to is within limits. The limit values are taken from the preset parameters. getGroupType()/getVoidType(): Returns the constant that tells which group type is being dealt with.

Whenever a tour is launched, the RDO is converted into its corresponding ADO. The following methods are used for this purpose:
toLegacy(): Returns the RDO from the tenderRDO attribute of the ADO. fromLegacy(): Accepts an RDO as a parameter, which it then uses to build the ADO

Data of the RDO is stored as a hash table in the ADO.

Tender Group Code

Public class TenderGroupMineADO extends AbstractTenderGroupADO implements TenderGroupMineIfc { public void validateLimits(HashMap tenderAttributes, CurrencyIfc balanceDue) throws TenderException { if(evaluateTenderLimits == Boolean.TRUE) { //evaluation code goes here //throw exception if the tender is invalid } else { evaluateTenderLimits = Boolean.TRUE; } } //more code here }

Here, the validateLimits() method is implemented, which looks up parameters for the group and throws an exception if the amount of the tender falls outside those bounds.

TOUR DATA OBJECTS

Tour Data Objects holds the information about a particular tour. This information can be used in multiple sites in a tour. Utilizing these objects make refactoring and customizing the tour very simple, we can enable or disable the buttons using them.

TENDER ATTRIBUTES
ADOs have setTenderAttributes() and getTenderAttributes() methods. Both these methods work with Hashmaps containing all the information necessary to create an ADO. Cargo also contains tender attribute hashmap. TenderCargo cargo = (TenderCargo)bus.getCargo(); HashMap tenderAttributes = cargo.getTenderAttributes(); tenderAttributes.put(TenderConstants.TENDE R_TYPE, TenderTypeEnum.MYTYPE);

TENDER ATTRIBUTES
DataInputBeanModel model = (DataInputBeanModel)ui.getModel(SCREEN_C ONSTANT); Hashmap tenderAttributes = cargo.getTenderAttributes(); tenderAttributes.put(TenderConstants.TENDER_T YPE, TenderTypeEnum.TYPE); tenderAttributes.put(TenderConstants.ACCOUNT_ NUMBER, model.getValue(myID)); cargo.setTenderAttributes(tenderAttributes);

TENDERADO CREATION
TenderCargo cargo = (TenderCargo)bus.getCargo(); HashMap tenderAttributes = cargo.getTenderAttributes(); TenderADOIfc myTender = null; try { TenderFactoryIfc factory = (TenderFactoryIfc)ADOFactoryComplex .getFactory(factory.tender); myTender = factory.createTender(tenderAttributes); } catch(ADOException adoe) { adoe.printStackTrace(); }

SOME MORE INFO ON RDO

Tour code gets RDO instance from a factory. If RDO is needed at more than one Tour element, then the RDO is stored on the cargo.

BASIC QUESTIONS
What is an RDO? What is an ADO? What is the relationship between RDOs and ADOs? What is a TDO? What code do you write to obtain an instance of an RDO?