Object oriented design for a Restaurant

Let we start to design Object Oriented architecture of restaurant. Before start the design, we need to understand how a restaurant works.

Components required:

Customer

            Name

            Contact

selectDish(): Dish

Selects the dish from the menu.

callWaiter(): call upon a waiter.

placeOrder(d:Dish): Places the order and enjoy his meal once the dish is served on his table.

requestBill(): Ask for the bill to the waiter.

makePayment(): Pays for the services.

Waiter

            Name

            EmpId

            TableToWait

respondToCustomer(): Response to the customer’s calls on the tables he is waiting.

takeOrder(): Take the customer's order.

placeOrderToQueue(o:Order): Place the order in PendingOrderQueue.

handleOrderPreparedNotification(): Observer design pattern for notification

Wait for the order ready notifications.

serveDishToCustomer(d:Dish): Once notification is received, collects the dish and serves the dish to the corresponding customer.

takeBillRequest(): Receive the bill request from the customer.

acceptPayment(): Ask the Cashier to prepare the bill.

payMoneyToCashier(): Gives the bill to the customer and accepts the payment.

Chef

            EmpId

prepareDish(d:Dish): Get the next order from the PendingOrderQueue.

placeOrderInFinishedQueue(): Prepares the dish and push the order to finished order queue.

notifyOrderComplete(): Observer design pattern for notification

Send a notification that the order is ready.

Cashier

            Name

            EmpId

prepareBill(o:Order): Accepts the prepare bill request from the waiter for the given order details. Prepares the bills and hands it over to the waiter.

acceptPayment(): Accept the cash from the waiter towards the order.

Order (DTO)

            id

            Dish

Data structure used:

PendingOrderQueue

addOrder(o:Order): Waiter will place the order in the PendingOrderQueue.

getNextOrder(): Chef gets the next order from the PendingOrderQueue.

FinishedOrderQueue

getFinishedOrder(o:Order): Chef will prepare the dish and push the order to FinishedOrderQueue. 

Open Closed Design Principle

In Design principle, SOLID – the "O" in "SOLID" stands for the open/closed principle.

Open Closed principle is a design principle which says that a class, modules and functions should be open for extension but closed for modification.

This principle states that the design and writing of the code should be done in a way that new functionality should be added with minimum changes in the existing code (tested code). The design should be done in a way to allow the adding of new functionality as new classes, keeping as much as possible existing code unchanged.

Benefit of Open Closed Design Principle:

1) Application will be more robust because we are not changing already tested class.

2) Flexible because we can easily accommodate new requirements.

3) Easy to test and less error prone.

OOPs Concepts

A methodology or paradigm to design a program using classes and objects.

Object Oriented programming is a programming methodology that is associated with the concept of Class.

Objects and various other concepts revovling around these like Inheritance, Polymorphism, Abstraction, Encapsulation etc.

Abstraction

Hiding internal details and showing functionality is known as abstraction. Abstract class and interface can be used to achieve abstraction.

Example: watching TV, we don't know the internal processing.

Encapsulation

Binding (or wrapping) code and data together into a single unit is known as encapsulation.

Example: capsule, it is wrapped with different medicines.

A java class is the example of encapsulation. Java bean is the fully encapsulated class because all the data members are private here.

Advantage of OOPs over Procedure-oriented programming language

1)OOPs makes development and maintenance easier where as it is not easy to manage the projects if code grows as project size grows.

2)OOPs provides data hiding whereas in Procedure-oriented programming language a global data can be accessed from anywhere.

3)OOPs provides ability to simulate real-world event much more effectively.

Design Principle vs.Design Pattern

Object Oriented Programming

OOP is a programming paradigm that represents concepts as “objects” that have data fields (attributes that describe the object) and associated methods. Objects (instances of classes) are used to interact with one another to design applications and computer programs.

OO basics principles:

Polymorphism

Abstraction

Encapsulation

Inheritance

Design Principles:

Design principles are core abstract principles which we are supposed to follow while designing software architect. Remember they aren't concrete; rather abstract.

OO principle is a set of guidelines that ensures OOP concept.Based on the OOP concept, this defines ways to design better way, a better design.

Examples:

1. Single Responsibility Principle

2. Open Close Principle

3. Liskov’s Substitution Principle

4. Interface Segregation Principle

5. Dependency Inversion Principle

Design Patterns:

They are solutions to real world problems that pop up time and again, so instead of reinventing the wheel, we follow the design patterns that are well-proven, tested by others, and safe to follow. Now, design patterns are specific, there are terms and conditions only in which they can be applied.

OO design patterns (OODPs) are those which provide a general solution to object oriented design based OO principle.

Design patterns are discovered, not invented.

Examples:

Singleton Pattern

Factory pattern.

Difference between Singleton Pattern vs Static Class in Java

The big difference between a singleton and a bunch of static methods is that singletons can implement interfaces (or derive from useful base classes), so you can pass around the singleton as if it were "just another" implementation.

Static class:

Static class can not be a top level class and can not implement the interface.
It provides better performance than Singleton pattern, because static methods are bonded on compile time.

Static class always provides the eagerly loaded however Singleton classes can be lazy loaded if it’s a heavy object.

Singleton objects:

It stored on heap while static class stored in stack.

It can have constructor while static class cannot.

It can dispose but not static class.

It can clone but not with static class (logically wrong to clone the Singleton objects).

Difference between Singleton Pattern vs Static Class in Java

The big difference between a singleton and a bunch of static methods is that singletons can implement interfaces (or derive from useful base classes), so you can pass around the singleton as if it were "just another" implementation.

Static class:

Static class provides better performance than Singleton pattern, because static methods are bonded on compile time.

Static class always provides the eagerly loaded however Singleton classes can be lazy loaded if it’s a heavy object.

Singleton Objects:

Singleton Objects stored on heap while static class stored in stack.

Singleton Objects can have constructor while Static Class cannot.

Singleton Objects can dispose but not static class.

Singleton Objects can clone but not with static class (logically wrong to clone the Singleton objects).

Difference between Abstraction and Encapsulation in Java

Abstraction - hiding implementation using abstract class and interfaces etc.

Abstraction represent taking out the behavior from how exactly it’s implemented.

Example: Abstraction in Java is interface.

Encapsulation - data hiding

While Encapsulation means hiding details of implementation from outside world so that when things change nobody gets affected.

Example: Java is private methods.

Difference between Abstraction and Encapsulation in Java

Abstraction - hiding implementation using abstract class and interfaces etc.

Abstraction represent taking out the behavior from how exactly it’s implemented.

Example: Abstraction in Java is interface.

Encapsulation - data hiding

While Encapsulation means hiding details of implementation from outside world so that when things change nobody gets affected.

Example: Java is private methods.

5 Class Design Principles in Java

[S.O.L.I.D.]
The 5 Class Design Principles

S.O.L.I.D is the acronym for five basic principles of object-oriented programming to design a class.

Single responsibility

Open-closed

Liskov substitution

Interface segregation and

Dependency inversion.

S.O.L.I.D principles help us to create a system that is easy to maintain and extend over time. Well designed and written classes can speed up the coding process by leaps and bounds, while reducing the number of bugs in comparison.

Classes are the building blocks of System. If these blocks are not strong, your building (i.e. System) is going to face the tough time in future.

If Classes are not so well-written, can lead to very difficult situations when the application scope goes up or application faces certain design issues either in production or maintenance.

It is part of an overall strategy of agile and Adaptive Software Development.

S	Single responsibility principle	“a class should have only a single responsibility” (i.e. only one potential change in the software's specification should be able to affect the specification of the class)
O	Open/closed principle	“software entities … should be open for extension, but closed for modification.”
L	Liskov substitution principle	“objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.”
I	Interface segregation principle	“many client-specific interfaces are better than one general-purpose interface.”
D	Dependency inversion principle	one should “Depend upon Abstractions. Do not depend upon concretions.”

Introduced by Michael Feathers for the "first five principles" named by Robert C. Martin in the early 2000s.

Why interface cannot have instance variables?

Interface variables are static final because Java interfaces cannot be instantiated in their own right; the value of the variable must be assigned in a static context in which no instance exists. The final modifier ensures the value assigned to the interface variable is a true constant that cannot be re-assigned by program code.