[프로그래밍 패러다임] 2. 객체지향 프로그래밍

객체지향 프로그래밍 (OOP)

• 객체들의 집합으로 프로그램의 상호작용을 표현하며, 데이터를 객체로 취급하여 객체 내부에 선언된 메서드를 활용하는 방식
• 설계에 많은 시간 소요 & 처리속도가 다른 패러다임에 비해 상대적으로 느림
• 예시) 자연수로 이루어진 배열에서 최댓값을 찾는 로직
  • List라는 클래스를 만들고 a라는 객체를 만들 때 최댓값을 추출해내는 메서드

const ret = [1, 2, 3, 4, 5, 11, 12]
class List {
  constructor(list){
    this.list = list
    this.mx = list.reduce((max, num) => num > max ? num : max, 0)
  }
  getMax(){
    return this.mx
  }
}
const a = new List(ret)
console.log(a.getMax()) // 12

객체지향 프로그래밍의 특징

추상화, 캡슐화, 상속성, 다형성 4가지 존재

(1) 추상화

• 복잡한 시스템으로부터 핵심적인 개념 또는 기능을 간추려내는 것
• 기존 클래스들의 공통적인 부분만 추출해서 불필요한 부분은 제외하고, 중요한 부분에만 중점을 두어 상위 클래스를 만들어내는 것
• ex) 'workA'와 'workB' 클래스가 공통적으로 'name' 속성과 'getName()', 'setName()' 메서드를 가지고 있다면 해당 속성과 메서드를 뽑아서 'work' 라는 상위 클래스를 만듦

(2) 캡슐화

• 객체의 속성과 메서드를 하나로 묶고 일부를 외부에 감추어 은닉하는 것

(3) 상속성

• 상위 클래스의 특성을 하위 클래스가 이어받아서 재사용하거나 추가, 확장하는 것
• 코드의 재사용 측면, 계층적인 관계 생성, 유지보수성 측면에서 중요

(4) 다형성

• 하나의 메서드나 클래스가 다양한 방법으로 동작하는 것
• ex) 오버로딩, 오버라이딩

오버로딩

• 같은 이름을 가진 메서드를 여러 개 두는 것
• 메서드의 타입, 매개변수의 타입, 매개변수의 개수를 등을 달리 하여 여러 개의 같은 이름을 가진 메서드를 둘 수있음 
• 컴파일 중에 발생하는 '정적' 다형성
• 예시

class Person{
    public void eat(String a){
        System.out.println("I eat " + a);
    }
    public void eat(String a, String b){
        System.out.println("I eat " + a + " and " + b);
    }
}

public class CalculateArea{
    public static void main(String[] args){
        Person a = new Person();
        a.eat("apple");
        a.eat("apple", "banana");
    }
}

/*
I eat apple
I eat apple and banana
*/

오버라이딩

• 메서드 오버라이딩
• 상위 클래스로부터 상속받은 메서드를 하위 클래스가 재정의하는 것
• 런타임 중에 발생하는 '동적' 다형성
• 예시

class Animal{
    public void bark(){
        System.out.println("mumu! mumu!");
    }
}

class Dog extends Animal{
    @Override
    public void bark(){
        System.out.println("wal! wal!");
    }
}

public class Main{
    public static void main(String[] args){
        Dog d = new Dog();
        d.bark();
    }
}

/*
wal! wal!
*/

설계 원칙

• 객체지향 프로그래밍을 설계할 때는 SOLID 원칙을 지켜야 함
• S (단일 책임 원칙), O (개방 폐쇄 원칙), L (리스코프 치환 원칙), I (인터페이스 분리 원칙), D (의존 역전 원칙)

(1) 단일 책임 원칙 SRP (Single Responsibility Principle)

• 모든 클래스는 각각 하나의 책임만 가져야 하는 원칙
• ex) A라는 로직이 존재한다면 어떠한 클래스는 A에 관한 클래스여야 하고, 이를 수정한다고 했을 때도 A와 관련된 수정이어야 함

(2) 개방-폐쇄 원칙 OCP (Open Closed Principle)

• 유지 보수 사항이 생긴다면 코드를 쉽게 확장(개방)할 수 있도록 하고, 수정할 때는 폐쇄적이어야 하는 원칙
• 즉, 기존의 코드는 잘 변경하지 않으면서도 확장은 쉽게 할 수 있어야 함
• 객체 하나를 수정해야 할 때, 해당 객체에 의존적인 다른 객체도 모두 수정해야 한다면 좋은 설계가 아님
• ex) 라이브러리를 사용하는 객체의 코드를 수정한다고 해서 라이브러리 코드까지 변경하지는 않음

(3) 리스코프 치환 원칙 LSP (Liskov Substitution Principle)

• 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 하는 원칙
• 부모 객체에 자식 객체를 넣어도 부모 객체를 이용하는 시스템이 문제 없이 돌아가게 만드는 것

(4) 인터페이스 분리 원칙 ISP (Interface Segregation Principle)

• 하나의 일반적인 인터페이스보다 구체적인 여러 개의 인터페이스를 만들어야 하는 원칙

(5) 의존 역전 원칙 DIP (Dependency Inversion Prinicple)

• 자신보다 변하기 쉬운 것에 의존하던 것을 추상화된 인터페이스나 상위 클래스를 둠으로써 변하기 쉬운 것의 변화에 영향받지 않게 하는 원칙
• 객체는 저수준 모듈(ex. 구현된 객체)보다 고수준 모듈(ex. 추상화된 인터페이스나 상위 클래스)에 의존해야 함
• 객체는 객체보다 인터페이스에 의존해야 함 == 객체의 상속은 인터페이스에 의해 이루어져야 함
• 상위 계층은 하위 계층의 변화에 대한 구현으로부터 독립적이어야 함
• ex) 타이어를 갈아끼울 수 있는 틀을 만들어 놓은 후 다양한 타이어를 교체할 수 있어야 함