# OOP and IF Statements

> It can sometimes be useful to think about what existing concept OOP replaces. References remove arithmetic operations from pointers, structured programming removes unstructured flow control (GOTO statements) from flow control, and OOP removes selection statements such as `if`, `switch`, and `match` that interfere with higher-level modularization. (Written sometime between 2005 and 2007)

It can sometimes be useful to think about what existing concept <OOP> replaces. References remove arithmetic operations from pointers, <structured programming> removes unstructured flow control (<GOTO statements>) from flow control, and OOP removes selection statements such as `if`, `switch`, and `match` that interfere with higher-level modularization. (Written sometime between 2005 and 2007)

## References and Pointer Arithmetic

Pointers in <the C language> are a raw means of addressing that permit arithmetic operations. References in [Java](https://wiki.g15e.com/pages/Java.txt) or <C#> gain advantages such as security, convenience, and <GC> efficiency by constraining arithmetic operations on pointers.

## Structured Programming and the GOTO Statement

<Structured programming> removes the <GOTO statement> from the methods of controlling a program's flow. To generalize by borrowing [Dijkstra](https://wiki.g15e.com/pages/Edsger%20Dijkstra.txt)'s expression, what matters is removing devices that damage a meaningful [programmer-independent coordinate system](https://wiki.g15e.com/pages/Programmer%20independent%20coordinate%20system.txt). According to <structured program theorem>, even without GOTO, flow control can be expressed through a combination of the following three means:

- sequence: simply put, code composed of recursive function calls and returns being executed from top to bottom
- selection: simply put, `if`, `switch`, `match`
- iteration: simply put, `while`, `do`, `until`, `repeat`, `for`

The <GOTO statement> combined with conditional statements is a raw means of flow control, and structured programming gains advantages such as comprehensibility and modularization by constraining it.

## OOP and IF Statements

Some say that OOP replaces structured programming, but that is only about one-third correct. One way to think about it is that, through <subtype polymorphism>, OOP replaces selection among the three flow-control means of structured programming—that is, `if`, `switch`, `match`, and so on.

A conditional statement is, to begin with, a branching selection mechanism, and "selection" means that the code executed afterward differs depending on the value of a particular variable. In an `if` statement, selection is performed according to the `boolean` value of the condition clause, whereas in subtype polymorphism, selection is performed according to the type of the instance receiving the message.

The following is the traditional approach:

```Java
if(mediaType.equals("monitor")) {
	renderToMonitor();
} else if(mediaType.equals("printer")) {
	renderToPrinter();
} else {
	throw new IllegalArgumentException("Unknown media: " + mediaType);
}
```

The following is the approach using subtype polymorphism:

```java
abstract class Media() { void render() }
class Monitor extends Media() { void render() { /* ... */ } }
class Printer extends Media() { void render() { /* ... */ } }

// ...

media.render();
```

Can subtype polymorphism, and the [dependency inversion](https://wiki.g15e.com/en/pages/Dependency%20inversion.txt) that uses it, be an important enough perspective to characterize OOP? Some people argue that it can.

> It doesn't matter what language a program is written in. If its dependencies are inverted, it has an OO design.
>
> --<Robert Cecil Martin>, <Agile software development (book)>

To elaborate so as to avoid misunderstanding, this is not a claim that object-oriented design requires removing every `if`. To quote Martin Fowler's explanation:

> We are not unconditionally opposed to conditional statements. In the first edition of this book (Refactoring), there was a smell called "switch statements." In the late <1990s>, sadly, polymorphism was not yet widely enough recognized, so we considered it beneficial for people to choose polymorphism instead of `switch`. --[Refactoring: Improving the design of existing code](https://wiki.g15e.com/pages/Refactoring%20-%20Improving%20the%20design%20of%20existing%20code.txt)

## Encapsulation and Information Hiding

People usually name polymorphism, encapsulation, and information hiding as the three characteristics of OOP, but can we regard polymorphism as especially more important among them?

All three are important, but since <encapsulation> and <information hiding> are concepts that already existed before OOP, polymorphism is a relatively conspicuous distinguishing feature.

## Must One Remove All ifs to Be True OOP?

There are two things one could say.

- First, "true OOP" is both vague to define and not a value especially worth pursuing.
- Second, what matters is not removing every `if`, but removing `if` statements that hinder higher-level modularization.

The perspective that OOP uses subtype polymorphism to replace `if` statements that hinder higher-level modularization is one of several useful perspectives for understanding OOP.