OOP 객체지향 프로그래밍
클래스
클래스는 객체지향 프로그래밍에서 특정 객체를 생성하기 위해 변수와 메소드를 정의하는 일종의 틀이다.
객체를 정의하기 위한 상태(멤버변수)와 메소드(함수)로 구성된다.
객체
클래스에서 정의한 것을 토대로 메모리(실제 저장공간)에 할당된 것으로 프로그램에서 사용되는 데이터 또는 식별자에 의해 참조되는 공간을 의미하며, 변수, 자료 구조, 함수 또는 메소드가 될 수 있다.
프로그래밍 언어는 변수를 이용해 객체에 접근하므로 객체와 변수라는 용어는 종종 함께 사용된다.
그러나 메모리가 할당되기 전까지 객체는 존재하지 않는다.
객체지향 프로그래밍에서 객체는 클래스의 인스턴스다. 클래스 객체는 자료와 그 자료를 다루는 명령의 조합을 포함하여 객체가 메시지를 받고 자료를 처리하며 메시지를 다른 객체로 보낼 수 있도록 한다.
정의
Object-Oriented Programming
컴퓨터 프로그래밍의 패러다임 중 하나
FROM 컴퓨터 프로그램을 명령어의 모임으로 보는 시각
TO 여러 개의 독립된 단위인 객체들의 모임으로 보는 시각
이 때 각각의 객체는 메시지를 주고받고, 데이터를 처리할 수 있다.
객체지향 프로그래밍은 프로그램을 유연하고 변경이 용이하게 만들기 때문에 대규모 소프트웨어 개발 시 많이 사용된다.
또한, 프로그래밍을 더 배우기 쉽게 하고 소프트웨어 개발과 보수를 간편하게 하며, 직관적인 코드 분석을 가능하게 한다는 장점 역시 가지고 있다.
하지만 지나치게 프로그램을 객체화하는 경향은 실제 세계의 모습을 그대로 반영하지 못한다는 비판을 받기도 한다.
특징
- 추상화(*)
- 캡슐화(*)
- 상속(*)
- 다형성(*)
---------객체지향 대표적 특징 4가지 - 동적 바인딩
추상화
불필요한 정보는 숨기고 중요한 정보만을 표현함으로써 프로그램을 간단히 만드는 것
캡슐화
변수와 메소드를 하나로 묶어서
외부로부터 실제 구현 내용을 감추는 것
데이터를 외부에서 직접 접근하지 못하도록 하고
함수를 통해서만 접근하도록 하는 것
캡슐화된 멤버를 노출시킬 것인가 아닌가는 접근 지정자를 사용
접근 지정자
- public: 클래스 외부에서 접근 가능
- private: 클래스 내부에서만 접근 가능
- protected: 상속받은 자식 클래스에서만 접근 가능
상속
새로운 클래스가 기존의 클래스의 자료와 연산을 이용할 수 있게 하는 기능
상속을 이용하면
1) 프로그램의 요구에 맞추어 클래스를 수정할 수 있고
2) 클래스 간의 종속 관계를 형성함으로써 객체를 조직화할 수 있음
다중 상속
클래스가 2개 이상의 클래스로부터 상속받을 수 있게 하는 기능
-
클래스들의 기능이 동시에 필요할 때 용이
-
하지만 클래스의 상속 관계에 혼란을 줄 수 있고 (예: 다이아몬드 상속) 프로그래밍 언어에 따라 사용 가능 유무가 다르므로 주의해서 사용해야 함.
-
Java는 지원하지 않는다. (다중 상속을 사용하고 싶은 경우 class가 아닌 interface를 이용하자)
다형성
어떤 한 요소에 여러 개념을 넣어 놓는 것으로 일반적으로 오버라이딩이나 오버로딩을 의미
다형 개념을 통해서 프로그램 안의 객체 간의 관계를 조직적으로 나타낼 수 있다.
- 오버로딩 ( Overloading ): 하나의 클래스에서 메소드의 이름이 같지만 파라미터는 다른 것
- 오버라이딩 ( Overriding ): 부모 클래스의 메소드를 자식 클래스의 용도에 맞게 재정의해서 코드의 재사용성을 높임
동적 바인딩
동적 바인딩은 실행 시간 중에 일어나거나 실행 과정에서 변경될 수 있는 바인딩으로 컴파일 시간에 완료되어 변하지 않는 정적 바인딩과 대비되는 개념이다.
동적 바인딩은 프로그램의 한 개체나 기호를 실행 과정에 여러 속성이나 연산에 바인딩함으로써 다형 개념을 실현한다.
장점
소프트웨어의 질을 향상하기 위해 강한 응집력(Strong Cohesion)과 약한 결합력(Weak Coupling)을 지향해야 한다.
OOP의 경우 하나의 문제 해결을 위한 데이터를 클래스에 모아 놓은 데이터형을 사용함으로써 응집력을 강화하고, 클래스간에 독립적인 디자인을 함으로써 결합력을 약하게 한다.
단점
프로그램을 설계할 때 많은 고민과 시간을 투자해야 한다.
원칙 SOLID
SRP ( Single Responsibility Principle )
단일 책임 원칙
한 클래스는 하나의 책임만 가져야 한다.
변경을 기준으로 둬서 변경이 있을 때 파급 효과가 적으면 단일 책임 원칙을 잘 따른 것.
예) UI 변경, 객체의 생성과 사용을 분리
OCP ( Open-Closed Principle )
개방-폐쇄 원칙
확장에는 열려있으나, 변경에는 닫혀있어야 한다.
LSP ( Liskov's Substitution Principle )
리스코프 치환 원칙
프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.
예) 자동차 인터페이스의 엑셀은 앞으로 가는 기능으로 만들어야 하며 뒤로 가게 구현하면 LSP를 위반한 것
ISP ( Interface Segregation Principle )
인터페이스 분리 원칙
특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.
DIP ( Dependency Inversion Principle )
의존관계 역전 원칙
추상화에 의존해야 하고 구체화에 의존하면 안된다.
쉽게 이야기해서 구현 클래스에 의존하지 말고, 인터페이스에 의존하라는 것.
참고 사이트
