객체지향 프로그래밍 (OOP)

객체의 개념

소프트웨어 객체는현실 세계의 객체를 필드와 메서드로 모델링 한것

상태를 필드, 동작을 메서드로 정의 한다. 필드는 객체 내부에 선언된 변수를, 메서드는 객체 내부에 정의된 동작을 의미한다.

 

객체지향의 주요 개념

 

캡슐화 (정보 은닉)

• 관련된 필드와 메서드를 하나의 캡슐처럼 포장해 세부 내용을 외부에서 알 수 없도록 감추는 것.
• 함께 코드를 재수정 없이 재활용하는 것. 관련된 기능과 특성을 한 곳에 모으고 분류하기 때문에 재활용이 원활해졌다.

상속

• 자녀가 부모 재산을 상속 받아 사용하듯이 상위 객체를 상속받은 하위 객체가 상위 객체의 메서드와 필드를 사용하는 것
• 부모클래스의 속성과 기능을 그대로 이어 받아 사용할 수 있게하고 기능의 일부분을 재정의 하여 사용할 수 있게 하는 것.
• 다중 상속은 불가능하다.

다형성

• 대입되는 객체에 따라서 메서드를 다르게 동작하도록 구현하는 기술. 실행 도중 동일한 이름의 다양한 구현체 중에서 메서드를 선택 가능하다. 
• 오버라이딩 : 부모 클래스의 메서드와 같은 이름, 매개변수 를 재정의하는 것.
• 오버로딩 : 같은 이름의 함수를 여러개 정의하고, 매개변수의 타입과 개수를 다르게 하여 매개변수에 따라 다르게 호출할 수 있도록 하는 것.

 

클래스 - 어떤 문제를 해결하기 위한 데이터를 만들기 위해 추상화 작업을 거쳐 집단에 속하는 속성과 행위를 변수와 메서드로 정의한 것

 

인스턴스(객체) - 클래스에서 정의한 것을 기반으로 실제 메모리상에 할당된 것으로 실제 프로그램에서 사용되는 데이터

 

객체지향 프로그래밍에서의 추상화

불필요한 정보는 숨기고 중요한 정보만을 표현함으로써 공통의 속성이나 기능을 묶어 이름을 붙이는 것.

(객체 지향 관점에서 클래스를 정의하는 것을 의미)

 

객체지향 프로그래밍의 장점

• 코드의 재사용에 용이하다 - 남이 만든 클래스를 가져와 이용할 수 있고 상속을 통한 확장성 또한 기대할 수 있음.
• 유지보수가 쉽다 - 객체지향 프로그램의 경우 수정해야 할 부분이 클래스 내부에 멤버 변수 혹은 메서드로 존재하기 때문에 해당 부분만 수정하면 된다.
• 대형 프로젝트에 적합하다 - 클래스 단위로 모듈화 시켜서 개발할 수 있으므로 대규모 프로젝트에 적합하다.

 

객체지향 프로그래밍의 단점

• 절차지향에 대비하여 처리속도가 상대적으로 느리다.
• 객체가 많을 경우 용량이 커지는 경우가 존재한다.
• 설계시 많은 시간과 노력이 필요하다.

 

SOLID 원칙?

 

객체지향 설계에서 지켜줘야 할 5개의 원칙을 말한다.

 

1. SRP (Single Resposibility Principle) 단일 책임 원칙

• 객체는 단 하나의 책임만 가져야 한다.
• 객체지향적으로 설계시 응집도를 높게, 결합도를 낮게 설계하는 것이 좋다.
• 메소드가 하나 존재하면 그 메소드는 명시된 기능만 딱 수행할 수 있게끔 구성하는 것이 좋은 것이다.
• 한 객체에서 책임이 많아 질 수록 클래스 내부에서 서로 다른 역할을 수행하는 코드끼리 강하게 결합하게된다. 즉 시스템의 결합도가 높아져 복잡하게 구성된다.
• 결론적으로 여러 객체들이 하나의 책임만 갖도록 잘 분배한다면, 시스템에 변화가 생겨도 그 영향을 최소화 할 수 있다.

 

2. OCP (Open-Closed Principle) 개방-폐쇄 원칙

• 기존의 코드를 변경하지 않으면서(close), 기능을 추가할 수 있도록 (open) 설계가 되어야 한다.
• 캡슐화를 통해 여러 객체에서 사용하는 같은 기능을 인터페이스에 정의하는 방법이 존재 한다.

3. LSP (Liskov Substitution Principle) 리스코프 치환 원칙

• 자식 클래스는 최소한 자신의 부모 클래스에서 가능한 행위는 수행할 수 있어야 한다는 설계 원칙.
• 즉 자식 클래스는 항상 부모 클래스의 역할을 대체할 수 있어야 한다. 부모 클래스와 자식 클래스의 행위가 일관되어야 한다는 의미.
• 자식 클래스는 부모 클래스의 책임을 무시하거나 재정의 하지 않고 확장만 수행하도록 하는 방법이다. -> 오버라이드를 가급적 피하자.

4. ISP (Interface Segregation Principle) 인터페이스 분리 원칙

• 자신이 사용하지 않는 인터페이스는 구현하지 않아야 한다는 설계 원칙.
• 하나의 거대한 인터페이스 보다 여러 개의 구체적인 인터페이스가 더 낫다.
• SRP가 객체의 단일 책임을 뜻한다면, ISP는 인터페이스의 단일 책임을 의미한다.
• 자신이 사용하지 않는 메소드에 대하여 영향력을 줄이는 방법.

5. DIP (Dependency Inversion Principle) 의존 역전 원칙

• 객체들이 서로 정보를 주고 받을 때 생기는 의존관계를 객체들이 나름대로의 원칙을 갖고 정보를 주고 받아야 한다는 설계 원칙
• 추상성이 낮은 클래스보다 추상성이 높은 클래스와 의존 관계를 맺어야 한다. 일반적으로 인터페이스를 사용하면 이원칙을 준수할 수 있다.

 

Design Pattern

Singleton Pattern

싱글톤 패턴이란, 인스턴스가 프로그램내에서 오직 하나만 생성되는 것을 보장하고 프로그램 내부 어디에서든 인스턴스에 접근할 수 있도록 하는 패턴. 즉 인스턴스가 사용될 때 똑같은 인스턴스 여러개가 아니라 기존에 생성한 하나의 인스턴스를 사용하는 것.