using files in java
where we have Three classes are given to you,
CabCustomer
CabCustomerService
CabCustomerServiceTester
Define the following in the class CabCustomer
private : custId int, customerName String, pickupLocation String,dropLocation String, distance int,phone long
Generate Getter/Setter for the all fields.
Implement the default constructor.
Generate the parameterized constructor in the order to initialize the data members of a class custId,Name,Pickup,Drop,Distance,Phone
Define the following in the class CabCustomerService and write logics in the following methods:
private : Generic ArrayList to represent list of CabCustomers.
addCabCustomer() :
Description :Add the customer object parameter to the ArrayList
Method name: addCabCustomer()
Return Type :void
Arguments: one of type CabCustomer
isFirstCustomer():
Description : Check whether the customer object parameter is already existing in arrayList.
Method Name:isFirstCustomer()
Return Type: boolean
Arguments: one of type CabCustomer
Note : If phone number of a customer matches with any of the phone numbers of the array list, then consider it as a existing customer, otherwise consider
the customer as new customer.
calculateBill():
Method Name :calculateBill()
Argument: CabCustomer
Return Type :double
Description: method should calculate and return the customer bill based on following rules
1) if the customer is new return 0.0;
2) if the customer's travel distance is below or equal
to 4 kms then return 80.00 (Rs).
3) if the customer travel distance is above 4 kms calculate bill 80 + 6 per each km.
Ex: Any distance for new customer return 0;
distance 4 return 80
distance 6 return 80 + (2 * 6);
printBill():
Description: which should return the bill of the customer object parameter in the following format:
output : JOHN Please pay your bill of Rs.0.0
SMITH Please pay your bill of Rs.180.0
Note :
Assume one customer books only one cab at a time.
No charge for customer booking the cab for the first time.
Customer's phone number is key to test a new customer or old customer.
Distance should be treated as kilometers
A class CabCustomerServiceTester is given with main() where you can create various objects and test them
Answers
Answer:
apna ap kar le ok answer
Visitor Design Pattern
Intent
Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates.
The classic technique for recovering lost type information.
Do the right thing based on the type of two objects.
Double dispatch
Problem
Many distinct and unrelated operations need to be performed on node objects in a heterogeneous aggregate structure. You want to avoid "polluting" the node classes with these operations. And, you don't want to have to query the type of each node and cast the pointer to the correct type before performing the desired operation.
Discussion
Visitor's primary purpose is to abstract functionality that can be applied to an aggregate hierarchy of "element" objects. The approach encourages designing lightweight Element classes - because processing functionality is removed from their list of responsibilities. New functionality can easily be added to the original inheritance hierarchy by creating a new Visitor subclass.
Visitor implements "double dispatch". OO messages routinely manifest "single dispatch" - the operation that is executed depends on: the name of the request, and the type of the receiver. In "double dispatch", the operation executed depends on: the name of the request, and the type of TWO receivers (the type of the Visitor and the type of the element it visits).
The implementation proceeds as follows. Create a Visitor class hierarchy that defines a pure virtual visit() method in the abstract base class for each concrete derived class in the aggregate node hierarchy. Each visit() method accepts a single argument - a pointer or reference to an original Element derived class.
Each operation to be supported is modelled with a concrete derived class of the Visitor hierarchy. The visit() methods declared in the Visitor base class are now defined in each derived subclass by allocating the "type query and cast" code in the original implementation to the appropriate overloaded visit() method.
Add a single pure virtual accept() method to the base class of the Element hierarchy. accept() is defined to receive a single argument - a pointer or reference to the abstract base class of the Visitor hierarchy.
Each concrete derived class of the Element hierarchy implements the accept() method by simply calling the visit() method on the concrete derived instance of the Visitor hierarchy that it was passed, passing its "this" pointer as the sole argument.
Everything for "elements" and "visitors" is now set-up. When the client needs an operation to be performed, (s)he creates an instance of the Visitor object, calls the accept() method on each Element object, and passes the Visitor object.
The accept() method causes flow of control to find the correct Element subclass. Then when the visit() method is invoked, flow of control is vectored to the correct Visitor subclass. accept() dispatch plus visit() dispatch equals double dispatch.
The Visitor pattern makes adding new operations (or utilities) easy - simply add a new Visitor derived class. But, if the subclasses in the aggregate node hierarchy are not stable, keeping the Visitor subclasses in sync requires a prohibitive amount of effort.
An acknowledged objection to the Visitor pattern is that is represents a regression to functional decomposition - separate the algorithms from the data structures. While this is a legitimate interpretation, perhaps a better perspective/rationale is the goal of promoting non-traditional behavior to full object status.