♥♦ Part 1: Badly designed Java classes & interfaces

4 Part practical design concept series

Part 1: Abstraction | Part 2: Single Responsibility Principle | Part 3: Open Close Principle | Part 4: Dependency Inversion Principle.

Q. Can you review the following code and discuss why they are not properly designed. How will you go about improving the design?

The Restaurant class uses the above classes as shown below.

A. The above classes are badly designed for the reasons described below.

  • The name should be an attribute, and not a class like Bob or Jane. A good OO design should hide non-essential details through abstraction. If the restaurant employs more persons, you don’t want the system to be inflexible and create new classes like Peter, Jason, etc for every new employee.
  • The above solution’s incorrect usage of the interfaces for the job roles like Waiter, Manager, etc will make your classes very rigid and tightly coupled by requiring static structural changes. What if Bob becomes a full-time manager? You will have to remove the interface Waiter from the class Bob. What if Jane becomes a manager? You will have to change the interface Waiter with Manager.

The above drawbacks in the design can be fixed as shown below by asking the right questions. Basically waiter, manager, etc are roles an employee plays. You can abstract it out as shown below.

The Employee class defines the employee name as an attribute as opposed to a class. This makes the design flexible as new employees can be added at run time by instantiating new Employee objects with appropriate names. This is the power of abstraction. You don’t have to create new classes for each new employee. The roles are declared as a list using aggregation (i.e. containment), so that new roles can be added or existing roles can be removed at run time as the roles of employees change. This makes the design more flexible.

The following Restaurant class shows how flexible, extensible, and maintainable the above design is.

4 Part practical design concept series

Part 1: Abstraction | Part 2: Single Responsibility Principle | Part 3: Open Close Principle | Part 4: Dependency Inversion Principle.

Print Friendly
The following two tabs change content below.
Arulkumaran Kumaraswamipillai
Mechanical Engineering to Java freelancer since 2003. Published Java/JEE books via Amazon.com in 2005, and sold 35K+ copies. Books are outdated and replaced with this online Java training. join my LinkedIn group.
Arulkumaran Kumaraswamipillai

Mechanical Engineering to Java freelancer since 2003. Published Java/JEE books via Amazon.com in 2005, and sold 35K+ copies. Books are outdated and replaced with this online Java training. join my LinkedIn group.

Posted in Designing your classes & interfaces
Tags: ,

800+ Interview Q&As with lots of diagrams & code ♥Free | ♦FAQs | Hover/Slide for full text

open all | close all

200+ Java Interview FAQs – Quick Prep

open all | close all

16 Java Key Areas to be a top-notch

open all | close all

80+ Java Tutorials – Step by step

open all | close all

100+ Java Coding Exercises

open all | close all

How good are your

open all | close all