객체지향이란?
객체지향(Object-Oriented)은 컴퓨터 프로그래밍에서 널리 사용되는 패러다임 중 하나로 프로그램을 객체들의 집합으로 모델링하여 설계하고 프로그래밍하는 방법론입니다. 이는 소프트웨어의 재사용성, 확장성, 유지관리성을 향상 시키기 위해 만들어졌습니다.
핵심개념에는 클래스, 객체, 상속, 다형성, 캡슐화, 추상화등이 있습니다.
4가지 특징
- 추상화(Abstraction)
복잡한 실제 상황을 간단한 모델로 표현하는 것. 필요한 정보만을 추출하여 프로그램의 복잡도를 관리하게 해줍니다. 불필요한 부분을 제거함으로써 필요한 핵심만 나타낸 것이라고 볼 수 있다. 흔히 일반화, 단순화라고 여겨 질수 있습니다. 이를 사용하는 이유는 복잡성을 낮추기 위함입니다.
- 다형성(Polymorphism)
다양한 형태를 가질 수 있는 것을 다형성이라 함. 쉽게 설명하면 하나의 타입으로 다양한 객체를 참조하는 것을 다형성이라합니다.
- 캡슐화(Encapsulation)
객체 내부의 세부사항을 외부로부터 감추는 것. 목적은 인터페이스만 공개하여 변경하기 쉬운 코드를 만들기 위해서 입니다.
- 상속(Inheritance)
부모로부터 물려 받은 것을 말합니다.
객체지향 5가지 설계 원칙
객체지향 설계의 5가지 기본 원칙, 일명 SOLID 원칙은 소프트웨어 개발 과정에서 유지보수가 용이하고, 확장이 가능하며, 견고한 애플리케이션을 설계하기 위해 고안되었습니다. 이 원칙들은 다음과 같습니다
1. 단일 책임 원칙(Single Responsibility Principle, SRP): 각 클래스는 하나의 기능만 가지며, 클래스가 변경되어야 하는 이유는 단 하나여야 합니다. 이 원칙은 클래스를 변경할 때 그 변경이 가능한 한 적은 다른 클래스에 영향을 미치도록 하는 것을 목표로 합니다.
2. 개방-폐쇄 원칙(Open-Closed Principle, OCP): 소프트웨어 구성 요소(클래스, 모듈, 함수 등)는 확장에 대해서는 열려 있어야 하지만, 수정에 대해서는 닫혀 있어야 합니다. 즉, 기존의 코드를 변경하지 않고도 구성 요소의 기능을 확장할 수 있어야 합니다.
3. 리스코프 치환 원칙(Liskov Substitution Principle, LSP): 부모 클래스의 인스턴스를 자식 클래스의 인스턴스로 대체(치환)해도, 프로그램의 정확성에 영향을 미치지 않아야 합니다. 이 원칙은 상속을 사용할 때 유의해야 하며, 상속받은 클래스는 부모 클래스의 책임을 완전히 이행해야 함을 의미합니다.
4. 인터페이스 분리 원칙(Interface Segregation Principle, ISP): 클라이언트는 자신이 이용하지 않는 메소드에 의존하면 안 됩니다. 즉, 하나의 일반적인 인터페이스보다는 몇 개의 구체적인 인터페이스가 더 낫다는 원칙입니다. 이를 통해 필요하지 않은 의존성을 줄일 수 있습니다.
5. 의존성 역전 원칙(Dependency Inversion Principle, DIP): 고수준 모듈은 저수준 모듈에 의존해서는 안 되며, 이 둘은 추상화에 의존해야 합니다. 또한, 추상화는 세부 사항에 의존해서는 안 되며, 세부 사항은 추상화에 의존해야 합니다. 이 원칙은 구체적인 클래스보다는 인터페이스나 추상 클래스와의 의존 관계를 선호함으로써 유연성을 높이는 것을 목적으로 합니다.
SOLID 원칙을 따르면, 소프트웨어는 더욱 견고하고, 유연하며, 유지보수가 쉬운 코드가 됩니다. 이 원칙들은 객체지향 설계의 핵심이며, 효과적인 시스템 아키텍처를 구축하는 데 있어 중요한 지침을 제공합니다.
객체지향 패러다임
- 적절한 객체에게 적절한 책임을 할당하여 서로 메시지를 주고 받으며 협력하도록 하는 것
- 배경: 점점 증가하는 SW 복잡도를 낮추기 위해 객체지향 패러다임이 나타남.
- 중요 포인트
- 클래스가 아닌 객체에 초점을 맞추는 것
- 객체들에게 얼마나 적절한 역할과 책임을 할당하는지가 중요
High Cohesion, Loose coupling
객체지향 설계에서 "High Cohesion(높은 응집도)"와 "Loose Coupling(느슨한 결합도)"은 소프트웨어의 품질과 유지보수성을 높이는 중요한 원칙입니다. 이 두 원칙은 서로 보완적인 관계에 있으며, 함께 적용될 때 소프트웨어의 설계와 구조가 크게 개선될 수 있습니다.
High Cohesion (높은 응집도)
응집도는 모듈 내부의 요소들이 얼마나 밀접하게 관련되어 있는지를 나타내는 지표입니다. 높은 응집도를 가진 모듈은 잘 정의된 목적이 있으며, 해당 목적과 밀접하게 관련된 작업만을 수행합니다. 모든 기능이 그 목적에 집중되어 있기 때문에, 코드를 이해하기 쉽고, 재사용성이 높아지며, 유지보수가 용이해집니다.
예를 들어, 계산기 클래스가 있을 때, 덧셈, 뺄셈, 곱셈, 나눗셈과 같은 기능들만을 포함시키는 것이 높은 응집도의 예입니다. 이러한 클래스는 계산과 관련된 명확한 목적을 가지며, 그 목적에만 집중합니다.
Loose Coupling (느슨한 결합도)
결합도는 하나의 모듈이 다른 모듈에 얼마나 의존하고 있는지를 나타내는 지표입니다. 느슨한 결합도를 가진 시스템에서는 각 모듈이나 클래스가 서로 독립적으로 동작할 수 있으며, 다른 모듈과는 최소한의 연결만을 가집니다. 이를 통해 한 부분의 변경이 다른 부분에 미치는 영향을 최소화하고, 각 모듈의 재사용성을 높일 수 있습니다.
예를 들어, 데이터베이스와 통신하는 클래스가 있다면, 이 클래스는 특정 데이터베이스 기술에 직접적으로 의존하기보다는 일반화된 인터페이스를 통해 데이터베이스와 통신해야 합니다. 이렇게 하면 나중에 다른 종류의 데이터베이스로 교체하더라도, 데이터베이스 통신 클래스를 변경하지 않고도 교체할 수 있습니다.
함께 적용하기
높은 응집도와 느슨한 결합도는 함께 적용될 때 가장 효과적입니다. 각 모듈이나 클래스가 명확하고 구체적인 목적을 가지며 (높은 응집도), 동시에 다른 모듈과의 의존성을 최소화하도록 설계되면 (느슨한 결합도), 전체 시스템은 유연하고 확장 가능하며, 오류를 발견하고 수정하기 쉬운 구조를 갖게 됩니다. 이러한 설계 원칙을 따르는 것은 장기적으로 소프트웨어의 품질을 향상시키고, 개발 비용을 절감하는 데 크게 기여합니다.
객체지향 프로그래밍 시 고민해야 할 것들
- 도메인을 구성하는 객체에는 어떤것들이 있는지 고민
- 객체들 간의 관계를 고민
- 동적인 객체를 정적인 타입으로 추상화해서 도메인 모델링 하기
- 협력을 설계
- 객체들을 포괄하는 타입에 적적할 책임을 할당
- 구현하기
'여러가지 > 이것저것' 카테고리의 다른 글
[OOP] 음식 주문하기 (0) | 2024.04.04 |
---|---|
[OOP]사칙연산 계산기 (1) | 2024.04.04 |
AMQP? (0) | 2024.04.03 |
MQTT? (0) | 2024.04.03 |
커널(Kernel) (0) | 2024.03.22 |