취업 ... 했다 .... 그것도 무려 네이버에 ...!!! 신입으로 !!

예전에는 티스토리 사용할 때 Apple Developer Academy @ POSTECH 1기 후기 작성하고 이런 글을 언제 또 쓸 일이 있을까 싶었는데 생각보다 빠르게 쓰게 되어서 기쁘다 ㅎㅎ

나도 다른 분들 후기 글 보면서 정말 도움을 많이 받았기 때문에 이 글을 보는 다른 분들에게 많은 도움이 되고 싶다는 생각이다

그런고로 말할 수 있는 범위 내에서 최대한 자세히 쓸 예정 !!

<쓰는 중에 미래에서 온 나> 중간에 글을 다시 보니까 '팩트'라기보단 내가 어떻게 공부했는지에 대한게 큰듯 ?? 합니다 ??

🙋‍♂️ 간단한 나의 스펙

전형 준비하면서 느낀 점은 스펙이 큰 영향을 끼치진 않는다는 것이다 그런고로 '이정도 스펙인데 가능할까요?' 이런 질문은 필요가 없을 것 같음 !

- 대학교
  - 중앙대학교 18학번
  - 주전공 : 전자전기공학부
  - 부전공 : 소프트웨어공학부
  - 학점 : 4.02 / 4.5

- 대외활동
  - Apple Developer Academy @ POSTECH 1기 ( 2022.03 ~ 2022.12 )
  - SOPT 32nd iOS PART ( 2023.03 ~ 2023.08 )
  - NEXTERS 24th iOS PART ( 2024.01 ~ 2024.03 )

사람들이랑 프로젝트 하는걸 좋아해서 다양한 대외활동을 진행했는데 넥스터즈까지 하고 나니까 더 이상 프로젝트를 위한 대외활동은 그만하자... 라는 마인드이긴 했다

플젝보다는 그냥 내 실력을 갈고 닦는게 중요하다는 마인드 ... (근데 네이버 떨어지면 부스트캠프는 지원해보려 하긴 했음 ㅋ 부스트캠프는 교육이니까 ~)

📆 간략한 프로세스 일정 설명

공고 링크

전체 전형이 내가 기록해둔걸로는

- 서류 모집 :                3월 5일 ~ 3월 18일
- 코딩테스트 :             3월 23일
- 서류 + 코딩테스트 결과:     4월 9일     (목)
- 1차 면접 일정 발표 :         4월 11일
- 1차 면접 :                 4월 25일
- 1차 면접 결과 :             5월 3일    (금)
- 2차 면접 일정 :             5월 13일
- 2차 면접 :                 5월 28일
- 2차 면접 결과 :             6월 14일    (금)

무려 시작부터 결과 발표까지 3개월이나 걸친 긴 프로세스였다 ...

지원자도 많을테고, 그만큼 많은 사람들 면접도 보고 서류도 보고 하느라 시간 오래걸린건 이해가 된다만 ...

시간이 너무 안가 .... 프로세스 하나 끝내고 결과 나오기까지 오래 기다려야 해서 피가 너무 말리는 ... ㅠㅜ

📋 서류 + 🧑‍💻코딩테스트

지원하게 되면 먼저 서류를 작성해야 한다 (당연한 말)

문항은 총 3개였는데, 실질적으로 작성해야 하는 건 2개뿐이었다 ( 하나는 깃허브나 포트폴리오 링크 )

1번 문항

다음 중 본인의 가장 자신 있고 희망하는 분야를 한 가지 선택해 주세요.

■ Front-End ■ Back-End ■ Android ■ iOS ■ Data ■ 

공통선택한 분야에 **관심을 갖게 된 계기**와 **자신 있는 이유**(그동안의 노력, 경험, 강점 포함) 등에 대해 구체적으로 설명해 주세요.
※ 작성 예시 : ■ Front-End / 관심 계기 및 자신 있는 이유 :
※ 구체적인 희망 직무 분야가 미정이신 경우 '공통'으로 선택하시고 상세 사유를 작성해 주세요.

지금까지 iOS를 위주로 많이 해왔기 때문에 당연하게도 iOS 관련한 이야기를 썼다

적혀있는대로, 아직 정해둔 파트가 없다면 공통으로 적어도 무관할듯 ??

이 부분에서 가장 주의 깊게 고려한 부분은

** 왜 **

문항에도 적혀 있듯, 관심을 갖게 된 계기와 자신 있는 이유를 적어야 하는데, 왜 관심을 갖게 되었고, 왜 자신 있는지, 이에 대한 충분하고 구체적인 근거들을 프로젝트랑 연관지어서 작성했다

그리고 나는 장점을 두 가지 썼는데 개발자로서의 장점과, 자신 있는 분야(나는 iOS)와 연관된 장점을 작성했다

대충 완벽한 나를 나타내는 짤

사실 팁이랄건 아니긴 하지만 ... 이번에 서류 작성하면서 느낀게

네이버 말고도 다른 회사 서류도 많이 작성했는데, 그러면서 글 실력이 는 것도 있지만 항상 어제의 나와 오늘의 나는 다르다는 마인드를 가졌음

무슨 의미냐면, 오늘 이 장점 쓰면 진짜 좋을 것 같음 !!!이라는 생각이 들어서 작성해둔게 내일 다시 생각해보면 별로라고 생각할수도 있고 더 좋은 장점이 떠오를수도 있다는 것

무튼 그래서 최대한 어필하려고 한 것들은 내가 개발을 얼마나 좋아하고 재미있어하는지인 것 같다 !

2번 문항

가장 열정을 가지고 임했던 프로젝트(목표/과제 등)를 소개해 주시고, 
해당 프로젝트의 수행 과정 및 결과에 대해 기재해 주세요. (최대 1000자)

이거는 타이밍이 좋다고 생각한게, 내가 NEXTERS 활동을 하면서 내가 얼마나 부족한지, 뭘 공부해야 하는지 알게 되었고, 이 때문에 공부한 것들을 다른 프로젝트의 리팩토링 과정에서 적용해나갔다

참고로 나는 나한테 굉장히 가혹한 편 ..

이렇게 적용하는 과정에서 진짜 열심히 했고, 내 나름대로의 독창적인(아마?) 분석을 하기도 했는데 (이건 내 다른 게시글에서 볼 수 있음 !!) 이 분석 내용들도 간략하게나마 작성했다 (1차 면접 때 이와 관련된 질문이 나오기도 한거 보면 흥미롭게 보신 것 같기도 ?)

여기서도 역시 왜 리팩토링을 하게 되었고, 왜 리팩토링 과정에서 이런 기술 스택을 사용했고, 왜 그런 분석을 하게 되었는지 등을 자세히 쓸려고 했다

글로만 이렇게 쓰는게 아니라 `왜`를 계속 물어보는게 개발자로서의 옳은 태도라고 생각함 처음에 MVC를 적용했으면 왜 그랬는지, MVC에서 어떤 문제를 느껴서 MVVM으로 바꾸게 되었는지 등

3번 문항 (선택)

[선택] 3. 본인의 대표적인 개발 경험이나 희망 분야 관련 과제 성과, 활동 등을 가장 잘 보여줄 수 있는 
Github, 블로그 등의 URL을 작성하시거나 자료를 첨부하시고, 간단한 소개나 설명을 해 주세요.

공동 프로젝트였다면 본인의 역할을 명확히 써 주세요.
오픈소스 컨트리뷰션, 프로젝트, 본인이 작성한 소스코드 등 (임시저장 후 복수 첨부 가능 / 최대 200MB)수강하셨거나 
별도로 공부하신 컴퓨터공학 관련 학습/과제/프로젝트 활동을 보여 주셔도 좋습니다.

요건 선택문항인 만큼 좀 부담 없이 쓰려고 한 듯 하다

딱히 크게 말할건 없고 그냥 팩트만 작성했다

작성한 것들

• 깃허브 링크
• 앱 한 줄 소개
• 기술 스택
• 기간
• 인원
• 역할

지금와서 더 나을 수 있지 않을까 싶은거는 깃허브 링크를 제대로 꾸미고 뭐 했는지 보기 쉽게 만들면 어땠을까 싶은 ...

코딩테스트

사실 코딩테스트는 ... 할 말이 더더욱 없다
왜냐하면 🐶 못봤기 때문 ...

그리고 코딩테스트 문제가 뭐가 나왔는지 이야기할수도 없고 ... 정말 어떻게 붙었을까 싶을 정도로 코테를 못봤기 때문에 ....

조금 아래에서 이야기하겠지만 코딩테스트가 그렇게 크지 않을수도 있겠다 .. 싶은 느낌 ?

실제로 서류+코테 붙고 들어간 공채 오픈채팅방 닉네임을 이왜진이었을 지은...

하지만 나같은 특이케이스가 또 있을까 싶기도 하고 실무 때에도 필요가 있지 않을까 싶어서 꾸준히 공부하긴 할거다

다른 분들이 2024년 코테 관련 후기 올려놓은 글들도 있으니 그거 확인하길 !!!

후기

제대로 취준을 시작한거는 2023년 12월정도부터니까 ... 이것저것 많이 지원하지는 못했지만 이때까지는 막 서류나 코딩테스트가 '완전 넘사다', '너무 어렵다' 이런 느낌은 없었다

이전 취준 과정에서 코테 승패 기록은
- 현대 오**버 (승)
- 팀 네*버 (승)
- 이베* 재팬 (승)
- CJ 올**영 (참패 ㅋㅋ)

취준 시작하고 나서부터는 별 일 없는 이상 1일 1알고리즘을 오전 시간대(주로 코테가 오전이라서)에 풀었고 프로그래머스 AI 문제 추천(?) 이걸로 준비했다

코테가 얼마 안남은 시점에는 하루종일 코테만 팠음 ...

이렇게 매일 풀다보니 프로그래머스 레벨2는 쉽게 풀리고 레벨3는 재밌게(?) 고민하면서 풀 수 있었다 레벨4는 입만 험해졌음 ㅋㅋ

그리고 바로 위에도 말해놓은 것처럼 코테를 못봐도 서류를 흥미롭게 작성하면 충분히 가능성이 있으니까 !! 코테에 너무 일희일비하지 말자 !! (기만인가 ..)

결과

보자마자

엥? 했음

기 받아가십쇼

🧮 1차 면접 ( 기술 역량 인터뷰 )

여기까지 읽으신 분들은 얼추 많은 정보들을 찾아보지 않았을까 싶은데 찾아보신 것들 다 맞는 말입니다

악명 높습니다 ...

그래서 혼자서 준비하기보다 다른 사람들과 같이 하면 좋을 것 같았고 오픈채팅방에서 어쩌다보니 내가 면접 스터디를 파게 되었다

스터디를 하면서 너무 잘하는 스터디원들 때문에 주눅들기도 하고 (진짜 이건 기만 아니고 ㄹㅇ로 ;; 사람들 개잘함 ;; ) 근데 오히려 여기서 더 자극받고 더 열심히 하게 된 것도 있다

그리고 집단지성이 좋긴 하잖슴 ~

다시 후기로 넘어가자면 ...

1차 면접 때는 기술 역량을 봄 크게는

- Computer Science
- 창의 / 수리 / 논리 문제
- 간단한 손 코딩
- 위 세 가지와 관련된 꼬리문제

요롷게 나오는 것 같다 각각 어떻게 준비했는지 이야기해드리겠슴다

Computer Science

먼저 말하자면, 내 스펙에서도 말했듯, 나는 전공생이지만 전공생이 아니다(?)

전자전기공학부를 나와서 운영체제 같은 과목을 듣긴 했다만 찐 전공생에 비해서는 얕게 배웠고 데이터베이스나 컴퓨터네트워크는 듣긴 들었지만 (수강할 당시에는)크게 필요성을 못느껴서 시험만 보고 머리 속에서 휘발되었다

모두 각 자리에 잘 분류되어 있는 모습이다.

무튼 이정도로 CS가 준비가 안되어있던 상황이었고, 1차 면접 전까지의 기간(대략 2주)동안 OS, 컴퓨터네트워크, 데이터베이스, 알고리즘, 자료구조를 준비하기에는 시간이 절대적으로 부족해서 선택과 집중을 했다

그렇게 가장 우선순위를 두고 공부한건 운영체제 왜냐하면, iOS 개발을 하면서 가장 밀접한 부분이라고 생각했기 때문 ! 그래서 가장 질문이 많이 나올 것 같았다

결론은 좋은 전략이었음 !! (사람마다 다를 수 있으므로 함부로 따라하지 말 것)

그래서 운영체제 공부를 어떻게 했냐하면

그냥 냅다 함

• 공룡책 중요하다고 생각하는 부분들 읽기
• 유투브 강의들 보기 (널널한 개발자, 우아한테크, 노마드 코더, 얄팍한 코딩사전)

이렇게 일단 한 바퀴 돌리는데, 여기서 중요하다고 생각한건

단순히 외우려고 하지 않고 왜 쓰는지, 어디에서 쓰는지, 각 요소가 뭘 하는지 이런 질문들을 계속 던지면서 깊게 파보기

이게 중요한 이유는, 막상 한 바퀴 돌리고 났을 때

"그래 운영체제가 어떤 역할을 하지?" 라고 스스로 질문했는데 만족스러운 대답을 할 수 없었다

뭐 보통 이야기한다면 "한정된 자원을 효율적으로 쓸 수 있게 분배한다"가 될 수 있는데 이거에 대해 "어떻게 효율적으로요?"와 같은 꼬리질문 하기가 애매하잖슴..

내가 저 대답보다 나은게 있을거라고 생각한 이유는 운영체제가 실제로 하는 굉장히 많은 것들

• 프로세스 생성 / 종료
• 프로세스 메모리 할당 / 해제
• 가상 메모리 관리
• 입출력 관리
• 커널 영역 사이의 인터페이스
• 등등...

이런 더 구체적인 대답이 있지 않을까 ? 더 꼬리질문 받고 궁금해할만한 대답이 있지 않을까 ? 이렇게 생각해서 !!

(그새 휘발되었다 ㅋㅋㅋㅋㅋㅋㅋㅋ... 출근 전에 다시 공부해야지..)

그냥 단순히 생각해봐도 "자원을 효율적으로 관리하도록 합니다 !" 보다는 "프로세스 스케줄링, 메모리 할당 / 해제 , 가상 메모리 관리 등을 합니다 !" 이런 대답이 더 이야기할 거리가 많을 것이기에 !!

그렇게 여어어어어얼심히 공부하고 나서는 전체적인 운영체제와 이게 어떻게 돌아가는지 스스로 말하면서 설명하는 연습을 했다

다른 얘기이긴 하지만, 자료구조도 공부했는데 공부하고 나서 티비에다가 아이패드 연결하고 엄마아빠한테 이해 되도록 설명하는 연습 하기도 함

왜냐하면 내 언어가 다른 사람들에게는 낯설수도 있기 때문에 그리고 말 하면서 정리하는게 내가 아는 지식들을 정리하기 좋다고 생각했기 때문 !

이건 꼭 해보길 추천 !!

창의 / 수리 / 논리 문제 + 손코딩

요 두 개는 공부하면서 되게 재미있었다 (공부라기보다는 바쁜 와중에 나름대로 쉬면서 공부한 느낌)

크게 보면 두 가지를 많이 함

• 문제적 남자 보기
• 책 보기

문제적 남자는 운영체제 공부하다가 쉴 때 틈틈히 봤다 이거 보다보면 이런 방향으로도 생각할 수 있구나가 트이게 됨 (부작용: 재미있어서 공부 안하고 계속 보게 됨)

그리고 책은 두 가지 추천

링크

링크

이 게시글은 유료광고를 포함하고 있지 않습니다.
당연히도 ㅋㅋ

'후지산을 어떻게 옮길까'는 면접 전전날에 집에 있는거 봤는데 오우 상당히 괜찮았음

'코딩인터뷰 완전분석'은 문제 보면서 코딩으로 구현해보면 손코딩 연습에 도움이 많이 됨

근데 '후지산' 책은 비슷한 책 많이 있던거 같고 '코딩인터뷰' 책은... 사실 대체 불가능인거 같기도 함

후기

살살 쓰다가 이제서야 인지하게 됐는데 먼가 면접이나 코테에 대한 팁보다는 내가 어떻게 준비했는지를 쓴 글이 되어가는듯한 ....

머 어때 ~

무튼 1차 면접은 정말 색다른 면접이었다 문제풀이를 시킬줄은 ....

근데 그래도 애플 개발자 아카데미 면접이 어나더레벨로 신박했음 ㅋㅋㅎ

면접을 다 마무리하고 나서는 아래와 같은 생각이 들었다

이유를 더 생각해볼걸

왜냐하면 단순히 공부하고 설명에서 끝나는게 아니라 공부한 지식들을 실제로는 어떻게 적용할 수 있을지, 어떻게 사용할 수 있을지 등을 더 대비하고 가면 좋지 않았을까 싶었다

1차 면접에서 꿀팁을 하나만 꼽자면 이거라고 생각 ...

떨어질 것 같았나 붙을 것 같았나 생각을 해보면 ... 사실 붙는거 7 떨어지는거 3 정도인 것 같다

면접 마무리 후 질문 시간에 피드백 주실게 있는지 여쭤봤는데 면접관 중 한 분이 되게 잘 즐기고 있는 것 같다고 하셨기 때문에 내가 얼마나 개발을 좋아하는지나 열정있게 하는지가 드러난 것 같았다

결과

TMI

합격 결과를 받고 너무 신기하고 흥분돼서 실수로 메일을 삭제했는데 삭제된 메일함에서 복구 버튼인 줄 알고 영구 삭제되었던 ...

2차 면접 때 네이버 관련 앱의 개선사항 관련해서 질문하시면
이거 이야기할 생각이었음 ㅋㅋ

그런데도 간직(?)하려고 메일 다시 받고 싶어서 재전송 가능한지 문의 넣었었음 ㅋㅋㅋㅋ

그래서 재전송 붙음 ㅋㅋㅋ

이것도 기 받아가십쇼 ...

🗣️ 2차 면접 ( 종합 역량 인터뷰 )

자자 이제 1차 면접보다 더더 정보가 없는 그 2차 면접입니다 ...

대부분의 블로그 후기들에 적혀있을텐데 ... 뭐 이거 준비해라 저거 준비해라 할 것 없이 그냥 다 준비해야 합니다 ...

우선 여기까지 오면 5월 중순쯤 되어서 너무 지쳤기 때문에 더 열심히 준비할 수 있었지만 그러지는 못했음 ...

2차 면접은 크게 준비한건

- 1차 면접 때의 복기
- 1분 자기소개
- 자기소개서 관련 질문
- 인성 질문
- CS 및 기술 질문
- 진행한 프로젝트 관련한 경험 정리

요정도 .... 많네 ..

하나하나 빠르게 살펴보겠다

1차 면접 때의 복기

일단 (준비할 시간은 충분할 것 같지만) 시간이 너무너무 없다면 이거만큼은 확실하게 준비하는게 좋을 듯 하다

대부분의 2차 면접 후기에서도 강조된 부분이기도 하고 나도 중요하다고 생각하는 부분이기 때문 ( ^____^ 유남쌩 ? )

무튼 1차 면접 끝나고 받았던 질문을 다시 받아적어두든 잊기 전에 다시 복기하는걸 추천한다

내 머리속의 지우개가 작동하기 전에 ....

스스로 생각했을 때 아 이건 더 잘 대답할 수 있었는데 싶은 것 제대로 대답하지 못했던 것 다시 보니까 틀리게 대답한 것 요런 것들은 다시 찾아보고 깊게 공부해보는거 추천..!!

1분 자기소개

개인적으로 나는 완전 각 잡힌 1분 자기소개를 별로 안좋아한다 자기소개를 하는건데 너무 준비한 티가 나면 인위적인 모습이 드는 것 같은..? 그래서 이건 크게 오래 준비하진 않고 틈틈히 생각했던 것 같음 !

내가 어떤 사람인지, 이 자리까지 오기에 어떤 노력을 거쳤는지 이런 것들을 짧고 굵게 말하려고 노력함

자기소개서 관련 질문

이것도 크게 말할건 없지만 ... 그냥 단순히 서류 제출할 때 쓴 것들 다시 정리해봄 관련 경험이나 기술적인 어려움이나 등등...

인성 질문

내가 최종 면접을 본게 처음이라 인성 준비를 어떻게 해야할지 1도 몰랐는데 열심히 구글링 했다 ㅋㅋ

구글링 하다보면 (링크가 어디있는지 모르겠어서 ㅠ) 어떤 분이 개발자 면접 질문 받은거 싹 다 아카이빙 해 둔 노션 페이지를 찾을 수 있다

이런 질문 리스트로 내가 한 경험들 다시 리마인드 하고 회고도 하고 도움이 많이 된 것 같다 그대로 나온 질문은 없었지만, 대비한 질문들로 면접 때 어떻게든 연관시켜서 생각할 수 있게 됐듯

그런고로 개발자 인생 회고 함 하는거 필수 !

CS 및 기술 질문

이건 자기소개서랑 연관이 있기도 한데, 자기소개서에 사용한 기술에 대해 많이 쓴다 ? 그러면 자소서에 쓴 것 관련해서 깊게 이야기한다고들 한다 (나는 기술적인걸 많이 쓰진 않아서 딱히 없긴 했지만)

대신 나는 자기소개서에 ~~에서 불편한 점을 느껴서 운영체제와 컴퓨터 네트워크에 대한 필요성을 느껴 공부할 예정입니다 라는 식의 내용을 썼는데, 이거에 대비하기 위해서 운영체제랑 컴퓨터 네트워크를 열심히 공부했다

1차 면접 대비할 때 운영체제 공부를 해 둬서 2차 준비할 때에는 컴퓨터 네트워크 위주로 공부했음 (근데 사실 이와 관련해서 질문이 많이 나오지는 않았음 ..)

진행한 프로젝트 관련한 경험 정리

하 이것도 좀 준비를 많이 할 걸 싶었던 부분 중 하나다

붙어서 다행이지 떨어졌으면 진짜 후회했을듯 ...

나는 대외활동 되게 많이 한 편이라 (애플 개발자 아카데미, SOPT, 넥스터즈) 프로젝트도 되게 많이 했어서 이와 관련해서 많이 물어보셨다

기술적인 것보다도 협업적인 것 들

나랑 비슷한 케이스라면 필수 !!

후기

이번에는 1차 때보다 더더 못봤다는 생각이 많이 들었다 ... 2차 끝나고는 그래도 분위기는 좋았어서 잘 봤다고 생각했는데 복기하고 나니까 조졌다는 생각밖에 안들었음 ...

그래서 결과 나올 동안 떨어지는 악몽도 꾸고... 붙는 꿈도 꾸고... 여자친구한테 하소연도 많이 하고... (Thanks and Love to SAJ)

그렇게 2주라는 기간을 감정기복이 굉장히 심한 상태로 지내다보니 결과가 나왔고 ...

결과

붙었다 !!!!!!

결과 메일을 키고 확인하는데 도저히 못보겠어서 손으로 가린 상태로 스크롤 내림 예전 전형은 탈락이면 궁서체인거 같아서 글씨체 확인하고 어..? 초록색 글씨 확인하고 어...!!!!!?

보자마자 눈물이 나오더라 ㅠ

사실 팩트로 보자면 취준 기간은 6개월이었고 그렇게 긴 시간이 아닐수도 있지만 피말리는 기간을 3개월동안 보내고 노력하던 모습이 주마등처럼 지나가면서 눈물이 안날 수가 없었음....

바로 엄마한테 달려가서 부에에에엥ㅇ(진짜 우아아악 함) 하면서 핸드폰 보여줬는데 엄마도 같이 울고 ㅋㅋ 난리였음

지금도 그때 생각하면 울컥 함 ㅠㅠ

무튼 이렇게 길면 길고 짧으면 짧은 취준 기간이 끝났고, 이번에 떨어지면 iOS 말고 웹을 해볼까 고민하고 있었는데 어떻게든 iOS로 신입 채용을 뚫었다 ... (들어가서 iOS 할지 안할지는 네이버 마음 ~)

네이버 하고 싶은거 다 해 !

이제는 신입으로서 어떻게 성장해나갈 수 있을지, 어떻게 선배들한테 예쁨 받을 수 있을지를 생각해야지..!

❗️ 당부의 말씀

글을 끝맺음 하기 전에 짧게나마 말하고 넘어가고 싶은 부분이...

제 개인적인 경험이고, 다른 분들은 자기소개서, 스펙, 경험, 담당 면접관에 따라 다른 경험을 하실 수도 있습니다 제 말이 답은 아니라는 점 ...!!!! 내가 면접관이라면 어떤 사람들을 뽑을까? 에 대한 생각을 통해서 준비를 해 나가시는게 베스트일 것 같습니다 :)

그리고 마지막으로..

모두 합격을 기원하며 !!

자율적인 책임

객제치향 공동체를 구성하는 단위는 자율적인 객체 즉, 객체가 맡은 책임을 어떻게 수행하는지는 객체 스스로, 자율적으로 판단해서 행동

• 협력관계 내에서 객체는 요청을 받아서 어떤 행동을 수행 → 이 수행을 책임이라고 함

• A 객체와 B 객체가 협력관계 내에 있다고 가정 → 이때, A객체가 B 객체에게 특수한 요청을 함 → B 객체는 이 요청을 수행하기만 하면 됨, 어떻게 수행할지는 전적으로 B의 자율에 맡김

• 재판장이 모자장수에게 증언을 요청

  • “증언하라” → 모자장수가 자율적으로 알아서 증언하면 됨
  • “목격했던 장면을 떠올려라” / “떠오르는 기억을 시간 순서대로 ~” / “말로 간결하게 표현” → 책임을 어떻게 수행할지를 제한하고 있으므로 원활한 수행이 이루어지지 않을 수도 있음
  • “설명하라” → 어떤걸 설명하라는지 너무 모호(추상적)

• 추상적이고 포괄적인 책임은 협력관계에서 해당 책임을 재사용할 수 있도록 해줌 → 자율성을 보장할 수 있도록 추상적이되, 협력의 의도를 파악할 수 있을 정도로 뚜렷해야 함

• 자율적인 책임의 특징은 협력을 위해 어떻게가 아니라 무엇을 해야 하는지가 핵심

메시지와 메서드

메시지

어떤 객체가 다른 객체에게 요청을 하기 위해 전송하는 것

• 메시지의 구성 → 메시지 이름(함수명)과 인자(전달 값) 으로 구성 → 증언하라(어제, 왕국)

• 메시지 전송의 구성 → 수신자와 메시지의 조합 → 모자장수.증언하라(어제, 왕국)

• 모자 장수는 증언하라는 메시지를 전달받았을 때, 처리 방법을 자유롭게 선택할 수 있음 → 모자 장수가 메시지 자체를 변경하지만 않는다면, 책임을 수행하는 방법을 바꿔도 재판장은 이를 알 수 없음 → 객체의 외부와 내부가 분리되어 있다는 것

메서드

메시지를 처리하기 위해 내부적으로 선택하는 방법

다형성

서로 다른 유형의 객체가 동일한 메시지에 대해 서로 다르게 반응하는 것

서로 다른 타입에 속하는 객체들이 동일한 메시지를 수신할 경우 서로 다른 메서드를 이용해 처리

• 다형성을 만족시킨다는 것 → 객체들이 동일한 책임을 공유한다는 것 → 메시지 송신자의 입장에서는 다형적인 수신자들을 구별할 필요가 없고, 송신자의 요청만 수행하면 됨 → 대체 가능성을 의미

• 다형성이 설계를 유연하고 재사용 가능하게 만듬 → 다형성이 수신자의 종류를 캡슐화

• 송신자와 수신자 간의 결합도를 메시지에 대한 결합도로 낮춤

유연하고 확장 가능하고 재사용성이 높은 협력의 의미

• 송신자가 수신자에 대해 매우 조금만 알아도 협력이 가능

  • 협력이 유연해짐 → 송신자 입장에서 수신자가 메시지를 이해하기만 하면 어떤 타입으로 바꿔도 상관이 없음 → 송신자는 수신자에게 어떤 메시지를 보낼 수 있는지만 알고 있음 → 송신자에 대한 파급효과 없이 유연하게 협력 변경 가능

  • 협력이 수행되는 방식을 확장할 수 있음

  • 협력이 수행되는 방식을 재사용할 수 있음 → 협력에 영향을 미치지 않고 다른 객체가 수신자의 자리를 대체할 수 있음

메시지를 따라라

객체지향의 핵심, 메시지

• 객체지향의 핵심은 책임을 수행하는 자율적인 객체들의 협력을 통해 어플리케이션을 구축하는 것 → 협력을 하기 위해 사용할 수 있는 유일한 수단은 메시지의 전송 → 그렇기 때문에 메시지를 중심으로 객체의 내부 구조를 정의해야 함 → 독립된 객체의 상태와 행위에 대해 고민하지 말고 시스템의 기능을 구현하기 위해 객체가 다른 객체에게 제공해야 하는 메시지에 대해 고민 → 객체가 메시지를 선택하는 것이 아닌, 메시지가 객체를 선택하게 하기

책임-주도 설계 다시 살펴보기

책임을 완수하기 위해 협력하는 객체들을 이용해 시스템을 설계하는 방법

• 책임-주도 설계의 역할, 책임, 협력을 식별 → 애플리케이션이 수행하는 기능을 시스템의 책임으로 보는 것에서 시작 → 시스템의 책임을 동작하게 하기 위해 적절한 협력관계를 찾기 → 이렇게 찾은 시스템의 책임의 협력관계를 몇 가지 객체들의 책임으로 분산하여 할당

What/Who 사이클

책임-주도 설계를 위해, 어떤 행위가 필요한지를 먼저 결정한 후에 객체를 결정하는 사이클

• 협력이라는 맥락에서, 객체부터 정하는 것이 아닌, 메시지부터 먼저 결정하는 것 → 이렇게 메시지들이 모여, 책임을 구성함

묻지 말고 시켜라

• 책임-주도 설계는 객체가 아닌 객체들이 주고받는 메시지에 집중하여 객체지향의 장점을 극대화 → 메시지에 집중하게 되면, 메시지 수신자의 캡슐화를 증진시킴 → 그 결과, 더 유연하고 재사용 가능한 설계할 수 있음 & 결합도가 낮아짐

• ‘어떻게’보다 ‘무엇을’에 집중하기 → 객체의 인터페이스의 크기를 급격하게 줄일 수 있음 → 외부에서 이 객체에 의존하게 되는 영역이 더 줄어듬 → 협력관계의 송/수신자 사이의 결합도가 줄어듬

객체 인터페이스

인터페이스

두 사물이 마주치는 경계 지점에서 서로 상호작용할 수 있도록 이어주는 방법이나 장치

• 인터페이스가 갖는 3가지 특징
  • 인터페이스를 사용할 수만 있으면, 내부 동작 원리는 몰라도 됨
  • 인터페이스를 변경하지 않고 내부 동작 원리만 바꾸는 것은 인터페이스에 아무 영향도 끼치지 않음
  • 동일한 인터페이스를 제공하기만 한다면, 손쉽게 사용할 수 있음

책임, 메시지, 그리고 인터페이스

• 책임의 수행이 자율적이어야 함 → 자율적이라 함은, 수행만 한다면, 수행 방법은 어떻게 하든 상관 없음

• 한 객체가 다른 객체에게 요청을 할 때 사용하는 메시지 → 객체의 인터페이스가 객체가 수행할 수 있는 책임으로 채워져, 인터페이스를 통해 메시지를 전송 → 특정 메시지를 수신했을 때, 그에 대한 동작을 수행 → 메서드는 특정 메시지를 수행하는 방법을 의미 → 이렇게 메시지와 메서드를 구분했기에, 객체의 내부와 외부를 분리된 영역으로 구분할 수 있고, 다형성을 통해 다양한 타입의 객체를 수용할 수 있는 유연성 부과

• 객체가 책임을 수행하기 위해 메시지를 받기 위한 통로인 인터페이스 → 객체가 다른 객체와 협력하기 위한 접점

인터페이스와 구현의 분리

객체 관점에서 생각하는 방법

• 맷 와이스펠드의 인터페이스 관련 세 가지 원칙

  • 좀 더 추상적인 인터페이스 → 자율적인 책임을 부여한다 → 단, 너무 추상적이면 역효과
  • 최소 인터페이스 → 외부에서 사용할 필요가 없는 인터페이스는 최대한 노출하지 않기 → 외부에 최소한의 정보만 공개할 수 있고, 그만큼 결합도가 낮아지며, 재사용성이 올라감
  • 인터페이스와 구현 간에 차이가 있다는 점을 인식 → 아래에서 더 설명

구현

객체를 구성하지만 인터페이스에 해당하지 않는 모든 것

• 객체의 상태
• 객체의 행동(메서드)

인터페이스와 구현의 분리 원칙

객체 외부에 노출되는 인터페이스와 내부에 숨겨지는 구현을 명확하게 분리해서 고려 → 외부에 공개되는 인터페이스와 내부에 감춰지는 구현, 두 가지 영역으로 나누어 설계

• 변경에 대한 안전지대와 위험 지대를 구분 → 안전지대를 만드는 것은 객체를 더욱 자율적이게 만듬 → 이 안전지대에서 변경을 주었을 때에는 외부에 어떤 변경사항도 야기해서는 안됨

• 이 원칙을 수행하기 위한 객체 설계 방법 → 캡슐화

캡슐화

객체의 자율성을 보존하기 위해 구현을 외부로부터 감추는 것 (정보 은닉이라고도 함)

상태와 행위의 캡슐화

• 객체는 스스로 상태를 관리하고, 행동을 내부에 보관 → 데이터 캡슐화 → 인터페이스와 구현을 분리하기 위한 전제 조건

사적인 비밀의 캡슐화

• 외부 객체가 객체 본인 내부를 알 수 없도록 막고, 일부만 의사소통 가능하게 노출 → 인터페이스
• 외부에 제공할 필요가 있는 메시지들의 모음 → 공용 인터페이스 → 개인적인 비밀은 공용 인터페이스의 뒤에 감춤

책임의 자율성이 협력의 품질을 결정한다

• 첫 번째 이유 - 자율적인 책임은 협력을 단순하게 만듬 → 세부사항을 무시하고 의도만을 명확하게 표현하면, 협력을 이해하기 쉽게 됨 → 책임이 적절하게 추상화 됨

• 두 번째 이유 - 자율적인 책임은 모자 장수의 외부와 내부를 명확하게 분리 → 책임이 자율적이기에, 책임만 완수한다면 어떻게 동작할지는 모자 장수의 몫 → 요청하는 객체가 몰라도 되는 사적인 부분은 캡슐화 됨 → 인터페이스와 구현이 분리됨

• 세 번째 이유 - 책임이 자율적일 경우 책임을 수행하는 내부적인 방법을 변경하더라도 외부에 영향을 미치지 않음 → 변경에 의한 파급효과가 객체 내부만으로 한정됨 → 두 객체 간의 결합도가 낮아짐

• 네 번째 이유 - 자율적인 책임은 협력의 대상을 다양하게 선택할 수 있는 유연성을 제공 → 다양한 문맥에서 재사용할 수 있게 됨 → 설계가 유연해지고, 재사용성이 높아짐

• 다섯 번째 이유 - 객체가 수행하는 책임들이 자율적일수록 객체의 역할을 이해하기 쉬워짐 → 책임이 자율적일수록 객체의 응집도를 높은 상태로 유지하기 쉬워짐

서론

최근 들어서 프로젝트의 설계와 구조에 대한 관심이 컸었고, 이에 대한 계기는 Funch 프로젝트의 개발 과정에 있다

현직자 형이랑 같이 개발을 하는데 무슨 레이어.. 저런 레이어.. 등등.. 초반에는 전혀 이해도 안되는 이야기를 하길래 조금 절망스럽기도 했다

하지만 여기서 끝내면 이성민이 아니지 ㅋ

프로젝트 중에는 개발하느라 바빴고, 끝나자마자 Clean Architecture를 공부하기 시작했다

가장 괜찮은 공부 방법이 '그' 클린 아키텍쳐 서적을 읽는거였는데, 아니나 다를까 전혀 이해가 안됐고 ... 내 또다른 멘토 형이랑 밥 먹으면서 객체지향부터 공부해보면 좋을 것 같아서 책을 추천 받았다 -> <객체지향의 사실과 오해>

책은 다 읽었는데 면접, 코테, 취준 하느라 5장부터 블로그를 못썼는데, 조만간 다시 시작할 예정 ...

무튼 책을 읽고 클린아키텍쳐를 다시 생각해보니 ... 꽤나 흥미롭게 책임과 역할과 협력을 대입해가면서 분석할 수 있었다

이걸 공고 지원서에도 많이 썼고, 면접을 앞두고 있는데, 그 전에 스스로 한 번 정리하는 차원에서 글을 쓰게 됐다

본론

결국 iOS 개발을 하는 이유가 서비스를 제공하기 위해서이고, 그 서비스에 Clean Architecture를 적용하려고 하는거다

그래서 상세적인 레이어로 들어가기 전에 서비스를 사용하는 유즈케이스와 서비스가 담당해야 하는 책임, 협력 등에 대해서 살펴보겠다

가장 거시적인 측면 - 서비스

사람들이 서비스, 또는 어플리케이션을 왜 사용할까 ? 즉, 사용자들의 서비스를 사용함에 있어서의 유즈케이스는 뭘까?

위 질문에 대해 가장 먼저 생각을 해봤다

그래서 내가 나름대로 생각한 유즈케이스는 아래와 같다

특정 목적의 실행 ( 사실 유즈케이스 자체의 의미인 것 같긴 하다만... )

왜냐하면 ... 카카오톡이나, 네이버나, 29CM이나.. 등등 주된 서비스의 사용 이유는 (상세적인 것은 다르겠지만) 특정 목적을 실행하는 것이다

• 카카오톡을 통해서 지인과 원격으로 대화하기
• 네이버를 사용하면서 검색, 쇼핑, 뉴스 등등을 통해 정보를 얻기
• 29CM을 통해 쇼핑하기

하지만 이렇게 서비스를 하나의 객체라고 생각하면, 너어어어어어무 많은 책임을 갖는다

조금 더 깊게 들어가기 - 레이어

너무 많은 책임을 조금 분산시키기 위해, 목적의 실행이라는 책임을 조금 나눠보겠다

• 목적을 수행할 수 있는 화면을 보여준다 -> Presentation Layer
• 목적을 수행한다 -> Domain Layer

이렇게 생각해보면 목적의 실행이 Presentation 과 Domain 사이의 협력관계로 생각할 수 있다

Domain에서는 목적을 수행하고 Presentation에서는 유저에게 목적을 수행하기 위한 요소들을 보여준다

.

그래서 사실 볼륨이 작은 서비스들은 이 두 레이어만 있어도 되지 않을까라는 개인적인 생각이다

하지만 생각해보면, 목적을 수행하기 위해서는, 대부분 특정 정보를 보여줘야 한다 즉, 내부/외부 데이터베이스로부터 정보를 가져와야한다

이런 관점에서, Domain 레이어를 다시 두 가지 책임으로 나눈다

• 특정 정보를 사용/가공하여 목적을 수행한다 -> Domain Layer
• 정보를 가져온다 -> Data Layer

.

이렇게 생각해보면, Clean Architecture의 세 가지 레이어의 책임이 나온다

• Presentation - 목적 수행을 위한 화면을 보여준다
• Domain - 특정 정보를 사용/가공하여 목적을 수행한다
• Data - 특정 정보를 가져온다

이를 협력관계로 보면 아래와 같다

Presentation - Domain: 유저와의 상호작용을 통해 특정 정보를 보여주며 가공한다 Domain - Data: 특정 정보를 보여주고 가공하기 위해 외부/내부로부터 정보를 가져온다

조금 조금 더 깊게 들어가기 - 각 레이어

Presentation 레이어

Presentation은 결국 화면을 보여주고, User Interaction을 처리해야 한다 즉, 화면에서 보여지는 모든 것을 해야한다

이렇게 보면, Presentation 또한 너무 많은 책임이 있어서 나눈다 !

• 화면을 보이기 -> View
• 화면에서의 Interaction을 처리하기 -> ViewModel
• 화면에 정보를 띄우기 -> Model -> Domain의 Entity

(MVVM 측면에서의 분리이다, 다른 패턴을 쓴다면 당연히 달라질 것이다)

기본적은 MVVM 측면에서는 이렇게 생각할 수 있다

여기에 추가적으로 Coordinator나, DIContainer등을 사용해서 책임을 더 분산시킬 수 있을 것 같다 !

Domain 레이어

Domain은 특정 정보를 사용/가공하여 목적을 수행해야 한다 즉, Data 레이어로부터 정보를 가져오고, 이를 가공하고 사용해야 한다

이 또한 단일 객체에서 담당하기에는 책임이 막대하기 때문에, 나눈다 !

• 화면에 보일 정보의 형태 -> Entity
• 정보의 가공 및 사용 -> UseCase
• 정보를 가져오기 -> Repository -> Data의 Repository

Data 레이어

Data는 특정 정보를 가져와야 한다 어디서? 데이터베이스에서 어느 데이터베이스에서? 내부? 외부?

이렇게 서로 아는 것이 다르기 때문에, 나눈다 !

• 정보를 가져오는 것을 요청하는 부분 -> Repository
• '외부' 데이터베이스와 연결되는 부분 -> Network (이름 개인차 有)
• '내부' 데이터베이스와 연결되는 부분 -> Persistent Storage (이름 개인차 有)

결론

이렇게 보면, 얼추 우리가 아는 Clean Architecture의 형태가 된다

프로젝트 볼륨, 의도, 또는 다른 아키텍쳐 적용 여부에 따라 각 역할과 책임과 협력관계가 달라질 수 있겠지만 나는 Clean Architecture에서는 이렇게 분석해보았다

처음 Clean Architecture가 나온 의미가 이와는 다를 수 있겠지만 머 ...

무튼 분석하면서 해당 아키텍쳐에 대해 훨씬 자세하게 이해할 수 있었던 것 같다 ! 이후로도 책임과 협력과 역할 측면에서 쭉 분석해봐야겠다 !

서론

먼저 왜 Coordinator Pattern 의 연습이 필요했냐면, '출시'는 했지만 코드는 개판인 프로젝트인 <건빵>의 리팩토링 과정에 반영한 것들 이것저것 생각하다 나온 디자인 패턴 중 하나이기 때문

약 스포 하자면 아래 다이어그램 아닌 다이어그램이 우리 서비스의 흐름이다 굉장히 ... 복잡하다 ...

이 복잡한 흐름을 Coordinator Pattern으로 조금이나마 간략하게 하려고 한다 !

무튼 꽤나 복잡한 상태이기 때문에 바로 프로젝트에 적용해보려고 하면 난리 날 것 같아서 연습으로 먼저 해봤다 ! 이후에 적용 다 완료되면 연습기 말고 설계할 때 생각한 것들, 적용할 때 생각한 것들 모두 올릴 것 같다 !!

고민

연습하고자/고민하고자 했던 요소들은 아래와 같다

• TabBar를 어떻게 관리할까
• LaunchScreen에서 유저/비유저 분기처리를 해야하는데, Coordinator에 어떻게 적용할까
• 29CM과 같은 서비스는 탭이 개별로 NavigationController를 갖는데, 없던걸 만드는것보다 있는걸 없애는게 쉬우니 적용해보자

일단 요정도 ??

.

첫 번째 고민 - AppCoordinator와 LaunchScreen

위에 적어둔 고민거리가 대부분 여기에 포함되어 있다

AppCoordinator는 최상단에 위치한 Coordinator로, 전체적인 앱 흐름을 관리하는 역할을 한다

• 그렇기 때문에, 맨 처음에 로그인 했는지 안했는지를 판별해야지 다음 플로우로 넘어가는데
• LaunchScreen에서 보통 로그인 여부를 판단한다 !

음.. 시작하자마자 고민을 하게 됐는데...

LaunchScreen을 어떻게 관리할까 ?

생각의 흐름

맨 처음 든 생각은

1. AppCoordinator 에서 LaunchScreenCoordinator로 이동한 뒤
2. LaunchScreenViewController를 실행시키고
3. LaunchScreenViewModel에서 viewWillAppear 이벤트가 도달하면
4. 로그인 여부를 판단하고, 이에 따라 AppCoordinator에게 적절한 플로우를 실행하라고 메시지를 전송하는 것

Coordinator 하나 만드는데에도 꽤나 많은 리소스가 필요한데, 그걸 LaunchScreen 하나 때문에 ViewController ViewModel Coodinator를 모두 만든다는 생각에 '흠...'싶을 것 같다

그래서 기각 ㅎㅎ

그 다음으로 든 생각은

1. AppCoordinator에서 LaunchScreenViewController를 실행
2. LaunchScreenViewModel에서 로그인 여부를 판단하고
3. AppCoordinator에게 적절한 플로우를 실행하라고 메시지 전송

먼저 이 방법에 대해 말하기 전에 알아둬야 할게, 요번 건빵에서는 DIContainer도 만들어서 의존성을 주입해주는 방식을 쓰고 싶었다 하지만 꽤나 높은 러닝커브와 과도한 리소스가 필요할 것 같아서 일단은 기각시켰다

이걸 왜 말하냐 -> DIContainer에 미련이 남은 미련 줄줄 바짓가랑이 붙잡는st.이기 때문이다 -> DIContainer를 적용할 수 있는 확장성을 생각했다는 의미 ..

- DIContainer는 Presentation, Domain, Data 등 모든 레이어를 알고 있고,
- AppCoordinator가 DIContainer를 의존하고 있어서
- AppCoordinator도 Application 레이어에 존재해야 한다

어 ? 나쁘지 않은데 ?

LaunchScreenVC를 Presentation 레이어에 두고, AppCoordinator에서 실행시키면 되지 않을까 ?

이렇게 하면 내가 생각했을 때 얻게되는 (내 생각에서의) 이점이

• 추가적인 Coodinator를 만들지 않아도 된다는 것
• SceneDelegate에서 AppCoordinator에 UIWindow를 인스턴스로 넘겨준다면 LaunchScreenVC를 UIWindow 위에서 실행시켜서 별도로 NavigationController를 만들지 않아도 되는 것

음 .. 이전까지는 LaunchScreen을 위해 UINavigationController를 만드는게 의미가 있을까? 하는 궁금증도 생겼고, 조금 더 알아봐야 하겠지만 굳이..? 라는 생각이 들었다

결과적으로 첫 번째 방법보다는 두 번째 방법이 더 좋다는 생각이 들었다 하지만 이걸 적용할지 말지는 건빵을 좀 더 자세히 들여다보고 생각해볼듯 ...

.

두 번째 고민 - TabBarController와 NavigationController

지금 취준중인데, 그 과정에서 어떤 기업의 서비스를 살펴보다가 UINavigationController 위에 UITabBarController가 있는 것 (아마? ㅎㅎ;;)을 확인했다

이렇게 되면, Tab 별로 Navigation이 관리되지 않고, Tab 위에 계속 화면이 쌓이게 되는 것이다

뷰와 Tab의 흐름에 따라서 적절한지, 적절하지 않은지 다를 것이라고 생각한다

• 만약 TabBar를 계속 보여주고 싶고, Tab별로 별도의 Navigation이 필요하다면, TabBarController 아래에 UINavigationController를 두는 것 대신, 각 Tab 위에 UINavigationController를 둬야 할 것이다

• 그렇게 뎁스가 깊은 서비스가 아니기 때문에,Tab 별로 Navigation을 관리해야 할 필요가 없다면 TabBarController 아래에 UINavigationController를 두고 단일 Navigation으로 가져가는 것도 괜찮을 것 같다

하지만 내가 봤던 서비스는 뎁스가 괴애애앵장히 깊었고, 따라서 첫 번째 방법이 적절하다는 생각이 들었....

무튼 건빵은 서비스 볼륨은 나름 크지만 뎁스는 깊지 않기 때문에, 두 번째 방법으로 가도 되긴 하지만, 연습을 위해서는 첫 번째 방법을 채택했다

연습

첫 번째 고민에서는 첫 번째 방법을

1. AppCoordinator 에서 LaunchScreenCoordinator로 이동한 뒤
2. LaunchScreenViewController를 실행시키고
3. LaunchScreenViewModel에서 viewWillAppear 이벤트가 도달하면
4. 로그인 여부를 판단하고, 이에 따라 AppCoordinator에게 적절한 플로우를 실행하라고 메시지를 전송하는 것

두 번째 고민에서는 첫 번째 방법을

1. 만약 TabBar를 계속 보여주고 싶고, Tab별로 별도의 Navigation이 필요하다면,
2. TabBarController 아래에 UINavigationController를 두는 것 대신,
3. 각 Tab 위에 UINavigationController를 둬야 할 것이다

이 두 가지를 고려하면서 연습을 해봤다

.

CoordinatorType

모든 Coodinator가 가져야 할 요소들이다 '추상화'시켜 '메시지'를 전송할 수 있어야 하므로, protocol로 추상화

protocol CoordinatorType: AnyObject {
    var parent: ParentCoordinatorDelegate? { get set }
    var navigationController: UINavigationController { get }
    var children: [CoordinatorType] { get set }
    var flowType: CoordinatorFlowType { get }

    func start()
    func finish()
}

extension CoordinatorType {
    func finish() {
        children.removeAll()
        parent?.finish(child: self)
    }
}

.

AppCoordinator

먼저 AppCoordinator에서 할 책임은

• LaunchScreenFlow를 보여주는 것과
• MainFlow를 보여주는 것

즉, showLaunchScreeFlow와 showMainFlow라는 메시지를 전송할 수 있어야 한다

그렇게 먼저 만든 프로토콜

protocol AppCoordinatorType: CoordinatorType {
    func showLaunchScreenFlow()
    func showMainFlow()
}

그리고 이에 대한 구현부

final class AppCoordinator: AppCoordinatorType {

    weak var parent: ParentCoordinatorDelegate? = nil
    var children: [CoordinatorType] = []
    var flowType: CoordinatorFlowType { .app }

    var navigationController: UINavigationController
    private var tabBarController: UITabBarController?

    init(navigationController: UINavigationController) {
        self.navigationController = navigationController
    }

    func start() {
        showLaunchScreenFlow()
    }

    func showLaunchScreenFlow() {
        let launchScreenCoordinator = LaunchScreenCoordinator(navigationController: self.navigationController)
        launchScreenCoordinator.start()
        launchScreenCoordinator.parent = self
        self.children = [launchScreenCoordinator]
    }

    func showMainFlow() {
        let tabs: [Tab] = Tab.allCases
        let tabNavigations: [UINavigationController] = tabs.map(makeTabNavigation)
        let tabBarController = makeTabBarController()

        self.tabBarController = tabBarController
        self.tabBarController?.setViewControllers(tabNavigations, animated: false)
        self.tabBarController?.selectedIndex = 0

        Array(zip(tabs, tabNavigations))
            .map { tab, navigation in makeTabCoordinator(type: tab, from: navigation) }
            .forEach { coordinator in
                coordinator.parent = self
                coordinator.start()
                children.append(coordinator)
            }

        guard let sceneDelegate = UIApplication.shared.connectedScenes.first?.delegate as? SceneDelegate else { return }
        sceneDelegate.changeRootViewController(to: tabBarController, animated: true)
    }
}

showLaunchScreenFlow()

func showLaunchScreenFlow() {
    let launchScreenCoordinator = LaunchScreenCoordinator(navigationController: self.navigationController)
    launchScreenCoordinator.start()
    launchScreenCoordinator.parent = self
    self.children = [launchScreenCoordinator]
}

LaunchScreen을 보여주는 Coordinator를 만들고 실행시킨다

showMainFlow()

func showMainFlow() {
    let tabs: [Tab] = Tab.allCases
    let tabNavigations: [UINavigationController] = tabs.map(makeTabNavigation)
    let tabBarController = makeTabBarController()

    self.tabBarController = tabBarController
    self.tabBarController?.setViewControllers(tabNavigations, animated: false)
    self.tabBarController?.selectedIndex = 0

    Array(zip(tabs, tabNavigations))
        .map { tab, navigation in makeTabCoordinator(type: tab, from: navigation) }
        .forEach { coordinator in
            coordinator.parent = self
            coordinator.start()
            children.append(coordinator)
        }

    guard let sceneDelegate = UIApplication.shared.connectedScenes.first?.delegate as? SceneDelegate else { return }
    sceneDelegate.changeRootViewController(to: tabBarController, animated: true)
}

1. Tab 별로 UINavigationController를 만든다
2. TabBarController를 만든다
3. 1.에서 만든 Tab 별 UINavigationController를 setViewControllers()로 적절히 설정해준다
4. Tab과 1.에서 만든 Tab 별 UINavigationController로 각 Tab에 알맞는 Coordinator를 만들고,
5. 현재 Coordinator의 children에 추가한다

이렇게 되면 각 Tab 별로 UINavigationController를 갖고, 각각 Coordinator도 갖게 된다

마치며

다음에는 프로젝트 세팅 관련 글로 돌아올 예정 ...

.

사실 코드 설명은 ... 글을 쓰다보니 지쳐서 조금 간략하게 설명했지만 ... 아래 레포가 연습한 레포이니까 참고하면 좋을듯 ㅎㅎ ;; Coordinator Pattern Practice

.

참고 A comprehensive guide to Coordinator Pattern in Swift Coordinator pattern with Tab Bar Controller [iOS] 메이트러너: 코디네이터 패턴 적용기

서론

SOPT 32기 앱잼 때 한 <건빵>을 리팩토링 하려고 한다

이에 대한 이유는 ... 아래와 같음

• 사실 가장 큰 이유는 역량 강화겠지..? 성능을 ~에서 ~까지 ~% 개선했다 또는 ~~를 사용해 Developer Experience를 개선했다 등 ...

• 맨 처음 앱잼 할 때 있었던 기능들이 많았는데, 현실적으로 힘들다는 생각에 다이어트를 많이 시켰다 그래서 그 때 넣고자 했던 기능들 (지도, 위치기반 등)을 추가해야 하는데, 지금 코드에서 추가하면 정말 개판이 될 것 같아 추가 기능 개발 전에 리팩토링을 돌려야 한다는 생각

• 원래 일정대로라면 작년 말? 쯤에 출시를 했어야 했는데 App Store에서 빠꾸먹어서 ... 계속 미루다미루다 2월 중순쯤에 출시를 했다 무튼 요는 이게 아니라 32기 앱잼이 끝난 이후(2023.08쯤?)부터 지금까지 새롭게 공부한거나 알게 된 것들을 잘 적용해보고 싶은 생각

크게 이렇게 3가지 이유 때문에 리팩토링을 하게 되었다 !!

리팩토링 계획

요번 리팩토링 때는 아래의 것들을 적용하려고 한다

1. Clean Architecture 넥스터즈 24기를 하면서 리드 개발자 형님의 도움에 클린 아키텍처를 잘 '이해'하게 되었다 그래서 이번엔 실제로 내가 설계하고 적용해보면서 체화하고 싶은 ...!!

2. Coordinator Pattern 이건 내 개인적인 욕심 ? 원래 ViewController에서 담당하던 '뷰의 전환'이라는 역할을 다른 애한테 넘겨주고 싶었다 그동안 MVC 또는 MVVM 쓰면서 고생 많았지 ㅠㅠ 이제 편히 쉬렴 ... 이제는 역할을 많이 덜어줄거다

3. Entity 설계 이제까지 프로젝트를 진행하면서 팀원들끼리 크게 Entity를 정하고 간 적이 없었다 그래서 각자 필요할때마다 만들고 싶은 Model을 만들고 .. 하다보니 겹치는 Entity가 많았기 때문에, 이번에는 뷰 보면서 필요한 것들로 적절히 분배하고 설계할 생각

4. '제대로 된' 디자인 시스템 Funch 프로젝트를 진행하면서 얼추 만들어보긴 했는데 ... 그때도 다시 보면 좀 난잡하다 이제는 그래도 여기저기서 많이 쓰이는 요소들을 묶어서 디자인 시스템으로 관리해보고자 한다

5. 에러처리 부끄럽지만 ... 지금까지 개발 하면서 제대로 된 에러처리를 한 적이 없 ....ㅠ 그냥 냅다 return nil 로 때려박은 경험이 많다 ... 그래서 요번엔 더 나은 UX를 위해 에러처리도 제대로 해보고 싶은 생각

6. DIContainer 설계 이것도 Funch 프로젝트를 하면서 처음 알게 된 애인데, 리드 형이 메모리 개선되는 것을 보여주니까 꽤나 유용하다는 생각이 들었다 지난번에는 SwiftUI에서 EnvironmentObject로 적용했었는데, 이번에는 UIKit에서 나름대로의 방법(?)으로 적용해보고 싶은 생각

7. Combine 이전에 RxSwift로 플젝을 잠시 진행한 적이 있어서 공부를 좀 했었는데, 역시 순정은 못이기지 ... 는 장난이고 좀 더 Raw 한 Combine도 사용하면서 custom publisher나 subscriber도 만들면 좋은 경험이겠다 싶어서 사용 예정 !

자잘한 것들 더 따져보면 새롭게 적용하려는게 더 많을 수도 있지만 ... 일단은 요정도 생각이 들었다

다 사용할지 안할지도 모르겠고, 해보고 싶은 것들은 이정도 !!

맨 처음으로는 Coordinator Pattern 설계를 하지 않을까 싶다 ! 다음 글에 작성할 예정 ㅎ

건빵 레포를 ... 공개하고 싶은데 ... 지금은 너무 부끄러운 코드들이라 ... 리팩토링이 얼추 마무리 되면 공개하겠다 !!

서론

• 객체지향에 입문한 사람들의 가장 큰 실수 → ‘협력’을 고려하지 않고 객체가 뭘 갖고 뭘 할 수 있는지부터 생각하는 것 → 객체지향에서 중요한 것은 ‘협력’ → 객체들이 어떻게 서로 협력해내는지 → 어떤 협력에 참여하는지 ⇒ 객체가 필요한 행동 결정 → 객체가 필요한 행동 ⇒ 객체가 가질 상태 결정

협력

요청하고 응답하며 협력하는 사람들

• 협력은 여러 객체가 참여하며, 연쇄적으로 이루어짐 → 시작은 한 객체가 도움을 청할 때 시작 → 처리를 할 수 있을 것 같은 다른 객체에 요청을 보냄

재판 속의 협력

• 앨리스의 이야기 속에서의 협력
  1. 누군가가 왕에게 재판을 요청
  2. 왕이 하얀 토끼에게 증인을 부를 것을 요청
  3. 요청을 받은 토끼는 모자 장수에게 증인석으로 입장할 것을 요청
  4. 모자 장수는 증인석에 입장함으로써 토끼의 요청에 응답 = 토끼의 왕의 요청에 대한 응답
  5. 왕은 모자 장수에게 증언할 것을 요청
  6. 모자 장수는 알고 있는 내용을 증언하여 왕의 요청에 대해 응답

• 누군가 ⇒ 왕 : 재판하라 → 왕은 재판을 수행할 의무가 있음 & 재판에 필요한 지식이 있음

• 왕 ⇒ 토끼 : 목격자 불러와라 → 토끼는 목격자에 대해 알고 있음 & 목격자를 부를 의무가 있음

• 왕 ⇒ 모자 장수 : 증언하라 → 모자 장수는 증언할 내용을 알고 있음 & 증언할 의무가 있음

책임

책임의 분류

• 책임 : 객체에 의해 정의되는 응집도 있는 행위의 집합 → 객체가 알아야 할는 정보와 객체가 수행할 수 있는 행위에 대해 개략적으로 서술한 문장

• 책임의 구성

  • 객체가 무엇을 알고 있는가 ( knowing )

    • 개인적인 정보에 관해 아는 것
    • 관련 객체에 관해 아는 것
    • 자신이 유도하거나 계산할 수 있는 것에 관해 아는 것

- 무엇을 할 수 있는가 ( doing )

    - 객체를 생성하거나 계산을 하는 등의 스스로 하는 것
    - 다른 객체의 행동을 시작시키는 것
    - 다른 객체의 활동을 제어하고 조절하는 것

• 앨리스의 이야기

  • 왕

    • Doing: 왕은 재판을 집행 / 토끼에게 증인을 불러오도록 요청 / 증인에게 증언하라고 요청 → “다른 객체들의 활동을 제어하고 조율” → 하는 것에 관련된 책임을 수행

  • 토끼

    • Knowing: 토끼는 목격자가 모자장수임을 알고 있음 → “관련된 객체에 대해 아는 것” → 아는 것에 대한 책임
    • Doing: 증인에게 증인석에 입장하도록 요청 → “다른 객체의 행동을 시작시키는 것” → 하는 것에 대한 책임

  • 모자 장수

    • Knowing: 자신이 알고 있는 사실을 증언해야 함 → “자신이 유도하거나 계산할 수 있는 것에 관해 아는 것” → 아는 것에 대한 책임
    • Doing: 스스로 증인석에 입장 → “객체를 생성하거나 계산을 하는 등의 스스로 하는 것” → 하는 것에 대한 책임

• 책임은 객체의 외부에 제공해 줄 수 있는 정보와 외부에 제공해 줄 수 있는 서비스의 모음 → 책임은 객체의 공용 인터페이스

책임과 메시지

• A객체(송신자) ⇒ B객체(수신자): 요청 전송 → 요청 은 수신자의 책임이 수행되게 함 → 이런 과정을 메시지 전송 이라 함

• 책임의 수준 ≠ 메시지의 수준 → 책임은 객체의 협력을 위해 수행해야 하는 것들을 개략적으로 서술한 것 → 메시지는 이 책임을 필요한 여러 메시지로 분할해서 진행

객체지향 설계의 시작점

협력에 참여하기 위해 어떤 객체가 어떤 책임을 수행해야 하고 어떤 객체로부터 메시지를 수신할 것인지를 결정하는 것

역할

책임의 집합이 의미하는 것

• 어떤 객체가 수행하는 책임의 집합 = 협력에서 해당 객체가 수행하는 역할

역할이 답이다

• 모자 장수, 요리사, 앨리스가 증인으로 선택된 상황 → 총 3 가지의 협력 상황 → 모자 장수, 요리사, 앨리스를 증인 이라는 역할로 포괄한다면, 단일 협력 상황으로 추상화 가능

• 추상화된 협력
  1. 누군가가 판사에게 재판을 요청
  2. 판사는 토끼에게 증인을 부를 것을 요청
  3. 판사의 요청을 받은 토끼는 증인에게 증인석으로 입장할 것을 요청
  4. 증인은 증인석에 입장하여 토끼의 요청에 응답
  5. 증인이 증인석에 입장함으로써, 토끼에 대한 판사의 요청에 대한 응답
  6. 판사는 증인에게 증언할 것을 요청
  7. 증인은 자신이 알고 있는 내용을 증언함으로써 판사의 요청에 응답

• 역할을 대체할 수 있는 객체는 동일한 메시지를 이해할 수 있는 객체여야 함

• 메시지가 책임을 의미함 → 동일한 역할 수행 가능 = 동일한 책임의 집합 수행 가능 → 동일한 역할 수행 가능 = 동일한 메시지를 수신할 수 있음 → 동일한 역할 수행할 수 있는 객체들끼리 묶어서 추상화 가능

• 추상화를 한다면 ( 역할을 부여한다면 ) → 인지 과부화 줄일 수 있음 = 단순성, Simplicity → 협력이 유연해짐 = 유연성, Flexibility → 재사용성이 높아짐 = 재사용성, Reusability

협력의 추상화

• 역할은 여러 객체가 협력에 참여 가능하게 하여 협력을 추상화 할 수 있게 함
• 협력의 추상화는 협력의 개수를 줄이고, 협력에 참여하는 객체를 추상적인 역할로 대체

대체 가능성

• 역할은 협력 안에서 구체적 객체로 대체 가능 → 동일 역할이면, 다른 객체로 대체 가능 → 동일 역할(동일한 책임의 집합)을 모두 수행할 수 있어야 함

• 객체는 역할에 주어진 책임 이외에도 다른 책임을 수행할 수 있음 → 역할이 암시하는 것 보다 더 많은 책임 가질 수 있음 → 역할-객체 관계 = 일반화-특수화 관계

객체의 모양을 결정하는 협력

흔한 오류

객체에 대한 선입견

• 객체의 존재 이유는 데이터를 저장하기 위해 → 진짜 객체의 존재 이유는 협력에 참여하기 위해 → 실제로 중요한 것은 객체의 행동(책임)
• 객체지향이 클래스-클래스 간의 관계를 표현하는 정적인 측면에 집중 → 객체지향은 협력에 중점을 두고, 객체는 협력에 참여할 때 동적임

협력을 따라 흐르는 객체의 책임

• 객체를 설계하기 전에 올바른 협력을 설계해야 함 → 설계에 참여하는 객체들이 주고받을 요청과 응답의 흐름을 설계해야 함

  1. 객체에게 책임을 할당 = 객체가 외부에 제공할 행동
  2. 해당 행동에 필요할 데이터 결정
  3. 클래스의 구현

• 협력에 필요한 책임을 얼마나 합리적, 적절하게 설계했는지가 설계의 품질을 결정

협력을 가장 먼저 정의하자

객체지향 설계 기법

• 책임-주도 설계 → 책임들을 식별하고 책임을 할당

• 디자인 패턴 → 반복적으로 사용하는 해결 방법을 정의해 둔 템플릿

• 테스트-주도 개발 → 테스트를 먼저 작성하고 통과하는 것들만 코드로 작성

책임-주도 설계

• 객체의 책임을 중심으로 시스템을 구축하는 방법 → 시스템의 기능은 더 작은 책임으로 분할 → 각 책임은 특정 객체에 할당 → 특정 책임을 여러 객체가 수행할 수 있다면, 추상화

• 시스템의 책임 ⇒ 객체의 책임으로 할당 → 객체가 책임을 수행할 때, 협력자를 찾아 다른 책임을 할당

책임-주도 설계 정리

• 시스템이 사용자에게 제공해야 하는 시스템 책임을 파악
• 시스템 책임을 더 작은 책임으로 분할
• 분할된 책임을 수행할 수 있는 적절한 객체 또는 역할을 찾아 할당
• 객체가 책임을 수행하는 도중 도움이 필요하면 또 이 도움이라는 책임을 질 다른 객체를 찾음
• 해당 객체에게 책임을 할당하고, 협력을 이룸

디자인 패턴

-

테스트-주도 개발

-

객체지향의 사실과 오해

서론

과거 런던의 지하철 노선도

현재 런던 지하철 노선도

과거와 현재의 런던 지하철 노선도를 살펴보면, 훨씬 가독성이 좋음

과거의 런던 지하철 노선도는 다른 것들보다 아래 요소들을 보이는데에 집중함

• 거리
• 실제 위치

하지만 사람들은 실제 위치나 거리에 생각보다 신경쓰지 않아 현재는 다른 요소들에 집중함

• 순서
• 환승 가능 역

즉, 과거에는 목적이 잘못 설정되어 가독성 떨어지고, 사람들이 보기 어려운 노선도를 사용했지만, 현재는 사람들이 노선도를 보는 목적을 제대로 파악하여 간단히 만들었음 → 지하철 노선도를 추상화

추상화를 통한 복잡성 극복

• 현실에 존재하는 것들을 이해해야 하는데, 그렇다기엔 너무 복잡 → 이해하기 쉽고 간단한 것으로 현실을 분해하고 단순화 해야 함

• 추상화란 현실에서 시작하되, 목적에 따라 정말 필요한 요소들만 남겨 본질을 보이게 함

• 하지만, 추상화도 목적에 맞지 않게 사용한다면, 잘못 사용되는 것

이 책에서 추상화의 정의

어떤 양상, 세부 사항, 구조를 좀 더 명확하게 이해하기 위해 특정 절차나 물체를 의도적으로 생략하거나 감춤으로써 복잡도를 극복하는 방법이다.

복잡성을 다루기 위해 추상화는 두 차원에서 이뤄진다.

• 첫 번째 차원은 구체적인 사물들 간의 공통점은 취하고 차이점은 버리는 일반화를 통해 단순하게 만드는 것이다.
• 두 번째 차원은 중요한 부분을 강조하기 위해 불필요한 세부 사항을 제거함으로써 단순하게 만드는 것이다.

모든 경우에 추상화의 목적은 목잡성을 이해하기 쉬운 수준으로 단순화하는 것이라는 점을 기억하라.

따라서, 객체지향 패러다임은, `객체`라는 `추상화`를 통해 현실의 복잡성을 극복한다

객체지향과 추상화

모두 트럼프일 뿐

이상한 나라의 앨리스 이야기 중 앨리스가 정원에 입장해 하트 여왕과 다양한 트럼프 병사들, 그리고 하얀 토끼를 만나는 장면에 대한 묘사

앨리스는 마지막에 “기껏해야 트럼프에 불과해. 무서워할 필요 없어” 라고 말함

그룹으로 나누어 단순화하기

앨리스의 그룹화

• 앨리스는 “기껏해야 트럼프에 불과해. 무서워할 필요 없어” 이라고 말함 → 다양한 트럼프 병사들을 그저 ‘트럼프 병사’로 그룹화 함 → 하지만 이 그룹에 ‘하얀 토끼’는 포함되지 않음 / 동일한 특성을 갖고 있지 않기 때문 → 명확한 경계를 가져 구별할 수 있는 것들을 객체라고 함

• 이번 이야기의 등장인물들 중, 정원사, 병사, 신하, 왕자, 공주, 왕, 왕비, 하트 잭 … 등은 모두 ‘트럼프’와 동일한 외형과 행동 방식을 지니고 있음 → 위 등장인물들을 모두 트럼프 그룹에 포함시킬 수 있음 → 하얀 토끼는 트럼프에 속하지 못함 → 결과적으로 앨리스는 등장인물들으 두 개의 그룹으로 나눔 / 트럼프, 토끼

개념

개념 이란 공통점을 기반으로 객체들을 묶기 위한 그릇 우리가 인식하고 있는 다양한 사물이나 객체에 적용할 수 있는 아이디어나 관념

• 개념을 이용하면 객체를 여러 그룹으로 분류할 수 있음 → 개념은 여러 객체의 공통점을 기준으로 객체들을 분류할 수 있는 ‘체’

• 어떤 객체에 특정 개념을 적용할 수 있게 되어, 해당 개념 그룹에 속하게 될 때 → 해당 객체를 이 개념의 인스턴스라고 함

객체란, 특정 개념을 적용할 수 있는 구체적인 사물을 의미함 개념이 객체에 적용되었을 때 객체를 개념의 인스턴스라고 함

개념의 세 가지 관점

일반적으로 개념을 객체의 분류 장치로 생각할 때, 세 가지 관점이 있음

• 심볼: 개념을 가리키는 간략한 이름이나 명칭 e.g. ‘트럼프’라는 이름
• 내연: 개념의 완전한 정의를 나타내며, 내연의 의미를 이용해 객체가 개념에 속하는지 여부를 확인할 수 있음 e.g. ‘트럼프’는 ‘몸이 납작하고 두 손과 두 발이 네모난 몸 모서리에 달려 있음’
• 외연: 개념에 속하는 모든 객체의 집합 e.g. ‘정원사’, ‘병사’, ‘신하’, ‘왕자와 공주’, ‘하객’, ‘하트 잭’, ‘하트 왕’, ‘하트 여왕’ 등

개념을 이용해 공통점을 갖는 객체들을 분류할 수 있음 !!!

객체를 분류하기 위한 툴

분류란 객체에 특정한 개념을 적용하는 작업이다. 객체에 특정한 개념을 적용하기로 결심했을 때 우리는 그 객체를 특정한 집합의 멤버로 분류하는 것.

• 분류가 객체지향의 품질을 결정함 → 객체를 적절히 분류하면, 유지보수성 증가, 변경에 유연하게 대처 가능 → 적절한 분류 체계가 객체들 간의 ‘지도’ 역할을 함

분류는 추상화를 위한 도구다

• 추상화의 두 가지 차원 → 사물 간의 공통점만 취하고 차이점은 버림 → 필수적인 부분을 강조하기 위해 불필요한 세부사항은 무시

• 개념은 구체적인 사물들 간의 공통점을 기반으로 만든 분류 체계 → 따라서, 추상화의 두 가지 차원 중, 사물 간의 공통점을 취한 것에 해당

타입

타입은 개념이다

• 개념을 좀 더 컴공스럽게 말한다면 : 타입

타입의 정의

타입은 개념과 동일하다.

따라서 타입이란 우리가 인식하고 있는 다양한 사물이나 객체에 적용할 수 있는 아이디어나 관념을 의미한다.

어떤 객체에 타입을 적용할 수 있을 때 그 객체를 타입의 인스턴스라고 한다.

타입의 인스턴스는 타입을 구성하는 외연인 객체 집합의 일원이 된다.

데이터 타입

타입에 관한 두 가지 조언

• 타입은 데이터가 어떻게 사용되느냐에 관한 것 → 숫자형 데이터들끼리는 사칙연산이 가능 → 문자열 데이터들끼리는 두 문자열을 연결하거나 길이를 알 수 있음 → 데이터의 타입을 결정하는 것은, 데이터에 적용할 수 있는 작업, 즉, 연산자 → 데이터에 어떤 연산자를 적용할 수 있는지가 이 데이터의 타입을 결정함

• 타입에 속한 데이터를 메모리에 어떻게 표현하는지는 외부에서 철저히 감춰짐

데이터 타입의 정의

데이터 타입은 메모리 안에 저장된 데이터의 종류를 분류하는 데 사용하는 메모리 집합에 관한 메타데이터다. 데이터에 대한 분류는 암시적으로 어떤 종류의 연산이 해당 데이터에 대해 수행될 수 있는지를 결정한다.

객체와 타입

• 이전에 데이터 타입에 대해 설명한 이유 → 전통적인 데이터 타입과 객체지향의 타입 사이에는 깊은 연관이 있기 때문 → 객체지향에서 우리는 객체를 일종의 데이터처럼 사용

객체에 관한 두 가지 조언

• 이전에 ‘타입에 관한 두 가지 조언’과 동일

• 어떤 객체가 어떤 타입에 속하는지를 결정하는 것은 객체가 수행하는 행동 → 동일한 행동을 한다면, 동일한 객체로 분류 가능

• 객체가 내부적으로 어떻게 표현되는지는 외부에서 철저히 감춰짐 → 객체의 타입은 내부 표현과는 일절 상관 없음

행동이 우선이다

• 어떤 객체를 다른 객체와 동일한 타입으로 분류하는 기준 ? → 두 객체가 동일한 행동을 하는지 → 동일한 상태를 갖고 있더라도, 다른 행동이라면 다른 타입 → 객체의 타입을 결정하는건 객체의 행동 뿐

• 같은 타입 = 동일한 행동 → 동일한 행동 = 동일한 책임 → 동일한 책임 = 동일한 메시지의 수신 → 같은 타입인 객체는, 내부의 데이터 표현 방식이 다르더라도, 동일한 메시지를 수신해 이를 처리할 수 있음 → But, 메시지의 처리 방식은 다를 수 있음 → 다형성

• 객체가 할 수 있는 행동만을 외부에 공개하고, 내부의 데이터는 행동 뒤로 감춰야 함 → 캡슐화

• 객체를 원활히 분류하기 위해서는 내부의 데이터가 아니라 외부의 행동을 먼저 고려해야 함 1) 객체가 외부에 제공해야 하는 책임을 결정 2) 책임을 수행하는 데 적합한 데이터를 결정 3) 책임을 수행하는 데 필요한 외부 인터페이스 뒤로 데이터를 캡슐화 → 책임-주도 설계

타입의 계층

트럼프 계층

• 정원사, 병사, 신하, 왕자, 공주 등은 정말 ‘트럼프’ 일까 ? → 카드게임을 할 때 트럼프와 외형은 동일하지만, 행동은 동일하지 않음 → ‘트럼프’가 아니라 ‘트럼프 인간’이 더 정확 → ‘트럼프 인간’ 타입은 ‘트럼프’ 타입의 객체가 할 수 있는 행동 + 걸어다니는 행동 할 수 있음 → ‘트럼프 인간’은 ‘트럼프’보다 조금 더 특화된 행동을 함

• 외연의 관점에서 ‘트럼프’와 ‘트럼프 카드’를 살펴보자 → ‘트럼프 인간’의 외연은 ‘트럼프’ 외연의 부분집합 → ‘트럼프 인간’과 ‘트럼프’ 사이의 관계를 일반화/특수화 관계라고 함

일반화 / 특수화 관계

• 일반화와 특수화는 동시에 이뤄짐 → ‘트럼프 인간’은 ‘트럼프’를 좀 더 구체적으로 표현한 것 → 어떤 객체가 다른 객체보다 더 구체적인 상태를 표현한다고 일반화 / 특수화 관계가 성립하는 것은 아님 → 한 타입이 다른 타입보다 더 구체적인 행동을 해야 함 → 일반화 / 특수화 관계를 결정하는 것도 행동

• 내연, 외연 관점에서의 일반화 / 특수화 관계 → 일반적인 타입의 외연은 특수한 타입의 외연보다 크다 → 일반적인 타입의 내연의 가짓수는 특수한 타입의 내연의 가짓수보다 작다

  

슈퍼타입과 서브타입

• 일반화 / 특수화 관계 → 슈퍼타입 / 서브타입 관계 → 슈퍼타입: 일반적인 타입 → 서브타입: 특수한 타입

• 슈퍼타입과 서브타입의 관계는 두 타입의 행동에 의해 결정됨 → 한 타입이 다른 타입의 서브타입이 되기 위해서는 행위적 호환성을 만족해야 함 → 어떤 타입을 다른 타입의 서브타입이라고 말할 수 있으려면 다른 타입을 대체할 수 있어야 함 → Liskov Substitution Principle ( LSP )

• 일반화 / 특수화 관계를 표기하는 방법 → 슈퍼타입을 상단에, 서브타입을 하단에 → 속이 빈 삼각형 화살표가 서브타입에서 슈퍼타입을 향하도록 연결

  

일반화는 추상화를 위한 도구다

• 추상화의 두 번째 차원은 중요한 부분을 강조하기 위해 불필요한 세부사항을 제거해 단순화하는 것 → 앨리스가 ‘트럼프 인간’이 아니라 ‘트럼프’라고 한 이유도 이와 유사 → ‘트럼프 인간’이 할 수 있는 구체적인 행동은 불필요해서 단순화 한 ‘트럼프’라고 생각

• 앨리스는 추상화의 두 가지 기법을 모두 사용함 → 등장인물들 사이의 차이점은 배제하고 공통점만으로 ‘트럼프 인간’으로 분류함 → ‘트럼프 인간’을 더 단순한 관점에서 바라보고 불필요한 세부 사항은 무시함으로서 ‘트럼프’로 일반화

정적 모델

타입의 목적

• 왜 타입을 사용하는가 ? → 인간의 인지 능력으로는 동적으로 변화하는 객체의 복잡성을 따라가기 어렵기 때문 → 앨리스의 키가 아무리 변해도 앨리스는 앨리스

• 타입은 동적으로 변화하는 객체의 상태에 무관하게 정적인 모습으로 다룰 수 있게 해줌

그래서 결국 타입은 추상화다

• 타입을 사용함으로써 객체의 동적인 상태를 정적으로 표현할 수 있게 해줌 → 결국 타입도 추상화

타입은 시간에 따른 객체의 상태 변경이라는 복잡성을 단순화할 수 있는 효과적인 방법

동적 모델과 정적 모델

• 스냅샷: 하나의 객체가 특정 시점에 구체적으로 어떤 상태를 갖는지 → UML에서 객체 다이어그램이라고도 불림 → 동적 모델: 스냅샷처럼 객체의 변화를 포착하는 것

• 타입 모델: 객체가 가질 수 있는 모든 상태와 행동을 시간에 독립적으로 표현한 것 → 정적 모델 이라고도 함

• 객체지향 애플리케이션을 잘 활용하기 위해서는 동적 모델, 정적 모델을 적절히 잘 사용해야 함 → 클래스를 작성하는 시점에는 변화하지 않기 때문에 정적 모델 → 디버깅 등 객체의 변화를 따라가는 시점에는 동적 모델

클래스

• 객체지향에서 정적인 모델의 ‘타입’은 주로 클래스를 통해 구현됨 → 하지만, 클래스는 타입의 다양한 구현 방법 중 하나 → 따라서, 클래스와 타입은 다른 개념 → 클래스는 타입의 구현 외에도 코드의 재사용의 용도로도 사용됨

• 객체를 분류하는 기준은 타입 / 타입을 나누는 기준은 객체가 수행하는 행동

객체지향의 사실과 오해

1997년 심리학자 엘리자베스 스펠크와 필립 켈만은 어린 아기들이 물체를 인지하는 방법을 연구하기 위해 한 가지 실험을 수행

그 결과, 사람은 태어난 지 얼마 안 된 시기부터 뚜렷한 경계를 가지고 함께 행동하는 물체를 하나의 개념으로 인지함

객체지향과 인지 능력

위 실험에서와 같이, 사람은 기본적으로 뚜렷한 경계를 가지고 함께 행동하는 물체를 하나의 개념으로 인지

객체, 그리고 이상한 나라

이상한 나라의 앨리스에서 앨리스가 정원으로 통하는 문을 통과하기 위해 음료, 부채, 버섯 등을 사용해 키가 변하는 것으로 비유 중

앨리스 객체

음료, 부채, 버섯 등을 사용하는 행동에 따라 앨리스의 키라는 상태가 변경됨

이런 점에서,

• 앨리스는 상태를 가지며, 상태는 변경 가능하다
• 앨리스의 상태를 변경시키는 것은 앨리스의 행동이다
  • 행동의 결과는 상태에 의존적이며, 상태를 이용해 서술할 수 있다
  • 행동의 순서가 결과에 영향을 미친다
• 앨리스는 어떤 상태에 있더라도 유일하게 식별 가능하다

객체, 그리고 소프트웨어 나라

객체를 효과적으로 설명하기 위해서는 상태, 행동, 식별자를 지닌 실체로 보는 것이 가장 효과적

이 책에서 객체의 정의는,

객체란 식별 가능한 개체 또는 사물이다. 객체는 자동차처럼 만질 수 있는 구체적인 사물일 수도 있고, 시간처럼 추상적인 개념일 수도 있다. 객체는 구별 가능한 식별자, 특징적인 행동, 변경 가능한 상태를 가진다. 소프트웨어 안에서 객체는 저장된 상태와 실행 가능한 코드를 통해 구현된다.

상태

상태가 왜 필요할까 ?

• 어떤 행동의 결과는 그 이전 행동에 대한 결과에 의해 결정됨 → 하지만, 그 이전의 행동들을 모둘 기억하기에는 비효율적 → 이전 행동에 대한 결과를 상태로 저장해두고, 현재 상태에 어떤 행동을 가해 새로운 상태로 갱신 ⇒ 즉, 상태가 있으면, 이전에 실행한 행동들을 모두 기억해두지 않아도 됨

상태와 프로퍼티

• <이상한 나라의 앨리스>에서, ‘앨리스’, ‘토끼’, ‘문’ 등은 객체로 생각할 수 있음 → 뚜렷한 경계를 갖고, 식별 가능하며, 상태와 행동을 갖기 때문
• 하지만, 앨리스의 ‘키’나 ‘위치’는 객체가 아님 → 스스로 독립적인 의미보다는, 다른 것의 특성을 표현하기 위한 수단으로 쓰이기 때문 → 프로퍼티는 객체의 특성을 표현할 수 있음
• 객체를 사용해 다른 객체의 상태를 표현할 때도 있음 → ‘앨리스가 음료를 들고 있음’이라는 상태는 ‘앨리스’ - ‘음료’ 사이의 연결로 표현할 수 있음 → 객체도 객체의 특성을 표현할 수 있음

따라서, `모든 객체는 단순한 값과 객체의 조합으로 표현할 수 있다`
이 때, 객체의 상태를 구성하는 모든 특징을 `프로퍼티`라고 한다

앨리스’가 ‘음료’를 마시기 위해 들고 있는 상황

• ‘앨리스’와 ‘음료’ 모두 객체로 판단할 수 있음 → 앨리스와 음료 모두 서로의 상태에 영향을 줌 → 앨리스가 음료를 들고 있는 상태에서만 가능 → 객체들 사이의 링크를 통해서만 메시지를 주고받을 수 있음 → ‘앨리스’와 ‘음료’가 상호작용을 하려면 ‘들고 있다’라는 링크가 있어야 함 → 즉, 객체가 다른 객체의 상태를 표현하고 있을 때에는, 링크가 필요하다
• ‘엘리스’의 ‘키’에 따라서 문을 지나갈 수 있는지 없는지 결정됨 → 앨리스의 키처럼 객체를 구성하는 단순한 값을 속성이라고 함

💡 프로퍼티는 단순한 값인 속성과 다른 객체를 가리키는 링크라는 두 가지 종류의 조합으로 표현

이 책에서 객체의 상태 정의

상태는 특정 시점에 객체가 가지고 있는 정보의 집합으로 객체의 구조적 특징을 표현한다. 객체의 상태는 객체에 존재하는 정적인 프로퍼티와 동적인 프로퍼티 값으로 구성된다. 객체의 프로퍼티는 단순한 값과 다른 객체를 참조하는 링크로 구분할 수 있다.

객체의 자율성

• 객체는 다른 객체의 상태에 직접적으로 접근하고, 변경할 수 없음 → 자기 자신만이 자신의 상태를 책임짐 → 다른 객체가 특정 객체에 링크를 통해 메시지를 보낼 수는 있음 → 하지만, 그 메시지를 통해 특정 행동을 할지 말지는 스스로가 결정 → 객체는 스스로의 행동에 의해서만 상태가 변경됨을 보장하여 자율성을 유지

행동

상태와 행동

• 객체의 상태를 변경하는 것은 객체의 자발적인 행동 뿐 → 이렇게 객체의 상태를 변경하는 행동은 부수 효과를 갖고 있다고 함
• 객체의 행동은 객체의 상태를 변경시키지만, 객체의 행동에 대한 결과는 객체의 상태에 의존적

- 객체의 행동은 상태에 영향을 받음
- 객체의 행동은 상태를 변경시킴

협력과 행동

• 객체와 객체가 협력하는 유일한 방법은 다른 객체에게 요청을 보내는 것 → 요청을 받은 객체는 이를 수행하기 위해 특정 행동을 함 → 행동이 객체들끼리 협력할 수 있는 유일한 수단
• 객체의 협력 과정에서 스스로의 상태 뿐 아니라, 다른 객체의 상태 변경을 유발할 수도 있음 → 앨리스가 음료를 마셔서 자신의 키도 줄어들지만, 음료의 양도 줄어듦

객체의 행동으로 인해 발생하는 결과의 두 관점
- 객체 자기 자신의 상태 변경
- 행동에 협력하는 다른 객체에게 메시지 전송

이 책에서 객체의 행동 정의

행동이란 외부의 요청 또는 수신된 메시지에 응답하기 위해 동작하고 반응하는 활동이다. 행동의 결과로 객체는 자신의 상태를 변경하거나 다른 객체에게 메시지를 전달할 수 있다. 객체는 행동을 통해 다른 객체와의 협력에 참여하므로 행동은 외부에 가시적이어야 한다.

상태 캡슐화

• 앨리스가 음료를 마심 → 앨리스.drinkBeverage() → 음료에게 drunken(quantity) 라는 메시지가 전달됨 → 두 행동 모두, 송신자는 수신자의 상태에 대해 변경이 있는지 없는지 모름 → 캡슐화 → 객체는 캡슐 안에 상태를 감추어 외부에 노출하지 않음 → 외부에 노출되는 것은 행동 뿐, 외부에서 접근할 수 있는 방법도 행동 뿐
• 객체의 행동을 유발하는 것은 외부로부터의 메시지, 하지만 상태를 변경할지 말지는 객체 스스로가 결정 → 외부에서는 메시지 수신자의 상태가 변경되는지 아닌지 알지 못함 → 메시지 송신자는 수신자에게 어떤 간섭도 가하지 못함
• 캡슐화를 통해, 객체의 자율성을 높이고, 협력을 단순하고 유연하게 만듦

식별자

• 객체가 식별자를 갖는다 = 객체를 서로 구별할 수 있는 특정한 프로퍼티가 객체 안에 존재함 → 모든 객체는 식별자를 가지며, 이 식별자로 객체들을 구별할 수 있음
• 단순한 값은 식별자를 갖지 않음 → 1이라는 숫자가 둘 있을 때, 두 개를 굳이 식별하지 않으려고 하는 것과 비슷한 맥락
• 값(value)은 변하지 않는 양을 모델링함 → 값은 상태가 바뀌지 않기 때문에, 불변 상태를 가진다고 할 수 있음 → 값은 상태가 변하지 않기 때문에, 상태를 비교해서 동일한지 판단할 수 있음 → 이런 성질을 동등성이라고 함
• 객체는 시간에 따라 상태의 변동이 있을 수 있음 → 객체는 상태가 바뀌기 때문에, 가변 상태를 가진다고 할 수 있음 → 타입이 같은 두 객체의 상태가 모두 같더라도, 두 객체는 다른 객체로 판단함 → 객체는 상태와 무관하게, 식별자로 동일한 객체인지 아닌지 판단 → 이런 성질을 동일성이라 함
• 우리는 단순 숫자 1, 1 두 가지를 동일한 값이라고 생각하는 것 → 동등성 맥락 키가 180cm인 움파, 룸파 두 명을 키는 같더라도 다른 사람이라 생각하는 것 → 동일성 맥락

식별자란 어떤 객체와 구분하는 데 사용하는 객체의 프로퍼티이다. 값은 식별자를 가지지 않기 때문에 상태를 이용한 동등성 검사를 통해 두 인스턴스를 비교해야 한다. 객체는 상태가 변경될 수 있기 때문에 식별자를 이용한 동일성 검사를 통해 비교한다.

💡 객체의 특성

- 객체는 상태를 가지며 상태는 변경 가능하다.
- 객체의 상태를 변경시키는 것은 객체의 행동이다.
- 행동의 결과는 상태에 의존적이며 상태를 이용해 서술할 수 있다.
- 행동의 순서가 실행 결과에 영향을 미친다.
- 객체는 어떤 상태에 있더라도 유일하게 식별 가능하다.

기계로서의 객체

• 쿼리: 객체의 상태를 조회하는 작업
• 명령: 객체의 상태를 변경하는 작업

기계로서의 객체

• 기계는 뜯어보지 않는 한, 내부에 있는 요소들을 확인할 수 없음 → 객체를 이런 기계에 비유해서 생각
• 원형 버튼을 통해서 기계의 상태를 조회할 수 있음 → 쿼리
• 사각형 버튼을 통해서 기계의 상태를 변경할 수 있음 → 명령
• 객체에 접근할 수 있는 방법은 객체가 제공하는 동작 뿐이라는 것을 보여줌
• 두 개의 동일하게 동작하는 기계가 있다고 해도, 다른 기계로 인지 → 식별자를 설명할 수 있음
• 두 개의 기계가 ‘링크’되어 있어야 서로 메시지를 보내며 협력할 수 있음 → 객체 간의 협력 관계도 설명 가능

행동이 상태를 결정한다

• 객체지향의 입문자는 상태를 중심으로 객체를 바라봄

• 하지만, 상태를 먼저 결정하고, 행동을 나중에 결정하는 것은 설계에 나쁜 영향을 끼침

  • 상태를 먼저 결정할 경우 캡슐화에 저해됨
  • 객체를 협력자가 아닌 고립된 섬으로 만듬 → 객체가 필요한 이유는 애플리게이션 문맥 내에서 다른 객체와 협력하기 위함
  • 객체의 재사용성이 저하됨 → 상태에 초점을 맞추게 된다면 다양한 협력에 참여하기 어려워짐

• 협력에 참여하는 객체를 잘 만들기 위해서는 행동에 초점을 맞춰야 함

• 객체지향 설계는 애플리케이션에 필요한 협력을 먼저 생각 → 협력에 참여하는 데에 필요한 행동을 생각 → 행동을 수행할 객체를 선택 → 행동에 필요한 정보가 무엇인지 고려하여 상태를 결정

• 협력 안에서 객체의 행동은 객체의 책임을 의미함 → 객체가 어떤 책임이 필요한지부터 생각해야 함 → 책임-주도 설계 ( Responsibility-Driven Design, RDD )

객체지향의 사실과 오해

서론

“객체지향 소프트웨어는 실세계의 투영이며, 객체란 현실 세계에 존재하는 사물에 대한 추상화이다.”

하지만, 막상 찾아보면, 애플리케이션을 개발하며 실세계에 직접적으로 대응되는 사물을 발견하긴 힘들다. 즉, 소프트웨어 방화벽과, 실세계의 방화벽의 의미적 거리만큼, 소프트웨어와 실세계 사이에는 어느정도의 의미적 저리가 존재한다

하지만, 실세계의 모방이라는 객체지향의 개념은 실무적인 관점에서는 부적합하지만, 객체지향의 기본 사상을 이해하고 학습하기에는 효과적이다

협력하는 사람들

손님

• 커피를 마시고 싶어서 커피를 캐시어에게 주문함

캐시어

• 직장인에게 받은 커피 주문을 바리스타에게 전달함

바리스타

• 캐시어에게 받은 커피를 자기 나름대로의 방법으로 제작함

‘커피 주문’이라는 협력에 참여하는 손님, 캐시어, 바리스타는 주문된 커피가 손님에게 정확히 전달될 수 있도록 맡은 바 역할과 책임을 다하고 있음

이 역할, 책임, 협력이 객체지향의 핵심적인 3가지 요소

요청과 응답으로 구성된 협력

사람들은 스스로 해결하지 못하는 문제를 마주치면 이를 해결할 수 있는 사람에게 도움을 요청(request)한다

• 손님 → 캐시어 : 커피를 주문
• 캐시어 → 바리스타 : 커피를 제조하라

요청을 받은 사람은 주어진 책임을 다해 필요한 지식이나 서비스를 제공, 즉, 응답(response)한다

• 바리스타 → 캐시어 : 커피 완성
• 캐시어 → 손님 : 커피 완성

역할과 책임

사람들은 다른 사람과 협력하는 과정에서 특정한 역할을 부여받음

• 손님 : 커피를 주문하는 역할
• 캐시어 : 손님으로부터 커피를 주문받아야 함
• 바리스타 : 주문된 커피를 제조해야 할 책임이 있음

즉, 역할에는 책임이 내포되어 있음

사람들이 협력을 위해 특정한 역할을 맡고 적합한 책임을 수행한다는 사실은 몇 가지 중요한 개념을 제시

• 여러 사람이 동일한 역할을 수행할 수 있다 (캐시어가 일을 그만둔다면, 다른 캐시어를 고용하면 됨)
• 역할은 대체 가능성을 의미한다 (손님 입장에서 커피를 받기 위해 어떤 캐시어에게 주문하든 상관 없음)
• 책임을 수행하는 방법은 자율적으로 선택할 수 있다 (바리스타가 커피를 핸드드립으로 내릴지, 커피머신으로 내릴지는 자율적으로 선택 가능)
• 한 사람이 동시에 여러 역할을 수행할 수 있다 (1인 카페와 같은 경우, 캐시어가 바리스타의 역할을 함께 수행할 수 있음)

역할, 책임, 협력

기능을 구현하기 위해 협력하는 객체들

커피를 주문하고 제작해서 손님에게 전달하는 과정을 객체지향으로 돌려보자면,

사람 = 객체

요청 = 메시지

처리하는 방법 = 메서드

역할과 책임을 수행하며 협력하는 객체들

아리스토텔레스 왈 … “인간은 사회적 동물이다”

→ 하나의 목표를 이루기 위해 사람들이 협력한다 → 하나의 목표에는 더 작은 책임으로 분할된다 → 각 책임은 책임을 수행할 수 있는 적절한 역할을 가진 사람에 의해 수행된다 → 협력에 참여하는 개인은 책임을 수행하기 위해 다른 사람에게 도움을 요청하기도 한다 → 이런 연쇄적인 요청과 응답으로 구성되는 협력 관계가 완성된다

→ 하나의 어플리케이션을 위해 여러 객체가 협력한다 → 하나의 어플리케이션은 더 작은 책임으로 분할된다 → 각 책임은 책임을 수행할 수 있는 적절한 역할을 가진 객체에 의해 수행된다 → 협력에 참여하는 객체는 책임을 수행하기 위해 다른 객체에 도움을 요청하기도 한다 → 이런 연쇄적인 요청과 응답으로 구성되는 협력 관계가 완성된다

즉, 객체지향 설계는 적절한 객체에게 적절한 책임을 할당하는 것에서 시작되고, 이 책임은 객체지향 설계의 품질을 결정하는 가장 중요한 요소

따라서, 얼마나 적절한 책임을 선택하느냐가 어플리케이션의 아름다움을 결정

‘역할’은 관련성 높은 ‘책임’의 집합 객체의 ‘역할’은 다음과 같은 특징을 지님

• 여러 객체가 동일한 역할을 수행할 수 있다
• 역할은 대체 가능성을 의미한다
• 각 객체는 책임을 수행하는 방법을 자율적으로 선택할 수 있다
• 하나의 객체가 동시에 여러 역할을 수행할 수 있다

<협력하는 사람들>에서와 동일한 내용인걸로 보아 객체지향을 이해하기 위해, 실세계의 모방은 아주 뛰어난 방법 !

협력 속에 사는 객체

객체지향의 윤곽은 역할, 책임, 협력이지만, 이 협력에 참여하는 주체는 객체

어플리케이션의 핵심을 차지하는 객체가 가져야 할 두 가지 덕목

• 협력적이어야 함 → 다른 객체의 요청에 응답할지 말지, 응답한다면, 어떤 방식으로 응답할지, 객체 스스로 결정
• 자율적이어야 함 → ‘자기 스스로의 원칙에 따라 어떤 일을 하거나 자기 스스로를 통제하여 절제하는 것’

객체지향 설계의 묘미는 위 두 가지 덕목을 지키는 객체들의 공동체를 설계하는 데에 있음

상태와 행동을 함께 지닌 자율적인 객체

객체는 상태 와 행동 을 함께 지닌 실체라고 정의함

즉, 객체가 협력에 참여하기 위해 어떤 행동을 한다면, 그 행동을 하는 데 필요한 상태도 함께 지니고 있어야 함

객체가 협력에 참여하는 과정에서 스스로 판단하고 결정하는 자율적인 존재이기 위해

객체의 자율성은 객체의 외부와 내부를 명확하게 구분하는 데에서 결정됨

• 객체의 내부는 스스로 관리하고 외부에서 간섭할 수 없도록 차단해야 함
• 객체의 외부에서는 접근이 허락된 수단을 통해서만 의사소통 해야 함

즉, 객체는 다른 객체가 ‘무엇’을 수행하는지는 알 수 있지만, ‘어떻게’ 수행하는지는 알 수 없어야 함

협력과 메시지

현실세계에서는 사람들 간의 의사소통 방식이 다양함 하지만, 객체지향에서 객체들 간의 유일한 의사소통 방법은 메시지

즉, 객체들은 메시지를 송신, 수신하며 협력해 나가는 존재들

• 송신자 : 메시지를 전송하는 객체
• 수신자 : 메시지를 수신하는 객체

메서드와 자율성

객체는 다른 객체에게 요청하기 위해 메시지를 전송 수신자 객체는 처리 여부에 대해 판단한 후, 자신만의 방법으로 자율적으로 처리

이 때 처리하는 방법을 메서드 라고 함

그리고, 메시지와, 메시지의 요청을 처리하기 위한 메서드를 분리하는 것이 객체의 자율성을 높이는 핵심 메커니즘

객체지향의 본질

불완전하고 부정확하긴 하지만, 나름의 객체지향의 개념을 포괄하는 내용들

• 객체지향이란 시스템을 상호작용하는 자율적인 객체들의 공통체로 바라보고, 객체를 이용해 시스템을 분할하는 방법이다
• 자율적인 객체란 상태와 행위를 함께 지니며 스스로 자기 자신을 책임지는 객체를 의미한다
• 객체는 시스템의 행위를 구현하기 위해 다른 객체와 협력하고, 각 객체는 협력 내에서 정해진 역할을 수행하며 역할은 관련된 책임의 집합이다
• 객체는 다른 객체와 협력하기 위해 메시지를 전송하고, 메시지를 수신한 객체는 메시지를 처리하는 데 적합한 메서드를 자율적으로 선택한다

객체를 지향하라

객체지향에서 핵심은 ‘클래스’가 아니라, 적절한 책임을 수행한느 역할 간의 유연하고 견고한 협력 관계를 구축하는 것이다

객체지향의 사실과 오해

Class Diagram의 구성

Class Diagram에는 다양한 요소들이 있음

• class
• protocol
• properties
• methods
• relationships

상자는 Class를 의미함

open arrowhead는 상속을 의미

inherits from 으로 읽기보다, is a 로 읽기

Sheep Dog is a Dog

Property 를 의미할 때에는 plain arrowhead 사용

has a 로 읽으면 됨

Farmer has a Dog

Class Diagram에서는 class가 복수이더라도, 항상 단수로 작성해야 함

Farmer 가 여러 마리의 Dog를 has a 하고 있는데도, Dogs라고 쓰지 않고, Dog라고 작성

Protocol은 위에 <<protocol>> 로 작성

Open arrowhead에 dashed line 이면, 프로토콜을 따른다는 의미

implements 혹은 conforms to 라고 읽음

Farmer conforms to PetOwning

Plain arrowhead에 dashed line 사용해 의존성을 표시함

Delegate를 이처럼 표시 가능

dashed line 으로 여러가지를 표현할 수 있음

• weak property
• delegate
• 프로퍼티로 저장되지는 않지만, method에 전달된 객체
• 약한 연결이나 callback

프로퍼티나 메소드도 Class diagram으로 표현 가능

Key Points

• Class diagram은 클래스와 프로토콜의 관계와, 이들이 갖는 프로퍼티, 메소드를 시각적으로 나타냄
• Class diagram은 Object 사이에서의 관계도도 나타냄
• 상자는 프로토콜을 나타낼 수도 있고, 그러기 위해서는 <<protocol>> 로 표기해둔다

설계와 아키텍쳐란 ?

• 결론은 아키텍쳐와 설계는 아무 차이가 없음

  • 아키텍쳐 는 저수준의 세부사항과는 분리된 고수준의 무언가를 가리킬 때 사용 e.g. 집의 형태, 외관, 입면도, 공간, 방의 배치 등
  • 설계는 저수준의 구조 또는 결정사항 등을 의미할 때 e.g. 콘센트, 전등 스위치, 전등의 위치 등

• Software Architecture 의 목표

  • 필요한 시스템을 만들고 유지보수하는 데 투입되는 비용을 최소화

• 토끼와 거북이’에서 토끼는 자신의 능력을 과신하고 잠을 자버림

  • 이와 유사하게, 개발자도 자신의 능력을 믿고 나중에 코드를 고친다든, 유지보수보다 기능 출시가 우선이라는 등의 과신이 있는데, 이런 상태로는 엉망진창인, 유지보수가 전혀 되지 않는, 생산성이 떨어지는 코드가 되버림
  • 애초부터 이런 마음가짐을 고치지 않으면 재설계한다 하더라도 같은 실수를 반복하고, 스스로에 대한 과신을 버린 후, 올바른 아키텍쳐를 적용해야지 생산성이 높은, 유지보수 가능한 코드를 작성할 수 있다.

두 가지 가치에 대한 이야기

• 소프트웨어 시스템은 서로 다른 두 가지 가치를 제공함 → 행위(behavior)와 구조(structure)

• 행위

  • 기계의 수익 창출 / 비용의 절약

• 아키텍쳐

  • Soft(부드러운) ware(제품) 이라는 뜻에서 알 수 있듯, 기계의 행위를 쉽게 변경할 수 있음 → 즉, 소프트웨어는 반드시 부드러워야 함 / 변경하기 쉬워야 함
  • 변경에 드는 어려움은 변경의 범위에만 비례해야 하고, 변경의 형태와는 관련이 없어야 함

• 아이젠하워 매트릭스

| 중요함 & 긴급함 | 중요함 & 긴급하지 않음 |
| --- | --- |
| 중요하지 않음 & 긴급함 | 중요하지 않음 & 긴급하지 않음 |

`행위` 는 긴급하지만 중요하지 않고
`아키텍쳐` 는 긴급하지 않지만 중요함

해당 분류에 대한 우선순위는 아래와 같음

1. 긴급하고 중요함
2. 긴급하지는 않지만 중요한
3. 긴급하지만 중요하지 않은
4. 긴급하지도 중요하지도 않은

하지만, 때때로 3.을 최우선순위로 격상시키는 경우가 발생 → 이런 때에 중요도가 높은 아키텍쳐가 무시되고 중요도가 낮은 기능을 선택하게 됨

한 줄 요약

High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions.

상위 모듈은 하위 모듈에 의존에서는 안되고, 상위, 하위 모듈 모두 ‘추상’을 의존해야 한다 ’추상’은 ‘디테일’을 의존하면 안되고, ‘디테일’은 ‘추상’에 의존해야 함

좋지 않은 디자인

‘좋은’ 디자인, ‘좋지 않은’ 디자인의 기준은 없지만, ’좋지 않은’ 디자인이 갖는 특징들이 있음

Rigidity

변경을 주기 어려움, 한 곳을 바꾸면 다른 부분을 망가트림

• OCP를 지키지 않았을 때 어떤 부분에 확장이 필요할 때, 다른 부분도 변경해야 함
• 어떤 구조가 ‘추상’이 아닌 다른 구조에 의존할 때

Fragility

한 곳에서 변경을 주면 다른 부분도 변경해야 함

• OCP가 지켜지지 않았을 때
• 어떤 구조가 ‘추상’이 아닌 다른 구조에 의존할 때

Immobility or Coupling

여기저기 연결되어있기 때문에 재사용이 어려움

• 어떤 구조가 ‘추상’이 아닌 다른 구조에 의존할 때

이런 이유들 때문에, DIP가 좋은 디자인에 직접적으로 영향을 미침

다른 SOLID와의 관계

OCP와 LSP에서의 해결책은 모두 Abstraction 즉, DIP를 사용했을 때 OCP와 LSP를 지킬 수 있다

예시

struct Product {
    let name: String
    let cost: Int
    let image: UIImage
}

final class Network {
    private let urlSession = URLSession(configuration: .default)

    func getProducts(for userId: String, completion: @escaping ([Product]) -> Void) {
        guard let url = URL(string: "baseURL/products/user/\(userId)") else {
            completion([])
            return
        }
        var request = URLRequest(url: url)
        request.httpMethod = "GET"

        urlSession.dataTask(with: request) { (data, response, error) in
            DispatchQueue.main.async {
                completion([Product(name: "Just an example", cost: 1000, image: UIImage())])
            }
        }
    }
}

final class ExampleScreenViewController: UIViewController {
    private let network: Network
    private var products: [Product]
    private let userId: String = “user-id"

    required init?(coder: NSCoder) {
        fatalError()
    }

    init(network: Network, products: [Product]) {
        self.network = network
        self.products = products
        super.init(nibName: nil, bundle: nil)
    }

    override func loadView() {
        view = UIView()
    }

    override func viewDidLoad() {
        super.viewDidLoad()
        getProducts()
    }

    private func getProducts() {
        network.getProducts(for: userId) { [weak self] products in
            self?.products = products
        }
    }
}

DIP를 따르지 않았을 때 생기는 문제

Rigidity & Fragility

어떤 이유에서든 Network를 바꿔야 한다면, ExampleViewController에 있는 Network도 변경해야 함 이런 의도치 않은 변경으로 인해, ExampleViewController는 rebuild & retest가 필요하게 됨

**Immobility & Coupling**

다른 곳에서 ExampleViewController을 다시 사용해야 할 때, 동일한 것을 가져다 쓴다면, Network도 함께 가져다가 사용해야하고, 이 Network가 굉장히 복잡한 구조라면 동일하게 가져다 사용하는게 비효율적임

차라리 동일한 ExampleViewController를 가져다 쓰는 것 보다 새로운 ViewController를 만드는게 더 좋을수도 ..!

DIP를 따르게 된다면

상위, 하위 계층 모두 ‘추상’을 의존하게 만들자

// Abstraction
protocol ProductProtocol {
    var name: String { get }
    var cost: Int { get }
    var image: UIImage { get }
}

// Abstraction
protocol NetworkProtocol {
    func getProducts(for userId: String, completion: @escaping ([ProductProtocol]) -> Void)
}

struct Product: ProductProtocol {
    let name: String
    let cost: Int
    let image: UIImage
}

final class Network: NetworkProtocol {
    private let urlSession = URLSession(configuration: .default)

    func getProducts(for userId: String, completion: @escaping ([ProductProtocol]) -> Void) {
        guard let url = URL(string: "baseURL/products/user/\(userId)") else {
            completion([])
            return
        }
        var request = URLRequest(url: url)
        request.httpMethod = "GET"

        urlSession.dataTask(with: request) { (data, response, error) in
            completion([Product(name: "Just an example", cost: 1000, image: UIImage())])
        }
    }
}

final class ExampleScreenViewController: UIViewController {
    private let network: NetworkProtocol // Abstraction dependency
    private var products: [ProductProtocol] // Abstraction dependency
    private let userId: String = "user-id"

    required init?(coder: NSCoder) {
        fatalError()
    }

    init(network: NetworkProtocol, products: [ProductProtocol]) { // Abstraction dependency
        self.network = network
        self.products = products
        super.init(nibName: nil, bundle: nil)
    }

    override func loadView() {
        view = UIView()
    }

    override func viewDidLoad() {
        super.viewDidLoad()
        getProducts()
    }

    private func getProducts() {
        network.getProducts(for: userId) { [weak self] products in
            self?.products = products
        }
    }
}

추상화의 또 다른 이점

예전 레거시를 새로운 레거시로 손쉽게 변경할 수 있음

• 현재 Network 프로토콜을 따르는 새로운 구초를 만들고 싶을 때, 프로토콜을 따르는 NewNetwork를 만들면 됨 !
• 테스트 코드를 작성하기 더 쉬워짐

[출처] Dependency Inversion Principle in Swift

Programs that references an object from a base class must be able to use an object of a derived class without behavior differences and without knowing about its existence.

Base와 Base를 상속받는 객체가 있을 때, 특정 프로그램에서 Base를 받아와 사용한다면, Base를 사용하든, 상속받은 객체를 사용하든, 차이점이 없어야 하고, 차이점이 보여서도 안된다.

예시1 - Unexpected Behaviors

class Rectangle {
    var width: Int
    var height: Int

    init(width: Int, height: Int) {
        self.width = width
        self.height = height
    }

    func area() -> Int {
        return width * height
    }
}

class Square: Rectangle {
    override var width: Int {
        didSet {
            super.height = width
        }
    }

    override var height: Int {
        didSet {
            super.width = height
        }
    }
}

func main() {
    let square = Square(width: 10, height: 10)

    let rectangle: Rectangle = square

    rectangle.height = 7
    rectangle.width = 5

    print(rectangle.area()) 
    // As a rectangle we should expect the area as 7 x 5 = 35, but we got 5 x 5 = 25
}

main()에서 Rectangle 타입으로 두고 rectangle 변수에 Square 타입 값을 할당하면 최종적으로 print 되는 값은 25가 됨

이 상황에서는, Square를 Rectangle 타입에 할당했지만, rectangle.height = 7 과 같은 코드는 Square에서 동작하는 것과 동일하게 동작

즉, Rectangle 타입으로 적어뒀고, 그렇게 알고 있는데, Square로 동작한다는 점에서 LSP를 위반함

LSP를 따르지 않았을 때 생기는 문제

추상화를 하기 위해 보통 Polymorphism(다형성)에 도움을 받음 (e.g. 마켓 앱에서 살 수 있는 모든 제품을 API로 받아올 때 다양한 아이템들을 추상화해서 받기)

위 예시에서 rectangle 이라는 변수가 어떤 타입이 될 수 있는지 모름 정사각형인지, 직사각형인지 등등 …

그렇기 때문에 우리는 rectangle 처럼 동작할 것이라고 예상할 수 있음 하지만, 위 예시에서 실상은 rectangle 로 동작하지 않고, square 로 동작함

LSP를 따르게 된다면

protocol Geometrics {
    func area() -> Int
}

class Rectangle: Geometrics {
    var width: Int
    var height: Int
    init(width: Int, height: Int) {
        self.width = width
        self.height = height
    }

    func area() -> Int {
        return width * height
    }
}

class Square: Geometrics {
    var edge: Int
    init(edge: Int) {
        self.edge = edge
    }

    func area() -> Int {
        return edge * edge
    }
}

func main() {
    let rectangle: Geometrics = Rectangle(width: 10, height: 10)
    print(rectangle.area())

    let rectangle2: Geometrics = Square(edge: 5)
    print(rectangle2.area())
}

만약 상속 받으면서 내부 내용물을 정할 수 있다면, 손쉽게 따를 수 있을 것임 그래서 Protocol을 사용 !

예시2 - LSP & OCP

class Shape {
    func doSomething() {
        // do something relate to shape that is irrelevant to this example, actually
    }
}

class Square: Shape {
    func drawSquare() {
        // draw the square
    }
}

class Circle: Shape {
    func drawCircle() {
        // draw the circle
    }
}

func draw(shape: Shape) {
    if let square = shape as? Square {
        square.drawSquare()
    } else if let circle = shape as? Circle {
        circle.drawCircle()
    }
}

코드가 이런 형식으로 되어 있으면, draw(shape:) 메소드가 실행될 때, Square 타입이 들어오거나, Circle 타입이 들어오거나, Shape 타입이 들어올 때 다른 방식으로 실행됨

추가로, 이 예시는 OCP를 위반하기도 하는데, Triangle이라는 Shape을 상속받는 새로운 타입을 만들 때, draw(shape:) 메소드에 Triangle인 경우에도 추가해야 하기 때문

LSP를 따르게 된다면

protocol Shape {
    func draw()
}

class Square: Shape {
    func draw() {
        // draw the square
    }
}

class Circle: Shape {
    func draw() {
        // draw the circle
    }
}

func draw(shape: Shape) {
    shape.draw()
}

프로토콜로 Shape 타입을 draw() 메소드와 함께 만들어 둔다면, 각 타입을 만들 때, 타입별로 필요한 메소드를 내부에 적어둘 수 있고, draw(shape:)에서도 어떤 Shape이건 동일하게 동작함을 볼 수 있음

추가적으로, Triangle 타입을 추가한다 하더라도, draw(shape:)에 변화를 줄 필요가 없기 때문에, OCP를 만족한다고도 볼 수 있음

[출처] Liskov Substitution Principle in Swift

The Open Closed Principle says that “Software Entities (classes, modules, functions, etc) should be open for extension, but closed for modification”.

OCP에 따르면, Software Entities 는 확장할 수 있어야 하지만, 변경할 수는 없어야 한다.

예시1 - Abstraction

class Person {
    private let name: String
    private let age: Int

    init(name: String, age: Int) {
        self.name = name
        self.age = age
    }
}

class House {
    private var residents: [Person]

    init(residents: [Person]) {
        self.residents = residents
    }

    func add(_ resident: Person) {
        residents.append(resident)
    }
}

protocol Resident {}

class Person: Resident {
        // ...
}

class House {
    private var residents: [Resident]

    init(residents: [Resident]) {
        self.residents = residents
    }

    func add(_ resident: Resident) {
        residents.append(resident)
    }
}

OCP를 따르지 않을 때 생기는 문제

왼쪽 예시를 보면, Person이라는 타입과는 다른 타입이 필요해서 NewPerson 타입을 만든다면, House에서는 내부에 있는 Person 타입들을 모두 NewPerson 타입으로 바꾸어야 함

즉, NewPerson으로 확장하려 하는데, House 에서는 변동이 생기기 때문에 OCP를 만족하지 못한다

만약, 그냥 Person 타입의 내부를 바꾼다면, 이 또한 Person 타입에 변동이 생기는 것이기 때문에 OCP를 만족하지 못한다

따라서, OCP를 따르지 않으면, 한 가지를 확장하려 할 때, 변동을 줘야 하는 요소가 생기게 된다

OCP를 따르게 된다면

House 타입은 Resident라는 프로토콜을 의존하고 있고, Person도 Resident라는 프로토콜을 받아와 사용하기 때문에, NewPerson이라는 타입이 Resident를 따르도록 형성된다면, House에는 아무 변화를 주지 않아도 된다

예시2 - Enum

enum DeeplinkType {
    case home
    case profile
}

protocol Deeplink {
    var type: DeeplinkType { get }
}

class HomeDeeplink: Deeplink {
    let type: DeeplinkType = .home
    func executeHome() {
        // Presents the main screen
    }
}

class ProfileDeeplink: Deeplink {
    let type: DeeplinkType = .profile
    func executeProfile() {
        // Presents the profile screen
    }
}

class Router {
    func execute(_ deeplink: Deeplink) {
        switch deeplink.type {
        case .home:
            (deeplink as? HomeDeeplink)?.executeHome()
        case .profile:
            (deeplink as? ProfileDeeplink)?.executeProfile()
        }
    }
}

위 예시는 OCP를 따르지 않음

DeeplinkType에 새로운 case를 추가하게 되면 Router의 execute()에도 새로운 case를 넣어줘야 하기 때문 !

OCP를 따르지 않을 때 생기는 문제

나는 그저 DeeplinkType를 확장했을 뿐인데, Router 클래스에도 변화를 줘야한다고 ..?!

많은 경우에 enum의 사용은 이렇게 다른 곳에서의 변동을 발생시킨다 ㅠㅠ 간단하게 case만 추가해주면 되는 때도 있겠지만, 완전 복잡한 로직이 들어가면 사고 …

OCP를 따르게 된다면

protocol Deeplink {
    func execute()
}

class HomeDeeplink: Deeplink {
    func execute() {
        // Presents the main screen
    }
}

class ProfileDeeplink: Deeplink {
    func execute() {
        // Presents the Profile screen
    }
}

class Router {
    func execute(_ deeplink: Deeplink) {
        deeplink.execute()
    }
}

이런 모습으로 바뀌게 됨 !

class SettingsDeeplink: Deeplink {
    func execute() {
        // Present the Settings Screen
    }
}

새로운 Deeplink 타입을 추가하게 되어도, Router에는 아무 변동이 생기지 않음

[출처] Open Closed Principle in Swift