Introduction

Robert L. Glass argued that practice precedes theory. Especially in software development, practice is a field where practice precedes theory. Developers gain the most by getting their hands dirty, touching concrete code. Therefore, we will put theory and concepts aside for now and take a look at a simple program.

Implementing a Ticket Sales Application

• We are planning a small event to promote the small theater.
  • Event Content: Sending invitations to watch the performance for free to randomly selected audience members.
• We need to separate the audience members who won the event from those who didn't.
  • Event winners: Exchange the invitation for a ticket.
  • Event losers: Purchase a ticket for money.

Practice code: https://github.com/Java-Crew/objects-study/tree/jayon/src/main/java/chapter01/step01

What is the Problem?

Robert Martin explains the three functions that a software module (any element that makes up a program, regardless of size, such as a class, package, or library) should have.

• It works properly during execution.
• It exists for change.
  • Changes should be possible with simple tasks.
• It communicates with the person reading the code.
  • Developers should be able to easily read and understand.

The previous ticket sales application satisfies the first constraint of working properly, but it fails to meet the goals of changeability and communication.

Code that misses the mark

Let's look at why it doesn't meet the communication goal.

• What the enter() method of the Theater class does
  • The theater opens the audience's bag and checks if there is an invitation inside.
  • If there is an invitation in the bag, it tells the salesperson to move the ticket stored in the ticket office into the audience's bag.
  • If there is no invitation in the bag, it takes out the ticket price from the audience's bag, buys the ticket, and puts the ticket in the bag.
• From the audience's perspective, the theater, a third party, has to look through the bag, take money, and put in a ticket.
• From the salesperson's point of view, the theater, a third party, manipulates the value of the tickets and cash in the ticket office without permission.
• Understandable code means code that doesn't deviate much from our expectations. The above theater violates our expectations.
  • Audience members should take out money from their bags themselves and pay the salesperson to receive a ticket.
  • The salesperson should take the ticket directly from the ticket office and give it to the audience. The salesperson should also receive money from the audience and keep it in the ticket office.
• In addition, you need to remember all the details to understand the enter() method.
  • Audience has a Bag.
  • Bag contains cash and a ticket.
  • TiketSellet sells tickets from TicketOffice. There is money and a ticket in TicketOffice.

Code vulnerable to changes

The enter() method assumes 2 conditions.

• The audience always carries a bag to hold cash and an invitation.
• The salesperson sells tickets only at the ticket office.

Then what about the situation below?

• The audience may not have a bag.
• The audience may use a credit card instead of cash.
• The salesperson may sell tickets outside the ticket office.

For example, to meet the first requirement, we need to remove the Audience's Bag object and modify the Theater class's enter() method accordingly. This is because the Theater class is overly dependent on the fact that the audience is carrying a bag and the salesperson is only selling tickets at the ticket office. If any of these details change, we need to modify both the relevant class and the dependent class (ex. Theater).

This is a problem related to dependency between objects, and dependency implies an impact on changes. However, object-oriented design aims to build a community of objects that cooperate while depending on each other, so we need to minimize the dependencies needed to implement the functionality of the application, not just eliminate them.Keep the minimum dependenciesand remove unnecessary dependencies.

High coupling when there are too many dependencies between objectsis said to be high, and the higher the coupling between two objects, the higher the probability that they will change together. Therefore, the goal of design is to create a design that is easy to change by reducing the coupling between objects.

Improving the Design

Theater does not need to know that the audience has a bag and that the salesperson sells tickets at the ticket office. Theater just wants the audience to enter the theater. Therefore, we need to make the audience and salesperson autonomous entities so that the audience can handle the cash and invitations in their bag themselves, and the salesperson can handle the tickets and sales fees in the ticket office themselves.

Let's increase autonomy

Objects that perform only closely related tasks and delegate unrelated tasks to other objects are said to have high cohesion. Creating autonomous objects that handle their own data can reduce coupling and increase cohesion.

Procedural and Object-Oriented

• Procedural Orientation
  • Theater's enter() method is a process, and Audience, TicketSeller, Bag, and TicketOffice are data.
  • The approach of placing processes and data in separate modules is called procedural programming.
  • There is a lot of code that goes against our intuition. (ex. The audience manages their own money and invitations.)
  • It is difficult to narrow down the impact of data changes.
  • Responsibilities are managed centrally. (Theater manages everything)
• Object Orientation
  • The approach of placing data and processes inside the same module is called object-oriented programming.
  • We can write code that matches our intuition.
  • The impact of data changes can be effectively narrowed down through encapsulation.
  • Each object is responsible for itself.
  • 
    

Practice code: https://github.com/Java-Crew/objects-study/tree/jayon/src/main/java/chapter01/step02

It can be further improved.

• The Bag class of the Audience class is still a passive entity dragged around by the Audience class, so we need to make the Bag class an autonomous object.
• The TicketOffice of the TicketSeller class is also managed at will by TicketSeller. We need to make TicketOffice an autonomous object.
  • However, after the change, TicketOffice has an additional coupling with Audience.
  • Design requires careful consideration of trade-offs. In this case, we can agree to make TicketOffice a somewhat passive object to reduce coupling with Audience.

Practice code: https://github.com/Java-Crew/objects-study/tree/jayon/src/main/java/chapter01/step03

That's a lie!

• Even if it is a passive entity in reality, in the world of object orientation, everything becomes an active and autonomous entity.
• It's a good idea to use personification to think of passive objects as entities that laugh, talk, and get angry.

Object-Oriented Design

Why is design necessary?

• Design is the arrangement of code.
• Good design is one that fully performs the functions required today and can smoothly accommodate tomorrow's changes.

Object-Oriented Design

• Changeable code is easy to understand code.
• The object-oriented paradigm helps us write code the way we see the world.
• Objects are autonomous entities that are responsible for their own data.
• Great object-oriented design is a design that appropriately manages dependencies between cooperating objects.

Source

• Objects