[데브코스] 객체지향 프로그래밍(OOP)

W1D2 - 객체지향이란 무엇일까 ..? 🤔

객체지향 프로그래밍이란?

• 프로그램이 커질 때 어떻게 효율적으로 구성할까? -> 작은 단위의 객체로 나누고 합치자!
  • 객체 : class, instance
• 일을 작게 쪼개서 객체에게 위임하고, 객체끼리 서로 협력하게 만든다.
• 객체는 어떻게 구분할까? -> type으로 구분하자! (type == class)

객체지향의 특성

캡슐화

• 기능을 수행하는 단위로써 완전함을 가진다. -> 외부 의존성을 최대한 낮추는게 목적
• 정보은닉 : 객체 정보를 밖에서 가져오거나, 유출하지 않는다.
• 객체는 스스로 동작할 수 있는 환경을 가지며, 외부에 의존하거나 외부의 침략을 제한한다

class Human{
    private Heart heart;
    private Blood blood;
    Blood donation(){
        // blood에 접근하려면 메소드를 통해서!
    }
}
Human h = new Human();
h.Heart;        // 바로 변수에 접근? X
h.donation()    // 연결 메소드를 통해서만 접근 O

• 캡슐화는 접근지정자를 통해 구현한다.
  • private : 객체 내에서만 접근 가능
  • protected : private + 상속된 개체에서도 접근 가능
  • friendly : 같은 패키지 내에서만 접근 가능 (패키지 가시성)
  • public : 어디에서든지 접근 가능

상속

• 상위 == 부모 == super == 추상체
• 하위 == 자식 == this == 구상체
• 상속이란 공통된 기능을 여러 객체에게 전달하고 싶을 때 사용하는 것이 아님!!!
• 기능적으로 보지 말고 객체지향적 관점에서 보아야 한다.

추상화

• 상위 객체로 갈수록 추상화가 된다. (추상체)
• 객체간의 관계에서 상위 객체는 하위 객체보다 추상적이어야 한다.

// 의미적 추상체
abstract class Login{
    abstract void login();
}
// 구상체
class KakaoLogin extends Login{
    // 상위 객체에서 메소드 정의만 했기 때문에 Override가 필수!!!
    @Override void login(){};
}

• abstract class를 만들어서 안의 메소드를 추상화
• 하위 객체에서는 extends로 상속받고 추상 메소드를 Override

// 객체 존재 자체가 추상 => interface
interface Login{
    void login();
}
// 구상체
class KakaoLogin implements Login{
    // 얘도 Override가 필수!!!
    @Override void login(){};
}

• interface로 생성, 그냥 추상적인 존재임 (구조만 존재)
• 하위 객체에서는 implements로 상속받고 추상 메소드를 Override

다형성

• type을 여러가지로 표현할수 있어야 하는 것

// 추상체로 추상체 객체 선언
Login k = new Login();
// 추상체로 구상체 객체 선언
// 하지만 이 객체에선 추상체에 정의된 메소드만 사용가능
Login k = new KakaoLogin();

• 왜 이렇게 쓰는데? => 인터페이스를 통해 자체적인 필터링 기능이 생긴다!
• 구상체를 만들 때 상속으로 많은 메소드들을 정의할 수 있음
• 하지만 이 구상체를 추상체(interface)로 선언한다면? => 해당 추상체 내부 메소드만 사용 가능 => 권한을 준다고 생각!

객체지향 설계

UML (Class Diagram)

• 객체지향을 설명하기 위한 도구
• 만들기 참고 사이트 : https://staruml.io/

객체지향 5원칙 - SOLID

• SRP(Single responsibility principle), 단일 책임 원칙 : 객체가 수정되는 이유는 그 객체에게 있어야 한다
• OCP(Open/closed principle), 개방-폐쇄 원칙 : 처음부터 수정은 지양, 확장은 지향하도록 설계하자
• LSP(Liskov substitution principle), 리스코프 치환 원칙 : 추상객체가 사용되는 부분에 구상객체가 들어가도 문제가 없어야 한다.
• ISP(Interface segregation principle), 인터페이스 분리 원칙 : 위 예제처럼 인터페이스 나눠서 써라~
• DIP(Dependency inversion principle), 의존관계 역전 원칙 : 중요도가 추상화 > 구체화 / 의존성 주입

이것만 알면 끝?

• NOOO~ 좋은 원칙이지만 너무 추상적이다. 진짜 설계해보자!
• 만들다 보니… 공통점이 생겼다? => 디자인 패턴의 탄생 😓
• 그 책이 바로 GoF(Gang of Fours). Design Patterns: Elements of Reusable Object-Oriented Software. _ 1995
• 총 23가지의 디자인 패턴이 있다. 🚀 포스팅 이동