객체지향 프로그래밍이란?
객체 지향 프로그래밍(Object-Oriented Programming, OOP)은 컴퓨터 프로그래밍의 패러다임 중 하나로, 프로그램을 '객체'의 모임으로 파악하고자 하는 것이다. 객체 지향 프로그래밍은 유연하고 변경이 용이할 뿐만 아니라 유지 보수가 쉽기 때문에 대규모 SW개발에서 자주 사용된다.
객체지향 프로그래밍의 구성 요소
* 클래스(Class)
- 같은 종류의 집단에 속하는 속성(attribute)과 행위(behavior)를 변수와 메서드로 정의한 것
- 객체를 만들기 위한 일종의 메타정보
- 클래스는 다른 클래스 또는 외부 요소와 독립적으로 디자인
- 쉽게 말해 클래스는 비슷한 구조를 계속 만들어 내기 위한 일종의 틀
* 객체(Object)
- 클래스에서 정의한 것을 토대로 실제 메모리에 할당된 것
- 구현된 모든 대상을 의미
- 물리적으로 존재하거나 추상적으로 생각할 수 있는 것 중에서 자신의 속성을 가지고 있고 다른 것과 식별 가능한 것
- 추상적이고 포괄적인 개념
* 인스턴스(Instance)
- 객체가 메모리에 할당되어 실제 사용되고 있음을 의미
클래스가 붕어빵 틀이라면 그 틀을 통해 생성된 객체(붕어빵) 하나하나를 해당 클래스의 인스턴스(Instance)라고 부른다. 즉, 인스턴스란 현실의 객체를 소프트웨어 내에서 구현한 실체라고 볼 수 있고, 이렇게 생성된 인스턴스들은 각자 고유의 특성을 가지고 독립적으로 존재한다.
* 메서드(Method)
- 클래스로부터 생성된 객체를 사용하는 방법
- 객체에 명령을 내리는 메시지
객체지향 프로그래밍의 등장 배경
1. 순차적 프로그래밍 (=비구조적 프로그래밍)
정의한 기능의 흐름에 따라 순서대로 동작을 추가하며 프로그램을 완성하는 방식이다.
간단한 프로그램의 경우, 이렇게 코드를 짜게 되면 흐름이 눈으로 보이기 때문에 매우 직관적일 것이다. 그러나, 조금이라도 프로그램의 규모가 커지게 되면 곤란해진다. 만일 A → B → C 라는 동작을 구현하다가, C 에서 A 로 돌아가야할 상황이라면 goto 를 활용해야 한다.
그러나 goto 문을 무분별하게 활용하게 되면, 그야말로 스파게티 그 자체가 완성된다. 쭉 나열된 코드 속에서 위로 갔다가 아래로 갔다가 난리도 아니게 된다.
2. 절차적 프로그래밍 (=구조적 프로그래밍)
순차적 프로그래밍을 보완하기 위해 탄생한 것이 절차적 프로그래밍이다. 절차적 프로그래밍에서 '절차'는 함수를 의미한다. 따라서 절차적 프로그래밍이란, 반복되는 동작을 함수 및 프로시저 형태로 모듈화하여 사용하는 방식이다.
반복 동작을 모듈화하여 코드를 많이 줄일 수 있다는 장점이 있지만, 프로시저라는 것 자체가 너무 추상적이라는 단점이 있어 이를 보완하기 위해 탄생한 것이 객체지향 프로그래밍이다.
※ 참고 ※
최근의 프로그래밍 패러다임
- 명령형 프로그래밍 : 무엇(What)을 할 건지를 나타내기 보다, 어떻게(How) 할 건지 설명하는 방식
- 절차지향 프로그래밍 : 수행되어야 할 처리 과정을 포함하는 방식
- 객체지향 프로그래밍 : 객체들의 집합으로 프로그램의 상호작용 표현
- 선언형 프로그래밍 : 어떻게(How) 할 건지를 나타내기 보다, 무엇(What)을 할 건지 설명하는 방식
- 함수형 프로그래밍 : 순수 함수를 조합하고 소프트웨어를 만드는 방식
객체지향 프로그래밍의 특징
1. 추상화
필요로 하는 속성이나 행동을 추출하는 작업
추상적인 개념에 의존하여 설계해야 유연함을 갖출 수 있다.
즉, 세부적인 사물들의 공통적인 특징을 파악한 후 하나의 집합으로 만들어내는 것이 추상화
2. 캡슐화
낮은 결합도를 유지할 수 있도록 설계하는 것
* 결합도(coupling)란 어떤 기능을 실행할 때 다른 클래스나 모듈에 얼마나 의존적인가를 나타내는 말로, 독립적으로 만들어진 객체들 간의 의존도는 최대한 낮게 만드는 것이 중요하다.
즉, 한 곳에서 변화가 일어나도 다른 곳에 미치는 영향을 최소화 시키는 것이 캡슐화
객체가 내부적으로 기능을 어떻게 구현하는지 감추는 것이라고도 볼 수 있다.
캡슐화에서는 정보 은닉을 활용하여 외부에서 접근할 필요가 없는 것들은 private으로 접근하지 못하도록 제한을 둔다.
(객체안의 필드를 선언할 때 private으로 선언하는 이유)
3. 상속
여러 개체들이 지닌 공통된 특성을 부각시켜 하나의 개념이나 법칙으로 성립하는 과정
기존의 클래스에 기능을 추가하거나 재정의하여 새로운 클래스를 정의하는 것으로, 상속을 이용하면 기존에 정의되어 있는 클래스의 모든 필드와 메소드를 물려받아, 새로운 클래스를 생성할 수 있다.
상속을 활용하면 보다 적은 양의 코드로 새로운 클래스를 작성할 수 있고, 코드를 공통적으로 관리할 수 있기 때문에 코드의 추가 및 변경이 매우 용이하다.
4. 다형성
서로 다른 클래스의 객체가 같은 메시지를 받았을 때 각자의 방식으로 동작하는 능력
다형성은, 상속과 함께 활용할 때 큰 힘을 발휘한다. 이와 같은 구현은 코드를 간결하게 해주고, 유연함을 갖추게 해준다.
즉, 부모 클래스의 메소드를 자식 클래스가 오버라이딩해서 자신의 역할에 맞게 활용하는 것이 다형성
객체지향 설계 원칙
SOLID라고 부르는 5가지 설계 원칙이 존재
1 .SRP(Single Responsibility Principle) - 단일 책임 원칙
- 클래스는 단 한 개의 책임을 가져야 한다.
- 클래스를 변경하는 이유는 단 한 개이어야 한다.
- 단일 책임 원칙을 제대로 지키면 변경이 필요할 때 수정할 대상이 명확하다.
2. OCP(Open Closed Principle) - 개방 폐쇄 원칙
- 확장에는 열려 있어야 하고, 변경에는 닫혀 있어야 한다.
- 기능을 변경하거나 확장할 수 있으면서, 그 기능을 사용하는 코드는 수정하지 않는다.
- 개방 폐쇄 원칙을 지키지 않으면, instanceof와 같은 연산자를 사용하거나 다운 캐스팅이 일어난다.
3. LSP(Liskov Substitution Principle) - 리스코프 치환 원칙
- 하위 타입은 상위 타입을 대체할 수 있어야 한다.
- 상위 타입의 객체를 하위 타입의 객체로 치환해도, 상위 타입을 사용하는 프로그램은 정상적으로 동작해야 한다.
- 상속 관계가 아닌 클래스들을 상속 관계로 설정하면, 이 원칙이 위배된다.
4. ISP(Interface Segregation Principle) - 인터페이스 분리 원칙
- 인터페이스는 그 인터페이스를 사용하는 클라이언트를 기준으로 분리해야 한다.
- 클라이언트의 목적과 용도에 적합한 인터페이스만을 제공해야 한다.
- 각 클라이언트가 필요로 하는 인터페이스들을 분리함으로써, 해당 클라이언트가 사용하지 않는 인터페이스에서 변경이 발생하더라도 영향을 받지 않아야 한다.
5. DIP(Dependency Inversion Principle) - 의존 역전 원칙
- 고수준 모듈은 저수준 모듈의 구현에 의존해서는 안된다.
- 저수준 모듈이 고수준 모듈에서 정의한 추상 타입에 의존해야 한다.
- 즉, 추상화에 의존하며 구체화에는 의존하지 않는 설계 원칙을 의미한다.
* 고수준 모듈 : 변경이 없는 추상화된 클래스 (또는 인터페이스)
* 저수준 모듈 : 변하기 쉬운 구체적인 클래스
객체지향 프로그래밍의 장단점
장점
- 코드의 재사용성이 증가한다.
- 유지 보수가 용이하다.
단점
- 설계에 시간과 비용이 많이 들 수 있다.
- 객체가 많아지면 용량이 커지고, 처리속도가 상대적으로 느리다.
'CS > SW공학' 카테고리의 다른 글
| 테스트 주도 개발 (TDD: Test Driven Development) (0) | 2022.09.02 |
|---|
