💡 객체 지향 프로그래밍
객체 지향 프로그래밍 이란
- 데이터와 함수 ( 논리 )가 결합된 형태를 ( 일반적으로 클래스 ) 통해 시스템을 개발하는 방식
- 책에서는 객체지향 프로그래밍이 아니더라도 이러한 형태로 개발 해오는 방식이 이미 쓰여지고 있었기 때문에 이 정의가 부족하다고 이야기 함
- 실제 세계를 모델링 하는 새로운 방법
- 책에서는, 너무 모호한 답변이며 의미가 없는 답변 이기 때문에 이 정의는 맞지 않다고 설명
- 책에서는 객체 지향 ( Object-Oriented )을 캡슐화 / 상속 / 다형성 의 개념을 적절히 조합 한 것 이라고 서술
- 객체 지향 프로그래밍이라면, 이 세가지 개념을 반드시 지원 해야 함을 이야기 하고 있음
캡슐화
- 캡슐화란
- 데이터 ( 변수 )와 이에 관련된 행위 ( 메서드 )를 하나로 묶는 행위
- 외부에서 변수와 메서드에 접근 하는 것을 막아주는 접근 제한자를 서술
- 변수를 은닉하고, 필요하다면 변수에 접근하기 위한 방식을 외부에 노출 시켜주는 작업
- 데이터와 함수를 보다 쉽고 효과적으로 캡슐화 하는 방식을 객체지 지향 언어가 제공 해 줌
- Example
데이터 ( 변수 )와 이에 관련된 행위 ( 메서드 )를 하나로 묶는 행위 를 클래스를 통해 쉽게 구현 할 수 있음
외부에서 변수와 메서드에 접근 하는 것을 막아주는 접근 제한자를 서술 을 접근 제한자를 통해 쉽게 구현 할 수 있음
변수를 은닉하고, 필요하다면 변수에 접근하기 위한 방식을 외부에 노출 시켜주는 작업 을 접근 제한자와 메서드를 통해 쉽게 구현 할 수 있음
- 하지만 이 캡슐화의 개념이 객체 지향 프로그래밍에만 국한 된 것은 아님
- C에서도 헤더와 실제 구현체를 구분 함으로써 완벽한 캡슐화가 가능 함
- 따라서 캡슐화만 지키고 있다고 해서 객체 지향 프로그래밍이라고 할 수 없음
- 책에서는 객체지향에 대해서 캡슐화가 가지는 점수는 100점만점에 0점
- Java / C#으로 들어오며 헤더와 구현체를 구분 하는 개념을 버렸으며 이를 통해 캡슐화가 많이 훼손 됨
- 이를 보안하기 위해
접근제한자 등을 두었지만, 컴파일러가 강제하지 않는 경우가 대다수임
- 따라서 객체지향 프로그래밍에서 캡슐화를 위해 개발자가 항상 신경을 쓰는 습관을 가져야 함
상속
- 상속이란
- 상위 / 부모 클래스의 특성을 하위 / 자식이 상속 받아 기존에 정의된 특성 ( 프로퍼티, 메소드 )을 재사용하고 이에 추가 / 확장 / 개선 하는 작업
- 책애세는, 객체 지향 언어가 상속만큼은 확실히 제공 했으나, 어떤 변수와 함수를 하나의 유효 범위로 묶어 재정의 하는 역할만 했다고 서술
- 즉, 객체지향 언어가 있기 전부터 상속이란 개념은 존재 했음 따라서 상속만 사용하고 있다고 해서 객체지향 프로그래밍이라고 할 수는 없음
- 하지만, 객체 지향 언어를 활용하여 상속을 정말 편하게 쓸 수 있는 것을 사실이며, 다중 상속도 이를 통해 구현이 너무나도 쉬워짐을 말함
- 책에서는 객체지향에 대해서 상속이 가지는 점수는 100점만점에 50점
다형성
- 다형성이란
- 프로그램 문맥에 따라, 다르게 반응 / 행동하는 능력
- 각 객체가 동일한 메세지 / 함수호출에 다르게 행동하는 능력
- 책에서는, 다형성도 객체지향 언어가 등장하기 전부터 구현 가능했던 것 중에 하나라고 서술
- 유닉스의 입출력 장치의 표준 함수의 예시
- 유닉스에서는 입출력 장치 드라이버가 open / close / read / write / seek 함수를 제공 할 것을 요구
- 각 입출력 장치 드라이버는, 위 함수를 반드시 구현 해야만 한다고 가정
- 이때, 유저가 사용 할 때엔 입출력 장치 드라이버의 변수에
read 함수를 호출하는 형태를 갖고 있으면, 장치 드라이버를 갈아 끼우며 여러 형태로 재활용이 가능
- 장치 드라이버 변수를 갈아 끼우면,
read 함수를 가져 올 때 장착된 장치 드라이버의 공간에서 함수를 가져와서 사용하게 됨
- 즉, 함수를 가리키는 포인터를 갈아 끼우는 형태 이며 이러한 기법을 통해 다형성을 구현하고 활용 할 수 있음
- 따라서, 객체지향 개념이 다형성을 존재하게 한건 절대 아님
- 하지만, 객체지향의 개념이 다형성을 좀 더 안전하고 더욱 편리하게 사용 할 수 있도록 도와줌
- 함수의 포인터를 통해 직접 함수를 참조하는 행위는 포인터를 초기화 하는 관례를 반드시 지켜야 함
- 이런 관례는 프로그래머가 특정관례를 수동으로 따르는 형식이고 이러한 버그는 잡기 쉽지도 않으므로 매우 위험한 행위
- 다형성을 통해 소스코드 의존성을 정말 많이 낮출 수 있음
- 위 입출력 드라이버의 예시를 볼 때, 입출력 드라이버가 변경 될 때 다시 컴파일 할 필요도 없으며 소스코드 변경도 필요치 않음
- 입출력 소스코드에 전혀 의존하고 있지 않기 때문