객체 지향 프로그래밍(OOP)
객체 지향 프로그래밍이란
예전에는 순서대로 일어나는 일을 시간순으로 프로그래밍하는 절차지향 프로그래밍을 많이 했다.
하지만 점점더 복잡한 어플리케이션에 대한 수요가 증가함으로 이러한 프로그래밍의 한계가 나오기 시작했다. 복잡한 어플리케이션을 만들기 위해서는 실제 세계처럼 더 밀접한 모델링 방식이 필요했기 때문이다.
이를 위해 나타난 방식이 객체 지향 프로그래밍(Object Oriented Programming)이다.
객체 지향 프로그래밍은 컴퓨터 프로그램을 명령어의 목록으로 보는 시각에서 벗어나 여러 개의 독립된 단위, ‘객체’들의 상호작용으로 프로그램 로직을 구성하는 프로그래밍이다.
이하 OOP의 핵심은 객체와 클래스라고 할 수 있다. 실제 세상의 객체와 마찬가지로 객체에는 두 가지 중요한 특성이 있다.
- 데이터
객체의 속성과 상태를 나타낼 수 있다.
- 행동
스스로 변화하고 다른 객체와 통신 할 수 있는 능력이다.
OOP의 구조
- 클래스
클래스는 개별 객체, 속성 및 메서드에 대한 청사진 역할을 하는 사용자 정의 데이터 유형이다.
사람을 예로 들면 속성이란 눈, 코, 입, 손, 발, 등의 신체들을 의미한다.
사람, 책 같은 객체들이 공통적으로 갖는 속성들을 모아서 정의내린 것을 클래스라고 생각하면 된다.
- 객체
객체는 클래스의 인스턴스이다. 붕어빵과 붕어빵 기계라고 생각하면 쉽다.
붕어빵을 찍어내는 기계는 붕어빵이라는 객체들을 생성하기 위한 틀을 제공한다.
그래서 붕어빵 찍는 기계는 클래스라 표현할 수 있고, 붕어빵 틀에서 만들어진 붕어빵들은 각각이 객체가 된다.
- 메서드
객체의 동작을 설명하는 클래스 내부에 정의된 함수이다.
재사용 또는 기능을 한 번에 하나의 객체 내부에 캡슐화한 상태로 유지하기 위해 사용한다.
- 속성
클래스 템플릿에 정의되며 객체의 상태를 나타낸다.
객체 안에 있는 어떤 (public이 아닌) 값을 수정하려면 get이나 set으로 시작하는 메서드를 정의해줘야 한다. 보통 이 과정을 조금 더 정교하고 보기 좋게 (마치 public한 값을 다루는 것처럼) 만든 것이 property이다.
OOP의 4가지 특성
객체 지향 프로그래밍의 4가지 주요 특성은 다음과 같다.
캡슐화
캡슐화는 관련이 있는 변수와 함수를 하나의 클래스로 묶고 외부에서 쉽게 접근하지 못하도록 은닉하는 것이다.
객체의 직접적인 접근을 막고 외부에서 내부의 정보에 직접접근하거나 변경할 수 없고 객체가 제공하는 필드와 메소드를 통해서만 접근이 가능하다.
- 캡슐화된 객체의 세부 내용이 외부에 드러나지 않아, 변경이 발생할때 오류의 파급효과가 적다.
- 개체들의 재사용이 용이하다.
- 객체들 간 메시지를 주고받을 때 각 객체의 세부 내용은 알 필요가 없으므로 인터페이가 단순해지고, 객체 간 결합도가 낮아진다.
추상화
객체는 불필요한 구현 코드를 숨기고 다른 객체의 사용과 관련된 내부 메커니즘만 드러낸다. 파생 클래스는 기능을 확장할 수 있다.
추상화는 인터페이스로 클래스들의 공통적인 특성(변수, 메소드)들을 묶어 표현한다.
- 인터페이스와 구현을 분리함으로서, 객체가 가진 특성 중 필수 속성만드로 객체를 묘사하고 유사성만을 표현하며 세부적인 상세 사항은 각 객체에 따라 다르게 구현되도록 할 수 있다.
상속
상속은 하나의 클래스가 부모 클래스의 속성과 메소드를 얻게 되는 방법이다.
기존 클래스를 수정하지 않으면서 이미 정의되어 있는 내용을 확장해서 사용할 수 있는 방법을 제공한다.
- 상속을 받는 자식클래스는 부모클래스의 특성과 기능을 사용할 수 있다.
- 기능의 일부분을 변경하는 경우, 자식클래스에서 수정하여 사용할 수 있다.
- 캡슐화를 유지하므로, 클래스의 재사용을 용이하게 만들어준다.
다형성
같은 형태이지만 다른 기능을 하는것을 의미한다.
동일한 이름을 가진 여러 형태의 메소드를 만들 수 잇다.
- 오버로딩
같은 이름의 메소드를 여러개 가지면서 매개변수의 유형과 개수가 다른것
- 오버라이딩
상위 크래스가 가지고 있는 메소드를 하위 클래스에서 재정의 하는것
OOP의 장점
- 모듈성
캡슐화 특성을 통해 문제 해결 및 공동 개발이 더 쉬워진다.
- 재사용 성
상속을 통해 코드를 재사용할 수 있다. 팀이 동일한 코드를 여러 번 작성할 필요가 없어진다.
- 생산력
여러 라이브러리와 재사용 가능한 코드를 사용하여 새 프로그램을 더 빠르게 구성할 수 있다.
- 쉬운 업그레이드 및 확장
프로그래머는 시스템 기능을 독립적으로 구현하여 쉽게 업그레이드하고 확장할 수 있다.
- 보안
캡슐화 및 수상화를 사용하여 복잡한 코드를 숨기고 소프트웨어 유지 관리를 더 쉽게할 수 잇다.
- 유연성
다형성을 사용하면 단일 함수가 해당 클래스에 적용할 수 있다. 다른 객체도 동일한 인터페이스를 통과할 수 있다.
OOP의 단점
프로그램 설계 시, 많은 노력과 시간을 투자해야 한다.
다른프로그램보다 크기가 크다.
다른 프로그램보다 느리다.
익숙해지는데 시간이 걸린다.
OOP의 5원칙, SOLID
CLean Code의 저자, 로버트 마틴이 객체 지향 프로그래밍 및 설계의 다섯 가지 기본 원칙을 마이클 패더스가 SOLID라는 약어로 소개한 것이다.
단일 책임 원칙, SRP(Single Responsiblity Principle)
- 하나의 클래스는 하나의 책임만 가져야 한다. 클래스는 그 책임을 완전히 캡슐화해야 함을 말한다.
- 어떤 변화에 의해 클래스를 변경해야 하는 이유는 오직 하나뿐이어야 함을 의미한다.
개방-페쇄 원칙, OCP(Open-Closed Principle)
- 확장에는 열려있고, 변경에는 닫혀있다. 기존의 코드는 변경하지 않으면서(Closed), 기능을 추가할 수 있도록(Open) 설계해야 한다.
- OCP는 강한 응집도와 낮은 결합도를 유지시킨다.
리스코프 치환 원칙, LSP(Liskov Substitution Princple)
- 객체는 프로그램의 정확성을 깨지 않으면서, 하위 타입의 인스턴스로 바꿀 수 있어야 한다.
- 이를 위해서 하위 타입의 객체는 상위 타입의 책임을 무시하거나 재정의 하지 않고 확장만 수행하도록 설계하여야 한다.
인터페이스 분리 원칙, ISP(Interface Segregation Principle)
- 하나의 범용적인 인터페이스보다 여러 개의 구체적인 인터페이스가 좋다는 원칙이다.
의존관계 역전 원칙, DIP(Dependency Inversion Principle
- 의존 관계를 맺을 때 변화하기 쉬운 것, 자주 변화하는 것보다는 변화하기 어려운것, 거의 변화가 없는 것에 의존하라는 원칙이다.
- 즉, 구체적인 클래스(구체화)보다 인터페이스나 추상 클래스(추상화)에 의존하라는 뜻이다.
참조
https://howtodoinjava.com/java/oops/object-oriented-programming/
https://velog.io/@vincentj2/JAVA-OOP란
https://www.techtarget.com/searchapparchitecture/definition/object-oriented-programming-OOP