객체지향은 왜 필요할까?

"객체지향 언어는 파이썬 자바 같은 것들이 있고

객체로 프로그래밍하기 때문에 생산성이 좋다"

이 문구를 보고 머릿속으로 !가 그려지시나요?

그래...자바 같은 거에 클래스 지원되고

그걸로 프로그래밍하니깐 편하긴 하지...

그런데 생산성이 더 좋나?

이런 생각이 드시나요?

오늘은 객체지향언어가 왜 필요한지

구체적으로 파보겠습니다

 

객체지향이 필요한 이유

대상이 뭉탱이로 묶인다

 

 

세상에는 다양한 사람들이 있습니다.

아시아인,유럽인,미국인

그리고 아시아인은 한국인,일본인,중국인 등으로 나누고

한국인 안에는 나이,학력,지역 등등

다양한 요소에 따라서 나뉩니다.

참 신기하게도, 사람 개개인의 인격이 다 다르지만

공통분모가 있다는 점입니다.

우선 사람은 태어나서 죽는다는 점에서 크게 묶이고

아시아권은 젓가락 문화권이라는 점에서 묶이고

한국사람은 김치가 들어간 음식을 먹는 점에서 묶입니다.

그렇다면 한국사람의 특성을 보면

아시아권의 공통점+기본 사람의 공통점이 함께 존재한다는 것이죠.

 

만약에 여러분들이, 세상 사람들을 프로그래밍한다고 가정해봅시다.

철수 영희 진우 희철 각각의 사람들을 일일이 프로그래밍한다고 생각해볼까요?

4명은 너무 쉽다고요?그럼 100명은?3천명은?

만약에 여러분들이 이렇게 접근하면 어떨까요?

"사람의 특징"

"아시아권 사람들의 특징"

"한국사람들의 특징"

"서울 사는 사람들의 특징"

"서울 은평구 사는 사람들의 특징"

이렇게 큰 특징으로 묶은 다음에 작업한다면

작업효율이 엄청나게 좋아지겠죠??

 

그림의 예시처럼

사람이라는 큰 분류안에

아구선수-직원으로 나누고

직원안에 감시자를 나누는 이런 구조.

전문용어로는 "상속"(Inherance)라고 합니다.

부모로부터 재산을 상속받듯이

부모 클래스의 특징을 이어받는 걸 의미합니다.

즉, 부모클래스 안에 있는

매개변수,함수 등등 여러가지 요소들을 물러받는 겁니다.

근데, 부모-자식보다는

"공통분모로 묶는다"라는 표현이 저한테는 더 잘 맞네요. ㅎㅎ

그림의 예를 들어 작업을 한다면,

나중에 person아래에 "lawyer"라는 대상을 추가한다할때

상속받아 간편하게 작업할 수 있습니다.

만약 객체지향 언어가 없었다면

여러분들은 새로운 게 튀어나올때마다

계속 빡코딩을 했어야할지도 모르겠네요.

(저런 언어 및 개념을 만들어준 석박사분들. 존경합니다)

 

객체 vs인스턴스(object vs Instance)

 

객체지향관련으로 항상 헷갈리는 주제입니다.

가만보면 그놈의 그놈같다는 말이죠.

실체냐 관계냐 등등 여러가지 말들이 많은데

저한테는 많이 어렵습니다.

쉽게 위의 그림 예시를 가져와서 설명해보겠습니다.

철수=new baseballplayer()

이렇게 철수라는 변수를 클래스로 선언해줬습니다.

여기서 철수는 Instance, 객체는 baseballplayer

 

 

 

 

단일책임원칙(Single Responsibility Principle)

멕가이버칼은 정말 유용합니다.

만능의 칼이거든요.

칼 하나에 다재다능한 기능이 있으니

필요할 때 이 칼 저 칼 써내쓰면 되거든요.

이런 생각을 가지고 객체를 프로그래밍할 때

"이 기능 넣고 저 기능넣고"막 구현하는 경우가 있습니다.

하지만 객체지향에서는 이런 멕가이버 칼 같은 코딩을 해서는 안됩니다.

나중에 코드 유지보수하는 게 엄청 힘들기 때문이죠.

이것을 객체지향에서는 "단일책임원칙"이라고 합니다.

하나의 클래스에서는 그 클래스만의 책임을 지도록 프로그래밍하라는 말입니다.

 

여러분들이 스타크래프트 개발을 한다고 가정하겠습니다.

Race라는 부모클래스를 만들고

그 아래에 terran,zerg,protoss를 만들었습니다.

그런데, 여러분들이 코딩하다가

"굳이 각 종족 안에 따로따로 코딩할 필요가 있어?"

하고 race안에다가 무리하게 기능을 집어넣습니다.

테란 자원관리하는 방법, 

저그 오버로드 산개 키,

프로토스 드라군 껌 안 밟기

등등 각각의 함수를 구현했습니다.

그런데 서비스를 해보고 나니,

드라군이 너무 껌을 밟아 수정해야할 필요를 느꼈습니다.

그냥 단순히 race안의 드라군 껌 안 밟기 기능을 수정하면 되는 줄 알았더니,

protoss클래스에 있는 설정 몇가지를 또 건드려야합니다.

그것만 건들면 끝인줄 알았는데, race안의 함수가 바뀌면서

테란,저그의 값이 또 달라져서 버그가 생기는 골치아픈 일이 벌어졌습니다.

 

이렇게 개발자가 나중에 유지보수하기 쉽게

하나의 클래스에는 하나의 책임만을 지게하는 걸

SRP원칙이라고 부릅니다.

 

 

(코드로 한번 더 이해하기)

https://inpa.tistory.com/entry/OOP-%F0%9F%92%A0-%EC%95%84%EC%A3%BC-%EC%89%BD%EA%B2%8C-%EC%9D%B4%ED%95%B4%ED%95%98%EB%8A%94-SRP-%EB%8B%A8%EC%9D%BC-%EC%B1%85%EC%9E%84-%EC%9B%90%EC%B9%99

💠 완벽하게 이해하는 SRP (단일 책임 원칙)

 

 

리스코프 치환 원칙 (Liskov Subsitution Principle)

 

객체지향 법칙 중 중요한 원칙.

바로 리스코프 치환원칙.

이 말은

"부모 객체를 호출하는 동작에서

자식 클래스가 상속받은 부모클래스를 완전히 대체할 수 있다"는 원칙.

 

여러분들이 스타3를 개발하고 있습니다.

신규 '젤나가'종족을 출시할 예정입니다.

젤가나의 특징을 살펴보니, 프로토스에 가깝네?

그럼 프로토스에 상속받아야할까

아니면 다른 종족처럼 race에 상속받아야할까

정답은 race에 상속받는 것입니다.

왜냐하면 프로토스랑 비슷하다고 할지라도

다른 점들이 워낙 많기 때문에

프로토스 관련 기능을 쓰는 건 무리입니다.

그러니 기본 기능이 구현된 race클래스를 상속받아 쓰는 것이 

LSP원칙을 지키는 것이죠.

 

 

(코드로 한번 더 이해하기)

https://blog.itcode.dev/posts/2021/08/15/liskov-subsitution-principle

[OOP] 객체지향 5원칙(SOLID) - 리스코프 치환 원칙 (Liskov Subsitution Principle) - 𝝅번째 알파카의 개발