개요

정의

  • OOP(Object-Oriented Programming)
  • 객체들의 집합으로 프로그램의 상호 작용을 표현하며 데이터를 객체로 취급하여 객체 내부에 선언된 메서드를 함께 활용하는 방식
  • 모든 객체는 내부에 자료형(Field)와 함수(Method)가 존재함
  • 절차지향에서도 함수 재활용은 가능하지만 코드 수정 시 영향 범위를 예상하기 어려웠음
  • JAVA, C++, C#, Python 등이 이에 속함

 

장점

  • 모듈화, 캡슐화로 인해 유지보수가 용이
  • 상속을 통한 코드의 재사용성 증가
  • 객체 지향적이기 때문에 현실 세계와의 유사성에 의해 자연적인 모델링이 가능
  • 클래스 단위로 모듈화하여 독립적인 객체를 사용함으로써 개발의 생산성 향상

 

단점

  • 설계에 많은 시간이 소요되며 다른 패러다임에 비해 처리 속도가 느림
  • 객체가 많아지면 용량이 커질 수 있음

 

4가지 특성

추상화(abstraction)

  • 객체에서 공통된 속성과 기능을 추출하여 정의하는 것
  • 불필요한 정보는 숨기고 중요한 정보만을 표현함
  • 클래스 정의 시 메소드와 속성만 정의한 것을 인터페이스라고 부름

 

캡술화(encapsulation)

  • 변수와 함수를 클래스로 묶어놓은 것을 의미
  • 접근 제어자를 통한 정보 은닉 → 높은 응집도, 낮은 결합도를 유지
    • 결합도: 어떤 기능을 실행할 때 다른 클래스나 모듈에 얼마나 의존적인가
  • 한 곳에서 변화가 일어나도 다른 곳에 미치는 Side Effect를 최소화시킴

 

상속(inheritance)

  • 상위 클래스의 특성을 하위 클래스가 이어받아 재사용하거나 추가, 확장하는 것
  • 코드의 재사용 측면, 계층적인 관계 생성, 유지 보수성 측면에서 중요
  • 엄밀히 따지면 상속은 자식 클래스를 외부로부터 은닉하는 캡슐화의 일종임

 

다형성(polymorphism)

  • 서로 다른 클래스의 객체가 같은 동작 수행 명령을 받았을 때, 각자의 특성에 맞는 방식으로 동작하는 것
  • 코드를 간결하게 해주고 유연함을 갖추게 해줌
  • 다형성의 대표적인 예로 오버로딩, 오버라이딩이 있음
    • 오버로딩: 같은 이름을 가진 메서드를 여러 개 두는 것
    • 오버라이딩: 상위 클래스로부터 상속받은 메서드를 하위 클래스가 재정의하는 것

 

객체 지향 설계 원칙

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

 

SRP(Single Responsibility Principle)

  • 하나의 클래스는 하나의 책임만 가져야 함
  • 정확히는, 모듈이 변경되는 이유가 한가지여야 함
  • 지키지 않을 경우, 한 변경에 의해 다른 책임과 관련된 코드에도 영향이 갈 수 있음
  • 제대로 지킬 경우, 변경이 필요할 때 수정할 대상이 명확해짐

 

OCP(Open Closed Principle)

  • 확장에는 열려있으나 변경에는 닫혀 있어야 함
  • 확장에 열려 있다: 요구사항이 변경될 때 새로운 동작을 추가하여 기능을 확장할 수 있음
  • 변경에 닫혀 있다: 기존의 코드를 수정하지 않고 동작을 추가하거나 변경할 수 있음

⇒ 기존의 코드는 변경하지 않으면서도 확장은 쉽게 할 수 있어야 함

 

LSP(Liskov Substitution Principle)

  • 올바른 상속 관계의 특징을 정의하기 위한 원칙
  • 부모 객체를 자식 객체로 치환해도 시스템이 정상적으로 동작해야 함
  • 자식 클래스가 부모를 대체하기 위해서는 부모 클래스에 대한 클라이언트의 가정을 준수해야 함
  • 여기서 대체 가능성을 결정하는 것은 해당 객체를 이용하는 클라이언트임

 

ISP(Interface Segragation Principle)

  • 목적과 관심이 각기 다른 클라이언트가 있다면 인터페이스를 통해 적절하게 분리할 필요가 있음
  • 즉 클라이언트의 목적과 용도에 적합한 인터페이스만을 제공하는 것
  • 모든 클라이언트는 관심에 맞는 인터페이스만을 접근하여 불필요한 접근을 최소화할 수 있음
  • 기존 클라이언트에 영향을 주지 않은 채로 유연하게 객체의 기능을 확장/수정 가능

 

DIP(Dependency Inversion Principle)

  • 고수준 모듈은 저수준 모듈의 구현에 의존해서는 안되고, 저수준 모듈은 고수준 모듈에서 정의한 추상 타입에 의존해야 함
  • 변하기 쉬운 것에 의존하던 것을 추상화된 인터페이스나 상위 클래스를 두어 변하기 쉬운 것의 변화에 영향받지 않게 하는 원칙
  • 예를 들어, 타이어를 갈아끼울 수 있는 틀을 만든 후 다양한 타이어를 교체할 수 있어야 함
  • 즉 상위 계층은 하위 계층의 변화에 대한 구현으로부터 독립해야 함

 

References

'Computer Science > 프로그래밍 패러다임' 카테고리의 다른 글

[프로그래밍 패러다임] 프로그래밍 패러다임이란?  (0) 2023.01.20
[프로그래밍 패러다임] 절차지향 프로그래밍(Procedural Programming)  (0) 2023.01.20
[프로그래밍 패러다임] 함수형 프로그래밍(Functional Programming)  (0) 2023.01.19

+ Recent posts

티스토리툴바