Starting from:
$30
BBM104-Experiment 4 Delivery System Solved
The aim of this is to introduce you object-oriented programming and design with Java. You will learn the structure of a class, how classes interact, inheritance and polymorphism and basic input-output operations in Java. There will be two main parts to this assignment. One part consists of creating the system’s input-output interface and implementing the logic for this interaction. The other part is defining (and implementing) the persistence backend (i.e. how we store and retrieve the information our system uses). You should also use decorator design pattern in first part of the experiment. Your homework will take commands from an input file then it will print the results of these commands to an output file. You should use Data Access Objects (DAO) to manage your data.
Decorator Pattern:
The Java language provides the keyword extends for subclassing a class. Those with enough knowledge of object-oriented programming know how powerful subclassing, or extending a class. By extending a class, you can change its behavior. The Decorator Pattern is used for adding additional functionality to a particular object as opposed to a class of objects. With the Decorator Pattern, you can add functionality to a single object and leave others like it unmodified. Any calls that the decorator gets, it relays to the object that it contains, and adds its own functionality along the way, either before or after the call. This gives you a lot of flexibility since you can change what the decorator does at runtime, as opposed to having the change be static and determined at compile time by subclassing. Since a Decorator complies with the interface that the object that it contains, the Decorator is indistinguishable from the object that it contains. That is, a Decorator is a concrete instance of the abstract class, and thus is indistinguishable from any other concrete instance, including other decorators. This can be used to great advantage, as you can recursively nest decorators without any other objects being able to tell the difference, allowing a near infinite amount of customization.
Decorators add the ability to dynamically alter the behavior of an object because a decorator can be added or removed from an object without the client realizing that anything changed. It is a good idea to use a Decorator in a situation where you want to change the behavior of an object repeatedly (by adding and subtracting functionality) during runtime.
The dynamic behavior modification capability also means that decorators are useful for adapting objects to new situations without re-writing the original object's code.
The code for a decorator would something like this:
void operation {
// any pre-processing code goes here component.operation() // delegate to the decor
// any post-processing code goes here
}
Note that the decorator can opt to not delegate to the decor, if, for instance, some condition was not met.
Data Access Object
The Data Access Object (DAO) layer is an essential part of good application architecture. Business applications almost always need access to data from databases or data files. The Data Access Object design pattern provides a technique for separating object persistence (stored data) and data access logic from any particular persistence mechanism (writing to files or accessing a real database). There are clear benefits to this approach from an architectural perspective. The Data Access Object approach provides flexibility to change an application's persistence mechanism over time without the need to re-engineer application logic that interacts with the Data Access Object tier. The Data Access Object design pattern also provides a simple, consistent API for data access that does not require knowledge of sub mechanism. A typical Data Access Object interface is shown below. (This is an example, your interface should look like different )
public interface CustomerDAO { public void add(Customer customer);
public void update(int id, Customer customer);
public void delete(int id);
public Customer[] getAll();
……………..
}
Experiment:
In this experiment, you are expected to develop a simple Pizza Restaurant System. Your application should support the following features:
New Customer:
Create a new customer. Attributes of a customer are:
• Customer id (Unique)
• Customer Surname
• Customer Name
• Customer Address
• Customer Phone Number
Remove Customer:
Remove a customer from the database by using its identification number.
List Customers:
Print the list of customers ordered by name.
Create Order:
Create a new order for an existing customer and append it to order data file. Each order has a unique order id.
Add Pizza:
Add a pizza to a given order with given toppings. A pizza can include 3 toppings at most. There are 2 types of pizzas. These are:
• American Pan Pizza 5 $
• Neapolitan Pizza 10 $
A pizza can include 3 toppings at most. There are 4 types of toppings. Soudjouk 3 $
• Salami 3 $
• Pepper 1 $
• Onion 2 $
Add Drink:
Add a soft drink to an order (2$). There is the only cola in this restaurant.
Pay Check
Calculate the paycheck of an order. List all pizzas and drinks in the order then calculate the total cost of an order.
Customer information and order information will be stored in text files (lists or arrays will also be accepted). The format of the files for persistence are shown below. Names of these files will be taken as arguments in your application. You can reach sample customer file, order data file and sample input-output files from the page of piazza site of the experiment.
Customer Data File Format
<customerID <customerName <customerSurname <phone number Address: <address
Customer name, surname, and phone number consist of one string. The address can be made up of one or more strings. Entries in customer data file should be ordered by ID.
Order Data File Format
Order: <orderID <customerID
<pizza type (Neapolitan or American Pan) <topping [1-3] (There can be 3 toppings at most)
<drink
Entries in order data file should be ordered by ID. After add and remove operations, all changes should be reflected data files.
Input File Format (Note: Number of topping can vary from 1 to 3.)
Ø AddCustomer <cutomerID <name <surname <phone number <address
Ø RemoveCustomer <cutomer ID
Ø CreateOrder <OrderID <CustomerID
Ø RemoveOrder <OrderID
Ø AddPizza <OrderID <pizza type <topping
Ø AddDrink <OrderID
Ø PayCheck <OrderID
Ø ListCustomers
Output File Format
Ø Customer <CustomerID <name added
Ø Customer <CustomerID <name removed
Ø Order <OrderID created
Ø <pizza type pizza added to order <OrderID
Ø Drink added to order <OrderID
Ø PayCheck for order <OrderID
ü <pizza type <topping[1-4] <cost $
ü <pizza type <topping[1-4] <cost $
ü SoftDrink <cost $
ü Total: <total_cost $
Implementation Details:
You should use decorator pattern for add topping mechanism. Add topping code should look like this:
pizza.addTopping(new Salami(new HotPepper(new Soudjuk())); This a pizza with salami, hot pepper, and soudjouk.
pizza.printToppings(); Output of this method call should be Soudjuk HotPepper Salami
pizza.cost(); Output of this method call should return the costs of pizza and its toppings
The advantage of using data access objects is the relatively simple and rigorous separation between two important parts of an application which can and should know almost nothing of each other, and which can be expected to evolve frequently and independently. Changing business logic can rely on the same DAO interface, while changes to persistence logic do not affect DAO clients as long as the interface remains correctly implemented. In the specific context of the Java programming language, Data Access Objects as a design concept can be implemented in a number of ways. This can range from a fairly simple interface that separates the data access parts from the application logic to frameworks and commercial products. DAO coding paradigms can require some skill.
For our system, we will store the data inside the individual files (one for order and one for customer class), and use Data Access Objects (DAO) to manage them (10points). Each DAO will have the basic operations to manage the data (defined by the DAO interface provided with the assignment). So basically what you need to do is implementing following abstract methods:
Object getByID(int ID) // read a single entry from the file Object deleteByID(int ID) // delete a single entry from file void add(Object object) // add or update an entry void update(Object object) // add or update an entry
ArrayList getALL() // get all entries
You could add additional methods to your DAOs and you can also make changes in DAO interface. Your application should terminate and save the files automatically when finish to reading input
Decorator Pattern:
The Java language provides the keyword extends for subclassing a class. Those with enough knowledge of object-oriented programming know how powerful subclassing, or extending a class. By extending a class, you can change its behavior. The Decorator Pattern is used for adding additional functionality to a particular object as opposed to a class of objects. With the Decorator Pattern, you can add functionality to a single object and leave others like it unmodified. Any calls that the decorator gets, it relays to the object that it contains, and adds its own functionality along the way, either before or after the call. This gives you a lot of flexibility since you can change what the decorator does at runtime, as opposed to having the change be static and determined at compile time by subclassing. Since a Decorator complies with the interface that the object that it contains, the Decorator is indistinguishable from the object that it contains. That is, a Decorator is a concrete instance of the abstract class, and thus is indistinguishable from any other concrete instance, including other decorators. This can be used to great advantage, as you can recursively nest decorators without any other objects being able to tell the difference, allowing a near infinite amount of customization.
Decorators add the ability to dynamically alter the behavior of an object because a decorator can be added or removed from an object without the client realizing that anything changed. It is a good idea to use a Decorator in a situation where you want to change the behavior of an object repeatedly (by adding and subtracting functionality) during runtime.
The dynamic behavior modification capability also means that decorators are useful for adapting objects to new situations without re-writing the original object's code.
The code for a decorator would something like this:
void operation {
// any pre-processing code goes here component.operation() // delegate to the decor
// any post-processing code goes here
}
Note that the decorator can opt to not delegate to the decor, if, for instance, some condition was not met.
Data Access Object
The Data Access Object (DAO) layer is an essential part of good application architecture. Business applications almost always need access to data from databases or data files. The Data Access Object design pattern provides a technique for separating object persistence (stored data) and data access logic from any particular persistence mechanism (writing to files or accessing a real database). There are clear benefits to this approach from an architectural perspective. The Data Access Object approach provides flexibility to change an application's persistence mechanism over time without the need to re-engineer application logic that interacts with the Data Access Object tier. The Data Access Object design pattern also provides a simple, consistent API for data access that does not require knowledge of sub mechanism. A typical Data Access Object interface is shown below. (This is an example, your interface should look like different )
public interface CustomerDAO { public void add(Customer customer);
public void update(int id, Customer customer);
public void delete(int id);
public Customer[] getAll();
……………..
}
Experiment:
In this experiment, you are expected to develop a simple Pizza Restaurant System. Your application should support the following features:
New Customer:
Create a new customer. Attributes of a customer are:
• Customer id (Unique)
• Customer Surname
• Customer Name
• Customer Address
• Customer Phone Number
Remove Customer:
Remove a customer from the database by using its identification number.
List Customers:
Print the list of customers ordered by name.
Create Order:
Create a new order for an existing customer and append it to order data file. Each order has a unique order id.
Add Pizza:
Add a pizza to a given order with given toppings. A pizza can include 3 toppings at most. There are 2 types of pizzas. These are:
• American Pan Pizza 5 $
• Neapolitan Pizza 10 $
A pizza can include 3 toppings at most. There are 4 types of toppings. Soudjouk 3 $
• Salami 3 $
• Pepper 1 $
• Onion 2 $
Add Drink:
Add a soft drink to an order (2$). There is the only cola in this restaurant.
Pay Check
Calculate the paycheck of an order. List all pizzas and drinks in the order then calculate the total cost of an order.
Customer information and order information will be stored in text files (lists or arrays will also be accepted). The format of the files for persistence are shown below. Names of these files will be taken as arguments in your application. You can reach sample customer file, order data file and sample input-output files from the page of piazza site of the experiment.
Customer Data File Format
<customerID <customerName <customerSurname <phone number Address: <address
Customer name, surname, and phone number consist of one string. The address can be made up of one or more strings. Entries in customer data file should be ordered by ID.
Order Data File Format
Order: <orderID <customerID
<pizza type (Neapolitan or American Pan) <topping [1-3] (There can be 3 toppings at most)
<drink
Entries in order data file should be ordered by ID. After add and remove operations, all changes should be reflected data files.
Input File Format (Note: Number of topping can vary from 1 to 3.)
Ø AddCustomer <cutomerID <name <surname <phone number <address
Ø RemoveCustomer <cutomer ID
Ø CreateOrder <OrderID <CustomerID
Ø RemoveOrder <OrderID
Ø AddPizza <OrderID <pizza type <topping
Ø AddDrink <OrderID
Ø PayCheck <OrderID
Ø ListCustomers
Output File Format
Ø Customer <CustomerID <name added
Ø Customer <CustomerID <name removed
Ø Order <OrderID created
Ø <pizza type pizza added to order <OrderID
Ø Drink added to order <OrderID
Ø PayCheck for order <OrderID
ü <pizza type <topping[1-4] <cost $
ü <pizza type <topping[1-4] <cost $
ü SoftDrink <cost $
ü Total: <total_cost $
Implementation Details:
You should use decorator pattern for add topping mechanism. Add topping code should look like this:
pizza.addTopping(new Salami(new HotPepper(new Soudjuk())); This a pizza with salami, hot pepper, and soudjouk.
pizza.printToppings(); Output of this method call should be Soudjuk HotPepper Salami
pizza.cost(); Output of this method call should return the costs of pizza and its toppings
The advantage of using data access objects is the relatively simple and rigorous separation between two important parts of an application which can and should know almost nothing of each other, and which can be expected to evolve frequently and independently. Changing business logic can rely on the same DAO interface, while changes to persistence logic do not affect DAO clients as long as the interface remains correctly implemented. In the specific context of the Java programming language, Data Access Objects as a design concept can be implemented in a number of ways. This can range from a fairly simple interface that separates the data access parts from the application logic to frameworks and commercial products. DAO coding paradigms can require some skill.
For our system, we will store the data inside the individual files (one for order and one for customer class), and use Data Access Objects (DAO) to manage them (10points). Each DAO will have the basic operations to manage the data (defined by the DAO interface provided with the assignment). So basically what you need to do is implementing following abstract methods:
Object getByID(int ID) // read a single entry from the file Object deleteByID(int ID) // delete a single entry from file void add(Object object) // add or update an entry void update(Object object) // add or update an entry
ArrayList getALL() // get all entries
You could add additional methods to your DAOs and you can also make changes in DAO interface. Your application should terminate and save the files automatically when finish to reading input
1 file (7.9KB)
