OOP

OOP

객체 지향 프로그래밍은 컴퓨터 프로그래밍 패러다임 중 하나로,
프로그래밍에서 필요한 데이터를 추상화시켜 상태와 행위를 가진 객체를 만들고 그 객체들 간의 유기적인 상호작용을 통해 로직을 구성하는 프로그래밍 방법이다.

장점으로는 아래와 같은 점이 있으며,

• 코드 재사용이 용이
  남이 만든 클래스를 가져와서 이용할 수 있고 상속을 통해 확장해서 사용할 수 있다.

• 유지보수가 쉬움
  절차 지향 프로그래밍에서는 코드를 수정해야할 때 일일이 찾아 수정해야하는 반면 객체 지향 프로그래밍에서는 수정해야 할 부분이 클래스 내부에 멤버 변수혹은 메서드로 존재하기 때문에 해당 부분만 수정하면 된다.

• 대형 프로젝트에 적합
  객체 지향의 특징 중 하나인 클래스 단위의 모듈화시켜서 개발할 수 있으므로 대형 프로젝트처럼 여러 명, 여러 회사에서 프로젝트를 개발할 때 업무 분담하기 쉽다.

단점으로는

• 처리 속도가 상대적으로 느림

• 객체가 많으면 용량이 커질 수 있음

• 개인을 위한 방향성이 아니기에 설계시 많은 시간과 노력이 필요
  등 이 있다.

OOP 5대원칙

OOP에는 5가지의 원칙이 있다.

1. 단일 책임 원칙(Single responsibility principle) - 약어: SRP

1번째 원칙이며, 모든 Class는 하나의 책임만 가져야 하는 원칙이다.
말 그대로 작성된 Class는 하나의 기능만 가지며, 그 Class가 제공하는 모든 서비스는 하나의 책임을 수행하는 데 집중되어야 한다는 원칙이다.

단일 책임 원칙의 이유는 하나의 Class에 여러가지의 기능이 들어갈경우 해당 클래스를 수정할 때
이를 포함 하는다른 모듈에 어떤 영향을 줄지 모르기 때문이다.
코드의 재사용및 유지보수에 적합한 OOP의 장점을 살리는 중요한 원칙이다.

2. 개방 폐쇄 원칙(Open/Closed principle) - 약어: OCP

2번째 원칙이며, 개방폐쇄 원칙은 Class 및 함수가 확장에 대해서는 확장에 대하여 Open 상태여야하며, 수정에 대해서는 Closed 상태여야 한다.

수정이 일어나더라도 확장에 대한 권한이 Closed 상태이기에 기존의 구성요소에서는 수정이 일어나지 않아야 하며, 새로운 Class밑 함수에 대해서는 쉽게 확장이 가능하여 재사용을 할 수 있도록 해야한다는 의미이다. 추상화와 다형성의 특징을 살린 원칙이다.

3. 리스코프 치환 원칙(Liskov substitution principle) - 약어: LSP

3번째 원칙이며, 상속에 대한 개념을 다루는 원칙이다. 위키백과에서는 ‘자료형 S가 자료형 T의 하위형이라면 필요한 프로그램의 속성의 변경없이 자료형 T의 객체를 자료형 S의 객체로 교체(치환) 할 수 있어야 한다.’ 라고 설명하고 있다. 쉽게 말해서 부모 Class가 들어갈 자리에 자식 Class를 넣어도 잘 구동되어야 한다 라는 원칙이다. 만약 블로그와 서적 등에서는 리스코프 치환 원칙의 예로 정사작형 클래스와 직사각형 클래스를 예로 든다. 수학적으로만 봤을 때는 직사각형은 정사각형을 포함하는 포괄적인 의미이다.

4. 인터페이스 분리 원칙(Interface segregation principle) - 약어: ISP

4번째 원칙으로서, 클라이언트는 자신이 사용하지 않는 메소드에 의존 관계를 맺으면 안된다라는 원칙이다. 제목에서는 사실 인터페이스라는 개념이 자바스크립트에서는 존재하지 않기 때문에 이 원칙의 경우 다른 원칙들처럼 딱 맞게 적용할 수는 없다.

이 법칙에서의 핵심 과제는 큰 덩어리의 인터페이스들을 구체적이고 작은 단위들로 분리시킴으로써 꼭 필요한 메서드들만 이용할 수 있게 한다이다. 이러한 원칙을 준수하면서 기대할 효과로는 시스템의 내부 의존성 관계를 느슨하게 하여 리팩토링, 수정, 재배포를 쉽게 할 수 있도록 한다.

5. 의존관계 역전 원칙(Dependency inversion principle) - 약어: DIP

5번째 원칙으로 이 원칙은 2가지 중요한 요소를 가지고 있다.

• 상위 모듈은 하위 모듈에 종속되어서는 안된다. 둘 다 추상화에 의존해야 한다.
• 추상화는 세부사항에 의존하지 않는다. 세부사항은 추상화에 의해 달라져야 한다.

위키백과에 따르면 OOP에서의 의존 관계 역전 원칙은 소프트웨어 모듈들을 분리하는 특정 형식을 지칭한다고 한다. 이 원칙에 따르면 상위 모듈이 하위 모듈에 의존하는 전통적인 의존 관계를 반전시킴으로써, 상위 모듈이 하위 모듈의 구현으로부터 독립되어야 한다고 한다.

이 원칙의 위반할 경우 개인적으로는 리팩토링을 하는 경우에도 그렇고, 비지니스 추가시에 굉장히 많은 제약을 가지지 않나 생각된다. 어떠한 프로젝트에서 리팩토링 혹은 기능을 추가할 때, 기존의 레거시 코드가 잘못된 것을 알면서도 수정하지 않고 그대로 두는 데에는 여러가지 이유가 있다. 레거시 코드를 수정함으로써 생길 예상치 못할 또 다른 에러에 직면할 수도 있고, 혹은 재사용을 위해 분리를 해야하는데 너무 얽키고 설켜 모듈을 뜯어낼 수 없는 경우도 있을 것이다. 이러한 원인은 여러 가지 원인들이 있을테니만 그 중 하나로는 상호 의존성이 너무 강하게 묶여서 있어서가 아닐까 싶다. 모듈 간의 의존성이 강한 경우, 하나의 모듈을 수정할 때는 그 모듈에 의존성을 가진 모든 모듈에 대해서도 변경이 일어나야 한다. 이러한 이유 때문에 하나의 모듈에 변경에도 신중할 수 밖에 없어진다. 그래서 상위 모듈과 하위 모듈은 의존을 하되 추상에 의해 의존해야 한다.

OOP 특징

1. 캡슐화
실제로 구현 부분을 외부에 드러나지 않도록 하는 것
변수와 메소드를 하나로 묶음
데이터를 외부에서 직접 접근하지 않고 함수를 통해서만 접근
ex) public, private, protected
public : 클래스 외부에서 접근 가능
private : 클래스 내부에서만 접근 가능
protected : 상속받은 자식 클래스에서만 접근 가능

2. 상속
자식 클래스가 부모 클래스의 특성과 기능을 물려받는 것
기능의 일부분을 변경하는 경우 자식 클래스에서 상속받아 수정 및 사용함
상속은 캡슐화를 유지, 클래스의 재사용이 용이하도록 해 준다.

3. 추상화
인터페이스로 클래스들의 공통적인 특성(변수, 메소드)들을 묶어 표현하는 것

4. 다형성
어떤 변수,메소드가 상황에 따라 다른 결과를 내는 것

• 오버로딩(Overloading) : 하나의 클래스에서 메소드의 이름이 같지만, 파라메터가 다른 것
• 오버라이딩(Overriding) : 부모 클래스의 메소드를 자식 클래스의 용도에 맞게 재정의하여 코드의 재사용성을 높임