팀 프로젝트 - CS (객체지향 프로그래밍)

🧩 객체지향 프로그래밍

🧩 일정

• 09.13 ~ 09.23

💊객체지향프로그래밍(OOP) 이란?

▶ 프로그래밍에서 필요한 데이터를 추상화 시켜 상태와 행위를 가진 객체로 만들고, 객체들간의 상호작용을 통해 로직을 구성하는 프로그래밍 방법이다
     -> 모든 데이터를 객체취급하며, 처리요청을 받은 객체는 객체 그 안의 기능을 사용해 요청을 처리합니다.

💊 객체지향 프로그래밍 장 · 단점

장점
① 코드 재사용이 용이
     => 기존에 만들어진 클래스를 재사용할 수 있고 상속을 통해 확장 가능
② 유지 보수가 편리
     => 수정해야 할 부분이 클래스 내부에 있으므로 해당 부분만 수정하면 됨.
③ 대형 프로젝트에 적합
     => 클래스 단위로 모듈화시켜서 개발 -> 업무 분담의 편리성 향상

단점
① 처리속도가 상대적으로 느림
② 객체의 수 증가 -> 용량이 커질 수 있음
③ 설계시 많은 시간과 노력이 필요
   => 좋은 객체를 만드는 것을 다른 말로 설계를 잘하는 법이라고 할 수 있는데, 좋은 설계는 현실을 잘 반영해야 한다.

---

🧩 객체 지향의 4요소

💊추상화

• 추상화 란?
  ▶ 객체 지향 관점에서의 추상화는 클래스를 정의할 때, 불필요한 부분들을 생략하고 객체의 속성 중 중요한 것에만 중점을 두어 개략화 하는     것, 즉 클래스들의 중요하고 공통된 성질들을 추출하여 슈퍼 클래스를 선정하는 개념이다.
  ▶ 객체들이 공통적으로 필요로 하는 속성이나 동작을 하나로 추출해내는 작업
  ▶ 불필요한 정보는 숨기고 중요한 정보만을 표현함으로써 프로그램을 간단하게 만드는것
  
• 추상화를 왜 하는가?
  ▶ 추상화를 통해 잘 설계했다면 여러개의 클래스를 정의했을 때, 중복 코드가 현저히 줄어들 것 이다.
       -> 코드가 간결해지기 때문에 생산성 증가, 가독성 증가, 에러 감소, 유지 보수시 시간 단축 등의 효과!
       -> 잘 만들어진 슈퍼 클래스 덕분에 코드의 재사용성이 증가한다.

💊인터페이스

추상 클래스와 유사하게 인터페이스를 구현한 클래스들에게 강제함으로써,
통일성과 일관성을 지원한다.
또한, 서로 관련 없는 클래스들끼리에 매게역할을 할수 있다.

• 구현 가능한 구성요소
  public static final 상수
  추상 메서드(abstract 키워드 생략가능)
  default 메서드 - 하위 호환성을 유지하고 인터페이스의 보완을 진행할 수 있습니다.
  static 메서드

• 특징
  추상 메서드를 가지고 있기 때문에 객체 생성 불가
  하위 클래스에서 인터페이스의 추상메서드를 재정의 해야한다.
  클래스에 다중 구현을 지원하다.
  인터페이스간에 다중 상속을 지원한다.

• 추상클래스 vs 인터페이스
  ▶ 추상 클래스는 추상 메소드뿐만 아니라 생성자, 필드, 일반 메소드도 포함할 수 있지만 인터페이스는 오로지 추상 메소드와 상수만을     포함할 수 있다.
  ▶ 그럼 추상클래스만 쓰지 인터페이스를 왜 써? 왜? why? -> 자바는 클래스를 통한 다중 상속은 지원하지 않지만 클래스와 인터페이스를     통한 다중 상속은 지원하기 때문!
  ▶ 추상클래스나 인터페이스에 구현한 추상메소드들은 상속받는 클래스들에게 강제성을 부여! -> 꼭 오버라이딩 해서 사용해야만 함.

---

💊캡슐화

• 캡슐화 란?
  ▶ 정보 은닉화를 통해 높은 응집도, 낮은 *결합도를 유지할 수 있도록 설계하는 것 
   → 한 곳에서 변화가 일어나도 다른 곳에 미치는 사이드 이펙트를 최소화 시키는 것을 의미
         결합도: 어떤 기능을 실행할 때 다른 클래스나 모듈에 얼마나 의존적인지를 나타내는 지표 
  ▶ 외부에서 접근할 필요가 없는 것들은 접근 지정자 private을 사용하여 접근을 제한

• 캡슐화를 왜 하는가?
  ▶ 사용자가 불필요한 부분을 접근하지 못하게 하여, 객체의 오용을 방지 할 수 있습니다. (항상 개발자와 사용자가 다를 수 있음을 기억해야 합니다.)
  ▶ 객체의 내부가 바뀌어도 그 객체의 사용방법이 바뀌지 않습니다. (사용자는 객체 내부가 바뀌어도 같은 결과를 기대 할 수 있습니다.)
  ▶ 객체 내부에서 사용되는 데이터가 바뀌어도 다른 객체에게 영향을 주지 않습니다. (각 객체들의 독립성이 유지됩니다.)
  ▶ 객체간의 결합도가 낮아지게 됩니다. (객체간의 결합도를 낮추는 일은 객체 설계의 기본 원칙입니다.)
  ▶ 큰 시스템 일지라도 컴포넌트 별로 작게 분리하여 개발이 가능하게 됩니다. 이로 인하여 시스템 개발 속도를 높이고 성능을 최적화 하기가 쉽습니다

---

💊상속

• 상속이란?
  ▶ 클래스의 속성과 행위를 하위 클래스에 물려주거나 하위 클래스가 상위 클래스의 속성과 행위를 물려받는 것
       → 자식 클래스를 외부로부터 은닉하는 캡슐화의 일종
  ▶ 새로운 클래스가 기존의 클래스의 데이터와 연산을 이용할 수 있게 하는 기능 

장점
① 자식 클래스를 캡슐화해두면, 외부에선 개별적인 자식 클래스들과 무관하게 개발 가능
② 상위 클래스의 구현을 활용함으로써, 코드 재사용성이 용이

단점
① 부모 클래스의 변경이 어려움 → 의존하는 자식 클래스들이 영향을 받음
② 불필요한 클래스의 증가 
③ 잘못된 상속 사용 → 상속받는 클래스가 부모클래스와 IS-A 관계가 아닐 때 발생
◎상속은 재사용 관점에서 사용하면 안됨

• 상속을 왜 하는가?
  ▶ 적은 양의 코드로 새로운 클래스를 작성 가능
  ▶ 코드를 공통적으로 관리하기 때문에 여러 코드의 추가 및 변경이 용이
  ▶ 중복을 제거해서 생산성과 쉬운 유지보수성에 크게 기여
  ▶ 가장 큰 이유는 코드의 재사용이다

---

💊다형성

• 다형성이란
  ▶ 서로 다른 클래스의 객체가 같은 동작을 수행할 때, 각자의 특성에 맞는 방식으로 동작하는것
  ▶ 객체 지향 프로그래밍은 하나의 클래스 내부에 같은 이름의 행위를 여러 개 정의하거나 상위 클래
  스의 행위를 하위 클래스에서 재정의하여 사용할 수 있음

① 오버라이딩 : 상위 클래스가 가지고 있는 메소드를 하위 클래스가 재정의해서 사용하는 것
② 오버로딩 : 같은 이름의 메서드가 인자의 개수나 자료형에 따라 다른 기능을 하는 것

• 다형성을 사용하는 이유
  ▶ 상속과 메서드 재정의를 활용하여 확장성 있는 프로그램ㅇ을 만들 수 있다
  ▶ 그렇지 않은 경우 많은 if-else if문이 구현되고 코드의 유지보수가 어렵다
  ▶ 상위 클래스에서는 공통적인 부분을 제공하고 하위 클래스에서는 각 클래스에 맞는 기능을 구현합니다.
  ▶ 여러 클래스를 하나의 타입(상위클래스)으로 핸들링할 수 있습니다.

---

🧩객체 지향의 5원칙 : SOLID

💊S (SRP : Single Responsibility Principle)단일 책임 원칙

▶ 모든 클래스는 각각 하나의 기능만 가진다.
▶ 단일 책임 원칙을 지키지 않을 경우 한 책임의 변경에 의해 다른 책임과 관련된 코드에 영향이 갈 수 있다.

예시 - 아래 남자 클래스를 보면 그냥 보아도 이 사람이 해야 할 역할, 책임이 매우 많은 것을 볼 수있습니다

즉, 하나의 클래스가 2가지 이상의 책임을 가지게 되면 클래스의 목적이 모호해지고 기능을 수정할 때 영향을 받는 범위도 커져서 유지보수가 힘들어지게 된다.
=> 역할을 분리한다

그래서 위처럼 남자라는 것을 각 역할에 맞게 잘 분리하면 역할과 책임이 알맞게 잘 분리된 것을 볼 수 있습니다.

💊O (OCP : Open/Closed Principle)개방/폐쇄 원칙

▶ 소프트웨어의 모든 구성요소(클래스, 모듈, 함수)는 확장에는 열려있고, 변경에는 닫혀 있어야 한다
▶ 기능을 변경하거나 확장할 수 있으면서 기능을 사용하는 코드는 수정하지 않는다.
▶ 개방-폐쇄 원칙은 추상화와 상속을 통해 구현해낼 수 있음

예시 - 마티즈를 운전하던 운전자가 소나타로 차를 바꾸게 될 때 운전자는 어떻게 될까?

위의 그림을 보면 운전자가 기어가 수동 or 자동이냐에 따라 행동이 달라지는 것을 볼 수 있는데요. 이렇게 어떤 변화가 있을 때 바로 운전자에게 영향이 오기 때문에 이러한 설계는 개방 폐쇄 원칙에 위배됩니다.

이렇게 상위 클래스 또는 인터페이스를 중간에 둠으로써 다양한 자동차가 생긴다고 해도 객체 지향 세계의 운전자는 운전 습관에 영향을 받지 않게 됩니다. 다양한 자동차가 생긴다고 하는 것은 자동차 입장에서는 자신의 확장에는 개방되어 있는 것이고, 운전자 입장에서는 주변의 변화에 폐쇄돼 있는 것입니다.

💊L (LSP : Liskov’s Substitution Principle)리스코프 대체 원칙

▶ 부모 클래스를 카리키는 포인터에 해당 클래스를 상속하는 자식 클래스를 할당하더라도 모든 기능이 정상적으로 작동해야 한다
▶ 프로그램 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.
-> 리스코프 치환 원칙을 지키지 않으면 개방 폐쇄 원칙을 위반하게 됨

예시

경찰차도, 오픈카도 자동차의 기본적인 도로주행 역할을 그대로 수행할 수 있다.
하지만 갑자기 '비행기'가 자동차의 파생이라고 하면 말이 안된다..

💊I (ISP : Interface Segregation Principle)인터페이스 분리 원칙

▶ 자신이 사용하지 않는 인터페이스는 구현하지 말아야 한다는 원칙
▶ 범용 인터페이스 하나보다 클라이언트를 위한 여러 개의 인터페이스로 구성하는 것이 좋다.
▶ 인터페이스는 인터페이스를 사용하는 클라이언트를 기준으로 분리해야 한다.

예시

위 그림에서는 자동차를 상속받아 저가형 자동차, 고급형 자동차라는 클래스를 정의하였습니다.
저가형 자동차에서는 드라이브모드_변경() 이라는 메소드는 사용되지 않지만, 상속을 하였기 때문에 어쩔 수 없이 구현이 된 상태입니다. 이를 인터페이스 분리 원칙에 맞게 변경하면 다음과 같습니다.

이렇게 되면, 저가형 자동차, 고급형 자동차 모두 자신이 필요한 인터페이스만 구현하게 되었습니다
그런데, 이대로 설계를 진행한다면, 1번의 단일책임원칙에 위배됩니다. 저가형 자동차는 {시동, 속도} 2가지 책임, 고급형 자동차는 {시동, 속도, 드라이브모드} 3가지 책임을 갖게 됩니다. 그래서 인터페이스 분리 원칙에서는 복수의 책임을 갖는것을 허용하게 되어 단일책임원칙과 함께 적용될 수 없습니다.
그래서 프로젝트의 상황에 따라, 단일책임원칙과, 인터페이스 분리 원칙을 선택하여 설계해야 합니다. 이 원칙에 따라 설계한다면, 불필요한 인터페이스가 줄어들어 효율적으로 인터페이스를 사용할 수 있습니다.

💊D (DIP : Dependency Inversion Principle) 의존성 역전 원칙

▶ 상위 모듈은 하위 모듈에 의존해서는 안된다.둘 다 추상화에 의존해야한다.
▶ 추상 클래스나 인터페이스에 의존해야지 구체화에 의존하면 안된다.

예시

차종이 바뀌어도, 운전하는 방법은 동일하다.
소나타 타던 사람이 테슬라로 차를 바꾼다고 면허를 다시 따지 않는 거랑 비슷하다.

solid 출처:
https://sehun-kim.github.io/sehun/solid/
https://career-gogimandu.tistory.com/27
https://jwkim96.tistory.com/155
https://career-gogimandu.tistory.com/27