6.14 Dev.Feedback (객체 지향 프로그래밍 Object-oriented programming)

절차 지향 프로그래밍

객체 지향 프로그래밍에 대해 더 디테일하게 공부하기 전에 먼저 절차지향 프로그래밍을 찾아보면,

순차적인 처리가 중요시 되는 프로그래밍 기법이다. 즉 물이 위에서 아래로 흐르는 것같은 방식을 통해 모든 프로그램이 유기적으로 연결되도록 만드는 것이다. 이 방식 자체는 컴퓨터의 작업 처리 방식과 유사하여 실행속도가 빠르지만,

시대가 흐를수록 발전하는하드웨어로 인해 컴퓨팅 환경은 급속도로 증가했지만, 소프트웨어가 그 발전 속도를 따라가지 못하게 되었고 이런 상황에 발 맞춰 소프트웨어의 개발시간을 단축할 수 있는 방식을 택하기 위해 객체 지향 프로그래밍이 등장하게 된 것이다.

 

장점

- 컴퓨터의 처리구조와 비슷하여 실행속도가 빠르다.

 

단점

- 실행 순서가 정해져 있으므로, 코드의 순서가 바뀌면 side effect가 발생할 가능성이 높다.

- 원인을 파악하기 힘들어 디버깅이 어렵고, 유지보수도 힘들어진다.

 

객체 지향 프로그래밍

객체 지향 프로그래밍(OOP, Object-oriented programming)은, 실제 세계를 모델링하여 소프트웨어를 개발하는 방법이다. 절차 지향 프로그래밍과는 다르게 데이터와 기능을 한데 묶어서 처리한다(모듈화). 속성과 메소드가 하나의 "객체"라는 개념에 포함되며, 이는 자바스크립트 내장 타입인 object(이하, object literal)와는 다르게, 클래스(Class)라는 이름으로 부른다. 객체 지향 프로그래밍은 개발하려는 것을 기능별로 묶어 모듈화를 함으로써 하드웨어가 같은 기능을 중복으로 연산하지 않도록 하고, 모듈을 재활용하여 하드웨어의 처리양을 큰 폭으로 줄여준다.

객체 지향 프로그래밍의 기본적인 컨셉

캡슐화

• 데이터와 기능을 하나의 단위로 묶는 것
• 은닉(hiding): 구현은 숨기고, 동작은 노출시킴
• 느슨한 결합(Loose Coupling)에 유리: 언제든 구현을 수정할 수 있음

느슨한 결합은 코드 실행 순서에 따라 절차적으로 코드를 작성하는 것이 아닌, 코드가 상징하는 실제 모습과 닮게 코드를 모아 결합하는 것을 의미함.키보드가 구동되는 것을 예시로 들면, 키보드 버튼이 눌리고, 전기 신호가 생겨서, 전선을 타고 흐르고, 입력이 된다같이 전 과정을 나누는 것이 아닌, 키보드의 상태를 속성으로 정하고 키보드의 기능(버튼을 한가지만 누른다 혹은 여러가지를 동시에 누른다)을 메소드로 정해서 코드만 보고도 인스턴스 객체의 기능을 상상할 수 있게 작성하는 것이다.

 

캡슐화라는 개념에는 "은닉화"의 특징도 포함하고 있는데, 은닉화는 내부 데이터나 내부 구현이 외부로 노출되지 않도록 만드는 것이다. 따라서, 디테일한 구현이나 데이터는 숨기고, 객체 외부에서 필요한 동작(메소드)만 노출시켜야 하는데, 은닉화의 특징을 살려서 코드를 작성하면 객체 내 메소드의 구현만 수정하고, 노출된 메소드를 사용하는 코드 흐름은 바뀌지 않도록 만들 수 있다.

 

반면 절차적 코드의 경우 데이터의 형태가 바뀔 때에 코드의 흐름에 큰 영향을 미치게 되어 유지보수가 어려워 진다. 그래서 더 엄격한 클래스는 속성의 직접적인 접근을 막고, 설정하는 함수(setter), 불러오는 함수(getter)를 철저하게 나누기도 한다.

 

추상화

 

추상화는 내부 구현은 아주 복잡한데, 실제로 노출되는 부분은 단순하게 만든다는 개념, 예를 들어 전화라는 객체가 있다면, 그 안에는 스피커와 마이크가 존재하고, 서킷 보드 등이 존재하는 등 내부 구현이 되어있지만, 실제로 우리가 사용할 때에는, 이러한 존재에 대해서는 생각하지 않고 단순히 수화기를 들고 버튼을 눌러서 해결하는 것으로 인터페이스(interface)를 단순화시킨 것을 볼 수 있다.

여기서 포인트는 캡슐화는 코드나 데이터의 은닉에 포커스가 맞춰져 있고, 추상화는 클래스를 사용하는 사람이 필요하지 않은 메소드 등을 노출시키지 않고, 단순한 이름으로 정의하여, 클래스를 사용하는 사람이 최대한 편하게 사용할 수 있도록 만들어주는 것이다.

 

즉 클래스를 정의할 때 메소드와 속성만 정의하는 것, 그것이 추상화를 이루어낸 인터페이스인 것!

 

 

상속

 

상속은 부모 클래스의 특징을 자식 클래스가 물려받는 것이다.디테일하게 짚고 넘어가자면, "기본 클래스의 특징을 파생 클래스가 상속받는다"로 표현하는 것이 적합하다.

예를 들어, 사람(Human)이라는 클래스가 있다고 가정해보았을 때, 사람은 기본적으로 이름과 성별, 나이와 같은 속성, 그리고 먹다, 자다 등과 같은 메소드가 있다고 볼 수 있다.

여기에 추가적으로 학생(Student)이라는 클래스를 작성한다면, 학생의 본질은 결국 사람이므로 사람(Human) 클래스의 속성과 메소드를 재구현하지 않고 상속을 이용한다. 즉, 학생(Student) 클래스는 사람(Human)클래스를 상속받아 추가적으로 학습 내용, 공부하다와 같은 속성/메소드를 추가하여 비효율적인 코드를 줄이는 방향으로 작성할 수 있게 해주는 것이다.

 

다형성

 

다형성을 HTML 엘리먼트를 예로 들어보면, Textarea(TextBox), Select, 그리고 Checkbox 같은 요소들을 

HTML에서는 Element라고 부른다. 이 엘리먼트를 직접 구현한다고 했을 때, 모든 엘리먼트들은 전부 객체이므로, 내부적으로 모양을 그리고 화면에 뿌리는 메소드가 존재한다. 이 메소드가 render라는 이름을 갖고 있다면, 이 경우에는, TextBox, Select, Checkbox의 공통의 부모인 HTML Element라는 클래스에 render라는 메소드를 만들고 상속을 받게 만들 수 있다. 그런데 다형성의 핵심은 이 같은 이름의 render 라는 메소드가 조금씩 다르게 작동한다는 데 있다. TextBox는 가로로 긴 네모 상자와 커서가 있는 형태일 것이고, Select 박스는 눌렀을 때 선택지가 나오도록 화면에 그려야 하는데 이처럼 같은 이름을 가진 메소드라도 조금씩 다르게 작동한다. 이것이 바로 다형성

 

만일 언어 자체에서 다형성을 제공하지 않는다면, 기본(부모) 클래스에 종류별로 분기를 시켜서 하나하나 다르게 만들어야 할 것이기에 코드의 양이 엄청나게 많아지게 될 것이다.

또한 각각의 자식 클래스의 별도의 각기 다른 render 함수를 만들 수도 있겠지만, 엘리먼트라는 클래스의 본질상 "화면에 뿌린다"(render)는 개념은 부모가 갖고 있는 것이 합리적이다.

 

이러한 특성들로 인해 발휘된 장점

 

- 캡슐화는 코드가 복잡하지 않게 만들고, 재사용성을 높인다.

 

- 추상화와 상속 역시 코드가 복잡하지 않게 만들고, 단순화된 사용으로 인해 변화에 대한 영향을 최소화 한다.

 

- 다형성으로 인해 동일한 메소드에 대해 if/ else if와 같은 조건문 대신 객체의 특성에 맞게 작성을 할 수 있게 되었다.