객체지향

객체지향의 역사, 특징

• 절차적인 언어의 대안으로써 객체지향 개념이 탄생, 코드 간의 관계를 맺어 유기적인 프로그래밍이 가능하게 되었음
• 코드의 재사용성 향상, 유지보수 용이, 중복 제거 세 가지 핵심 기능

객체를 지향하는 프로그래밍 방식

객체 하나하나가 각자의 책임을 가지고 있고 그 책임에 맞는 기능을 수행해 서로 협력을 이룬다.
협력을 통해 Application 을 구성한다.
이 때 서로에게 요청하는 방식이 message를 전송하는 것

OOP의 설계원칙

• Single Responsibility Principle
  객체는 단 하나의 책임만 가지고 있어야 한다. 하나의 기능만 수행하는 걸 의미하는 것은 아니며
  [오브젝트] 에서는 변경의 이유가 하나여야 한다고 한다.
• Open Close Principle
  변경에는 닫혀있고, 확장에는 열려있어야 한다.
  side effect 가 없도록 캡슐화가 잘 지켜져야 하며, 확장이 용이하도록 Interface 를 기준으로 설계되어야 한다.
• Liskov Substitution Principle
  객체지향의 꽃인 다형성을 이용할 때 객체의 행동이 호환되어야 한다.
  단순히 같은 이름의 메서드가 있으면 되는 것이 아니라 클라이언트의 입장에서 생각해야 한다.
  클라이언트가 원하는 역할이 있을 것이고, 그 역할이 호환되어야 함을 의미한다.
• ex) 엑셀을 밟으면 속도가 느리던 빠르던 앞으로 나아가야 한다.
  (뒤로 가면 클라이언트 입장에서 원하는 역할이 아니다.)
• Interface Segregation Principle
  가능한 한 최소 크기의 인터페이스에만 의존해야 한다.
  사용하지 않는 메소드에 의존 해서는 안 된다. (그 클래스를 알고 있기만 한다면 해당됨)
• Dependency Inversion Principle
  객체는 구체화에 의존해서는 안 되고 추상화에 의존해야 한다.
  구체화에 의존한다면 side effect가 존재하기 때문에 변경의 주기 (객체의 생애주기) 가 영향 받게 돼 의도한 대로 사용할 수 없다.

Class & Object

• Class란 객체를 정의해놓은 것으로 설계도, 틀에 비유됨
• Class를 알맞게 작성해두면 필요할 때마다 재사용 가능
• Object란 실제로 존재하는 것으로 대표되는 개념
• 객체는 속성과 기능으로 구성, 속성은 멤버 변수, 기능은 메서드와 mapping된다
• Instance란 Object가 형상화된 것, 실제로 작동하는 것

프로그래밍적 관점에서의 클래스

• 변수 : 하나의 데이터 저장
• 배열 : 하나의 종류, 여러 개의 데이터 저장
• 구조체 : 여러 종류, 여러 개의 데이터 저장
• 클래스 : 서로 관련있는 데이터와 함수(메서드) 저장

데이터의 저장 형태는 위와 같이 발전되어 왔고, 클래스는 특히 관련된 데이터와 함수를 묶어 놓는다는 점이 특별하다.

A라는 공간에서만 사용되는 함수들이 굳이 전역 범위에서 사용될 필요는 없기 때문에 A 공간에 데이터와 그 데이터를 이용하는 함수를 묶어놓는 것 응집도 향상이라는 결과를 얻을 수 있고 유지보수 측면에서 이익이 크다.