Object Oriented Software Development

This document discusses the concept of object oriented software development and explores the use of creational design patterns such as builder, prototype, singleton, abstract factory, and factory method. It also explains the proxy pattern and composite pattern in the context of compute price and checkout. The document provides pseudocode examples and class diagrams for better understanding.

Running head: OBJECT ORIENTED SOFTWARE DEVELOPMENT
OBJECT ORIENTED SOFTWARE DEVELOPMENT
Name of the Student:
Name of the University:
Author Note:

1OBJECT ORIENTED SOFTWARE DEVELOPMENT
Table of Contents
Question 1..................................................................................................................................2
Question 2..................................................................................................................................3
Design problem: Compute price............................................................................................3
Design problem: Checkout.....................................................................................................6
References................................................................................................................................10

2OBJECT ORIENTED SOFTWARE DEVELOPMENT
Question 1
Creational design patterns are a type of patterns which are used to design and develop a
software in multiple different ways. The main use of these patterns is to abstract the
instantiation process. The creational pattern design process helps in making the system not
dependent on the object’s creation, representation and composition process. To make new
classes via the creational design patterns, inheritance is used and to instantiate new objects
the authority is delegated. The use of creational patterns become more useful as the
application or the system to be developed evolves slowly and when the system becomes more
dependent on inheritance than object composition. These patterns help in creating small
fundamental behaviours that can be used to design more complex classes. This is something
which is much more than just regular class instantiation. There are five types of creational
design patterns. These are abstract factory, builder, factory method, prototype and singleton.
These are discussed below as follows:
1. Builder: This is one of the creational design patterns that make use of the
construction process of the object by separating the process from the representation so
as to use it to create many representations of the product multiple times over. The
pattern is used when the algorithm that is creating the objects is totally independent of
the parts of the object and its assembling process. The builder pattern is also used
when the construction process of an objects requires multiple representations of the
same object to be permitted. The major consequence of using this pattern is that the
internal representation of the product can be changed by the user. The pattern is also
used when a user wants to have a more subtle control over the object’s construction
process. The pattern is also used to separate the construction process of the object
form its representation process.
2. Prototype: The prototype pattern is used when the same type objects need to be
created for classes and a prototype of the objects is provided so as to speed up the
creation process by just copying the prototype. This pattern is used when the classes
to be instantiated is specified by the class during dynamic loading. The pattern is also
used when the user wants to avoid building a factory hierarchies which parallels the
product hierarchies. The prototype pattern also finds its use when a certain number of
combinations are required by class for its state. The consequence of using this pattern
is that it makes the runtime removal and addition of products easier. It also permits

3OBJECT ORIENTED SOFTWARE DEVELOPMENT
the modifications of values of the objects. Another result of this pattern is that it lets
the user create new objects by changing the structure.
3. Singleton: This pattern is only used when a single instance of a class is needed to be
created along with global access. The pattern helps provide the client with an
individual instance that they can access from common access points. The pattern is
also used to extend the main class of the system with the help of a subclass without
changing the codes. The major consequence of this pattern is that it lets the user have
controlled access to the solo class. It also lets the user create many different instances
of the class. The pattern also helps in reducing the name space of the instances. The
flexibility of the system is increased more than the normal required for class
operations. The pattern also allows for the refinement of operations and representation
of the class.
4. Abstract factory: The pattern allows the creation of an interface which enables the
developer to create multiple families of objects without stating the concrete classes of
those same objects. Kit is another name given to this pattern. The main use of this
pattern is to create an independent system which will work without the composition,
representation and creation of those objects. The pattern is also used when the system
being created must be configured along with the many families of that object. One
main consequence of using this pattern is that it isolates the entire concrete class.
Another consequence is that it helps in exchanging of the families of the product. This
pattern makes the supporting of newer product types harder for the system. The
pattern also helps in increasing the consistency of the products.
5. Factory method: This popular design pattern creates an interface for the object but
shifts the control for the initiation process to its subclass. Virtual constructor is
another name given to this pattern. The main use of this pattern is in scenarios where
the objects to be created are not yet decided by the class. The pattern lets the object to
be created be decided by a subclass. A major consequence of using this pattern is that
it provides placeholders or hooks for the subclasses of the classes. Another
consequence is that using this pattern brings more flexibility to the system.
Question 2
Design problem: Compute price
a. The pattern chosen for this class is the proxy pattern. This pattern is chosen because it
lets the user view or select different items from his cart and their prices without

4OBJECT ORIENTED SOFTWARE DEVELOPMENT
loading all the objects. This makes the application faster and reduces heavy memory
usage.
b. The main components are:
1. Proxy (Image proxy)
2. Subject (Graphic)
3. Real Subject (Image)
c. The two main benefits of using this pattern:
1. It can be used to control the access to a given object by using a proxy to protect it.
2. This pattern lets a placeholder be placed in place of a real object until the real
object is called for or required.
d. The two security features of this class are:
1. Limited view:
Merit: This security pattern will help smoothen the compute price process as only
the items selected by the user will be visible.
Demerit: This operation cannot be used in scenarios where user need to perform a
lot of operations.
2. Pathname canonicalization:
Merit: This pattern makes sure that the links or connections to other pages in the
applications are valid and non-clustered.
Demerit: The user must know the pages he wants to traverse to use this pattern.
JAVA complete class pseudocode:
Interface of total price:
package com. proxy;
public interface Total price
{
public void totalbill();
}
Real total price.java
package com.proxy;
public class RealTotalprice implements Totalprice

5OBJECT ORIENTED SOFTWARE DEVELOPMENT
{
@Override
public void Totalbill()
{
System.out.println("your total bill is” +bill);
}
}
Proxy total price.java
package com.proxy;
public class Proxytotalprice implements totalprice
{
private Proxytotalprice totalprice = new totalbill();
@Override
public void Totalbill()
{
System.out.println("your total bill is” +bill);
}
}

6OBJECT ORIENTED SOFTWARE DEVELOPMENT
Figure 1 Compute price class diagram (Source: created by author)
Design problem: Checkout
a. The pattern chosen for this class is the composite pattern. This pattern is perfect for
this class because the checkout process has many subparts which can be categorised
in a tree structure as per hierarchy or use flow.
b. The main components are:
1. Component (Graphic)
2. Leaf (rectangle, line, text, etc)
3. Composite (Picture)
4. Client
c. The main benefits are:
1. It helps in defining class hierarchies that includes complex and primitive objects.

7OBJECT ORIENTED SOFTWARE DEVELOPMENT
2. It makes the job of adding new components to the system smoother and easier.
d. The two security patterns are:
1. Secure state machine:
Merit: The pattern helps in separating the user functions of the applications from
the security functions making it easier for developers to design the system.
Demerit: All types of functionalities of the system must be defined beforehand for
this pattern.
2. Single access point:
Merit: This pattern makes a single access point or website for all users to access
the application and prevents duplication.
Demerit: This pattern sometimes forces the user to enter unnecessary information
not required for his current session.
JAVA complete class pseudocode
INTERFACE
public interface Payment
{
public void showPaymentDetails();
}
LEAF
public class receipt implements payment
{
Int customer_ID;
String customer_details;
String Product_names;
Int Product_subtotal;
Int Total_bill;
public receipt(Int customer_ID, String customer_details, String Product_names, Int
Product_subtotal, Int Total_bill)

8OBJECT ORIENTED SOFTWARE DEVELOPMENT
{
……….
}
@Override
public void showreceipt()
{
System.out.println(“receipt”);
}
}
COMPONENT
public class totalprice implements payment
{
@Override
public void totalbill()
{
………
}
}

9OBJECT ORIENTED SOFTWARE DEVELOPMENT
Figure 2 Checkout class diagram (Source: created by author)

10OBJECT ORIENTED SOFTWARE DEVELOPMENT
References
Beck, K., Beedle, M., Van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., ... &
Kern, J. (2001). Manifesto for agile software development.
Bresciani, P., Perini, A., Giorgini, P., Giunchiglia, F., & Mylopoulos, J. (2004). Tropos: An
agent-oriented software development methodology. Autonomous Agents and Multi-
Agent Systems, 8(3), 203-236.
Bruegge, B., & Dutoit, A. H. (2009). Object-‐Oriented Software Engineering. Using UML,
Patterns, and Java. Learning, 5(6), 7.
Gamma, E. (1995). Design patterns: elements of reusable object-oriented software. Pearson
Education India.
Gomez-Sanz, J. J., & Fuentes-Fernández, R. (2015). Understanding agent-oriented software
engineering methodologies. The Knowledge Engineering Review, 30(4), 375-393.
Padhy, N., Singh, R. P., & Satapathy, S. C. (2018). Utility of an object-oriented metrics
component: Examining the feasibility of. Net and C# object-oriented program from
the perspective of mobile learning. International Journal of Mobile Learning and
Organisation, 12(3), 263-279.
Pree, W., & Gamma, E. (1995). Design patterns for object-oriented software
development (Vol. 183). Reading, MA: Addison-wesley.
Sahoo, A., Kung, D., & Gupta, S. (2016). An Agile Methodology for Reengineering Object-
Oriented Software. In SEKE (pp. 638-643).
Smith, B. (2011). Object-oriented programming. In AdvancED ActionScript 3.0: Design
Patterns (pp. 1-25). Apress.
Wirfs-Brock, R., Wilkerson, B., & Wiener, L. (1990). Designing object-oriented software.