객체지향 프로그래밍이란?
- 객체지향 프로그래밍(Object Oriented Programming)은 문제를 여러 개의 객체 단위로 나눠 작업하는 방식을 말합니다.
- 이 방식은 오늘날 가장 많이 사용하는 대표적인 프로그래밍 방식이고 JAVA, C# 등이 대표적인 객체지향 프로그래밍 언어입니다.
- 객체지향의 장점
- 코드 재사용이 용이
- 남이 만든 클래스를 가져와서 이용 가능
- 상속을 통한 확장 가능.
- 유지보수가 쉬움
- 절차 지향 프로그래밍에서는 코드를 수정해야할 때 일일이 찾아 수정해야하는 반면 객체 지향 프로그래밍에서는 수정해야 할 부분이 클래스 내부에 멤버 변수 혹은 메서드로 존재하기 때문에 해당 부분만 수정하면 된다.
- 클래스 단위로 모듈화시켜서 개발할 수 있으므로 대형 프로젝트처럼 여러 명, 여러 회사에서 프로젝트를 개발할 때 업무 분담이 쉬움.
- 객체지향의 단점
- 객체가 많으면 용량이 커질 가능성이 있다
- 처리 속도가 비교적 느리다
- 설계시 많은 시간과 노력이 필요하다
객체란 무엇일까요?
객체를 알기위해선 클래스라는 개념과 추상화에 대해 알아야 합니다. 아래의 예를 통해서 설명해 보겠습니다.
개발자가 과일의 특징을 다루는 프로그램을 만들고 싶다고 가정해 봅시다.
우선 프로그램에서 다루고 싶은 과일의 특징을 가지고 와서 클래스로 정의를 합니다.
이렇게 실제 현실세계에 존재하는 대상(과일)에서 내(개발자)가 다루고자하는 공통적이고 핵심적인 특성들만 뽑는 과정을 추상화라고 합니다.
그리고 추상화를 통해서 뽑아진 특징들을 하나로 묶어 만든 추상적인 틀을 클래스(Class)라고 합니다
예시에서 볼 수 있듯이 클래스는 과일의 무게와 색상 그리고 맛이라는 틀만 가지고 있을 뿐 내용물이 담겨있지 않습니다
즉, 클래스는 개념적으로만 존재하는 것 입니다.
개념적인 틀만 존재하는 클래스에 실제 내용물을 담아 실체화 한 것이 객체입니다.
객체는 클래스와 다르게 내용물이 담겨있는 실체입니다. 예시에서 볼 수 있듯이 사과 또는 레몬이 실체화한 객체라고 할 수 있습니다.
간혹 객체로서의 사과와 현실세계에 실재하는 사과의 개념이 헷갈릴 수 있습니다.
개체로서의 사과는 프로그램 상에서 다루고자 하는 특성만을 모은 클래스로부터 생성된 것으로 실제 사과와 동일하다고 볼 수는 없습니다.
객체지향의 4가지 특징
1. 추상화
- 객체에서 공통된 속성과 행위를 추출 하는 것
- 공통의 속성과 행위를 찾아서 타입을 정의하는 과정
- 추상화를 통해 불필요한 정보는 숨기고 필요한 정보만을 표현해서 간단한 프로그램을 만드는것이 목표
2. 캡슐화
- 데이터 구조와 데이터를 다루는 방법들을 결합 시켜 묶는 것 (변수와 함수를 하나로 묶는 것을 뜻함)
- 낮은 결합도를 유지할 수 있도록 설계하는 것
3. 상속
- 새로운 클래스가 기존의 클래스의 데이터와 연산을 사용할 수 있게 한다.
- 클래스의 속성과 행위를 하위 클래스에 물려주는 것을 뜻함.
장점
1. 재사용으로 인한 코드가 줄어든다
2. 범용적인 사용이 가능하다
3. 자료와 메서드의 자유로운 사용 및 추가가 가능하다
단점
1. 상위 클래스의 변경이 어려워진다
2. 불필요한 클래스가 증가할 수 있다
3. 상속이 잘못 사용될 수 있다
4. 다형성
- 하나의 변수명, 함수명이 상황에 따라 다른 의미로 해석 될 수 있는 것
- 어떠한 요소에 여러 개념을 넣어 놓는 것
객체 지향 프로그래밍은 하나의 클래스 내부에 같은 이름의 행위를 여러개 정의하거나 상위 클래스의 행위를 하위 클래스에서 재정의하여 사용할 수 있기 때문에 다형성이라는 특징을 갖게 된다.
오버라이딩
- 상위 클래스가 가지고 있는 메소드를 하위 클래스가 재정의해서 사용하는 것
오버로딩
- 같은 이름의 메서드가 인자의 개수나 자료형에 따라 다른 기능을 하는 것
SOLID 원칙 - 객체지향 설계원칙
1. 단일 책임 원칙 (Single Responsiblity Principle)
- 하나의 클래스는 단 하나의 책임만 가져야 한다.
- 단일 책임 원칙을 지키지 않을 경우 한 책임의 변경에 의해 다른 책임과 관련된 코드에 영향이 갈 수 있다.
2. 개방-폐쇄 원칙 (Open Closed Principle)
- 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.
- 기능을 변경하거나 확장할 수 있으면서 기능을 사용하는 코드는 수정하지 않는다.
3. 리스코프 치환 원칙 (Liskov Substitution Principle)
- 프로그램 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.
- 상위 타입의 객체를 하위 타입의 객체로 치환해도, 상위 타입을 사용하는 프로그램은 정상적으로 동작해야 한다.
4. 인터페이스 분리 원칙 (Interface Segregation Principle)
- 범용 인터페이스 하나보다 클라이언트를 위한 여러 개의 인터페이스로 구성하는 것이 좋다.
- 인터페이스는 인터페이스를 사용하는 클라이언트를 기준으로 분리해야 한다.
- 클라이언트가 필요로 하는 인터페이스로 분리함으로써 각 클라이언트가 사용하지 않는 인터페이스에 변경이 있어도 영향을 받지 않도록 만들어야 한다.
5. 의존 역전 원칙 (Dependency Inversion Principle)
- 추상화에 의존해야지 구체화에 의존하면 안된다.
- 고수준 모듈은 저수준 모듈의 구현에 의존해서는 안되고 저수준 모듈은 고수준 모듈에서 정의한 추상 타입에 의존해야 한다.
SOLID 예시 참고하기
https://mangkyu.tistory.com/194
참고
