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

Yeonn·2023년 8월 15일
0

CS 공부

목록 보기
2/13
post-thumbnail

1. OOP의 특징

📌 어떤 대상을 추상화하여 공통점을 찾고 그것을 캡슐화해 한 군데 모아 객체로 만들고, 새로운 객체가 상속받아 코드 재사용이 가능하게 만들어 준다. 또한 이 상속받은 객체는 다형성을 통해 기능을 수정, 추가하여 재사용할 수 있다.

✔️ 캡슐화 ( Encapsulation )

데이터와 코드의 형태를 외부로부터 알 수 없게 하고, 데이터의 구조와 역할, 기능을 하나의 캡슐형태로 만드는 것

  • 변수를 private로 선언하여 데이터를 보호하고, 보호된 변수는 getter나 setter등의 메서드를 통해서만 간접적으로 접근을 허용
  • 불필요한 정보를 감출 수 있음 → 정보 은닉 가능 ( 캡슐화 ≠ 정보은닉 )

✔️ 추상화 ( Abstraction )

객체의 공통적인 속성과 기능을 추출하여 정의하는 것으로 목적과 관련이 없는 부분을 제거하여 필요한 부분만을 표현하기 위한 기법이다.

✔️ 상속 ( Inheritance )

기존 상위 객체의 기능을 가져와 재사용 할 수 있으면서도 동시에 새로운 하위 객체에 새로운 기능 추가가 가능하다.
상속이 필요한 이유는 코드의 중복을 없애기 위함이며, 자식 객체를 생성할 때 부모 객체의 속성들을 자동으로 물려받기 때문에 자식 객체에서 재정의 할 필요가 없어진다.

✔️ 다형성 ( Polymorphism )

상속과 연관있는 개념으로 한 객체가 상속을 통해 기능을 확장하거나 변경하여 다른 여러 형태( 객체 )로 재구성 되는 것을 의미한다. 하나의 부모 밑의 자식이라도 각각 다른 부분을 갖으면서, 같은 이름의 속성을 유지함으로서, 인터페이스를 유지하고 메서드 이름을 낭비하지 않도록 한다. 이는 API가 많아질ㅁ 수록 복잡성이 증가하기 때문에 코드 재사용성을 늘려주어 유지보수를 용이하게 한다. 오버로드Overload 또는 오버라이드Override가 다향성의 대표적인 예 이다.

  • 오버로드Overload: 하나의 객체 안에서 같은 이름의 메서드를 사용하지만 각 메서드마다 다른 용도로 사용되며 그 결과물도 다르게 구현하는 것을 의미한다. 메서드 끼리 이름은 같지만 매개변수의 개수나 데이터 타입이 달라야 한다.
  • 오버라이드Override: 하위 객체가 상위 객체에서 만들어지는 메서드를 필요한대로 다시 재창조해서 사용하는 것을 의미한다


2. OOP의 5가지 설계 원칙 ( SOLID )

5가지의 객체 지향 설계 원칙인 SOLID가 얘기하는 핵심은 결국 추상화와 다형성 !

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

모든 모듈은 각각 하나의 책임만 가져야 한다.
해당 모듈이 여러 대상 또는 액터들에 대해 책임을 가져서는 안되고, 오직 하나의 대상 또는 액터에 대해서만 책임을 가짐으로써 변경이 필요할 때 수정 대상이 명확해 진다.
→ 유지보수 용이

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

확장에는 열려있고, 수정에는 닫혀있다

  • 확장이 열려있다: 요구사항이 변경될 때 새로운 동작을 추가하여 모듈의 기능을 확장할 수 있다.
  • 수정이 닫혀있다: 기존의 코드를 수정하지 않고 모듈의 동작을 추가하거나 변경할 수 있다.
    → 추상화에 의존
    : 핵심적인 부분만 남기고 불필요한 부분은 제거 ! 변하는 것들은 숨기고 변하지 않는 것들에 의존

3. 리스코프 치환 원칙 ( Liskov Subsitution Principle )

자식 객체는 언제나 자신의 부모 객체를 대체할 수 있다는 원칙이다.
→ 자식 객체는 부모 객체의 역할을 무시하거나 재정의하지 않고 확장만 수행하도록 설계

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

클라이언트의 목적과 용도에 적합한 인터페이스 만을 제공하는 것이다.
→ 모든 클라이언트가 자신의 관심에 맞는 퍼블릭 인터페이스(외부에서 접근 가능한 메세지) 만을 접근하여 불필요한 간섭을 최소화할 수 있다. 즉 각각은 자신이 사용하지 않는 인터페이스는 구현하지 않아야 한다.
하나의 일반적인 인터페이스보다 여러 개의 구체적인 인터페이스가 낫다

5. 의존 역전 원칙 ( Dependency Inversion Principle )

  1. 고수준 모듈은 저수준 모듈의 구현에 의존해서는 안 되며, 저수준 모듈이 고수준 모듈에 의존해야 한다.
    의존 역적 원칙에서 의존성이 역전되는 시점은 컴파일 시점 !

0개의 댓글