<객체지향의 사실과 오해>를 읽고 객체지향에 대해 배운 점을 사내 세미나로 진행했던 자료입니다.

1. 객체 지향이요?
그게....
개발팀 3분기 세미나
객체지향이란?
<객체지향의 사실과 오해>를 읽고
셀렉트스타 개발팀 이희찬

2. 이번 분기에 읽은 이 책의 내용을 기반으로 재구성한
내용입니다

3. 객체 지향이요?
그거 클래스
아닌가요?
객체지향 하면 (내가) 원래 떠올렸던
키워드들
- 클래스
- (클래스는 과자틀이다…)
- 클래스 상속

4. 어떤 학교의 프로그래밍 입문 수업
기대: 뭔가 객체랑 관련 프로그래밍 기법
설명해주나?
그냥 클래스를 어떻게 만들 수 있는지,
어떻게 이쁘게 정리할 수 있는지 알려줌
API나 Interface 패턴에 대해 알려줄줄 알았는데
GUI 한번 설명해주고 PPT가 끝남

5. 학교 탓 하는건 아니지만!
딱히 객체지향이 뭔지 제대로 배울 기회가 없어
객체지향에 대한 질문을 받아도 정확히 뭐라 설명하기 쉽지
않았다
요즘이야 좋은 책이 많지만 가끔 보면 객체지향 설계 책인데
클래스와 상속 관련 내용이 중심인 경우도 있음

6. *객체지향 세계는 실제 세계와는 다른 점이
많지만,
쉬운 설명을 위해 실제 세계 예시를
들어보겠습니다.
기획자
역할: 신기능을 기획하기
개발자
역할: 기능을 개발하기

7. 기획자
역할: 신기능을 기획하기
개발자
역할: 기능을 개발하기
이 기능 만들어주세요!
완성했다 / 실패했다

8. 기획자
역할: 신기능을 기획하기
개발자
역할: 기능을 개발하기
이 기능 만들어주세요!
완성했다 / 실패했다

9. 기획자
역할: 신기능을 기획하기
개발자
역할: 기능을 개발하기
객체의 특징 1. 객체는 상태와 행동으로
이루어져 있다

10. 기획자
역할: 신기능을 기획하기
개발자
역할: 기능을 개발하기
이 기능 만들어주세요!
완성했다 / 실패했다
객체의 특징 2. 객체는 서로 협력할 수 있다.

11. 기획자
역할: 신기능을 기획하기
개발자
역할: 기능을 개발하기
객체의 특징 3. 협력은 하되, 자신의 역할에만 집중한다
서로 내부 구조 모름. 공개된 메서드만 호출
가능
“requestPlans”만 있군..

12. 기획자 개발자
객체지향은 ‘단순한 클래스 잘 만들기’가 아니다
위 객체의 특징들을 어떻게 잘 살릴지 고민한 결과가
객체지향
1. 필요에 따라 적당한 상태와 행동을 구성하는 것
2. 객체 사이의 협력 관계를 구축하는 것
3. 각 객체가 가져야 할 역할과 책임을 적절히 부여하는 것
객체지향 설계의 핵심

13. 객체지향을
처음 본 나
근데 왜 이렇게 귀찮게
만들지? 그냥
전역에다가 대충 함수
만들어서 쓰면 되는거
아닌가...

14. 객체지향을
처음 본 나
근데 왜 이렇게 귀찮게
만들지? 그냥
전역에다가 대충 함수
만들어서 쓰면 되는거
아닌가...
그래서
전역에다가
마구잡이로
코드를
짜버린 나
플젝 사이즈 커지니까
뭐가 어디있는지도,
어디에 쓰이는지도
모르겠고… 다시
손대기도 부담스럽네;;
ㅅㄱ

15. 객체 & 객체지향을 이용하면 얻을 수 있는
이점은?!
역할, 책임, 협력으로 만들어진 지속가능한 코드 구조
수정하기 쉽고, 확장성 있고, 이해하기 쉬운….
아니 뭐… 어떻게?

16. 책임과 협력의 관계
개발자
무지성으로 코드짜기, 디버그하기, 테스트하기, 빌드하기 메서드를 제공한다면 기획자는...
어떤 협력이 필요한지 생각하지 않고, ‘개발자’라는 클래스를 구현한다면...
개발자가 할 수 있는 일..?
코드짜고, 테스트하고, 빌드하고…
이런 메서드를 클래스에 만들어두고 쓰게 하면
되겠지?

17. 책임과 협력의 관계
개발자
무지성으로 코드짜기, 디버그하기, 테스트하기, 빌드하기 메서드를 제공한다면 기획자는...
자신의 역할을 넘어 너무나 많은 것을 신경 써야 하는 기획자
협력 관계가 복잡해짐, 의존성 ON, God object ON
어떤 협력이 필요한지 생각하지 않고, ‘개발자’라는 클래스를 구현한다면...
개발자가 할 수 있는 일..?
코드짜고, 테스트하고, 빌드하고…
이런 메서드를 클래스에 만들어두고 쓰게 하면
되겠지?
기획자
내가 코드 짜라, 디버깅해라, 하나하나
다 말해줘야 하냐고~

18. 책임과 협력의 관계
기획자 개발자
명확한 책임이 깔끔한 협력을 만든다
너무 세세하지 않으면서, 너무 추상적이지도 않은 ‘적절한 책임’을 가지고
있어야 함

19. 책임과 협력의 관계
기획자 개발자
명확한 책임이 깔끔한 협력을 만든다
개발자는 ‘기획을 받아 원하는 것을 개발해내 전달하기’ 라는
책임을 가진다
기획자는 개발자의 해당 책임을 호출하고 기다리기만 하면 된다
= 기획자가 해야 하는 역할을 넘어서지 않아도 된다
협력 관계가 깔끔해진다

20. 협력은 어떻게 이루어질까
메시지를 전송하는 방법
(= 공개된 메서드를 호출하는 방식)
공개된…?
(“Developer는 이 메서드를 갖고 있구나?!” 라고 알 수
있는)

21. 추상화
?

22. 추상화와 타입
개발자
iOS 앱
개발
자
aOS
앱
개발자
Web
개발
자
서버
개발
자
공통적인 특징: develop()를 수행할 수 있음
‘개발자’ (Developer) 라는 타입으로 여러 개발자들을 추상화

23. 추상화와 타입
기획
자
iOS 앱
개발자
개발자
얘는 개발자구나...
그러면 일단 누구든 간에
개발은 할 수 있겠군...
개발자.develop()
개발자라는 타입이란걸 알고 있으면
기획자는 복잡하게 생각할 필요 없이
“아! 얘는 개발은 할 수 있겠군!”
이라고 판단, .develop() 메서드를 호출할 수 있다
=> 추상화를 통해 깔끔해진 협력 관계

24. 추상화와 타입
기획
자
iOS 앱
개발자
개발자
얘는 개발자구나...
그러면 일단 누구든 간에
개발은 할 수 있겠군...
개발자.develop()
기획자는 해당 대상이 ‘개발자’라는 타입인 것만 신경
씀
이게 사실은 안드로이드여도, 서버여도, 웹이어도
상관없음
‘개발자’라는 역할을 수행하는 그 어떤 객체든
들어와서 붙을 수 있음
=> 역할을 통해 객체의 대체가능성

25. 인터페이스

26. 인터페이스
Swift의 Protocol: JS, Kotlin의 interface와 같음
이 역할(타입)이 수행하기 적절한 책임을 넣어둔다

27. 인터페이스
Swift의 Protocol: JS, Kotlin의 interface와 같음
이 역할(타입)이 수행하기 적절한 책임을 넣어둔다
Developable에 부합하는 객체들은 부담없이
사용 가능

28. 책임을 수행하는 객체
메시지를 받은 객체는 그 메시지가 요구하는 결과를 내야 하는 책임이 있고,
그 책임을 다 하기 위해 자율적으로 메서드를 수행할 수 있다.
기획자
개발자
책임 부여
알아서 개발해서
결과물을 돌려주면
되겠군...

29. 자율적? 메서드 불러지면 수동적으로 움직이는건데 이게 왜 자율적이냐?
객체가 자유 의지를 가지고 있다는게 아니라…
어떤 결과를 내기 위해 내부에서 어떤 과정을 거칠지는 객체가 알아서 하라는 뜻

30. 캡슐화
기획
자
iOS 앱
개발자
개발자
Developable
개발자.develop() develop 해달래
내부에서 어떻게 작동하는지
모름
사실 알 필요도 없음
코드
짜기
테스트
하기
빌드하기
내부 메서드를 알아서 사용해
개발 책임을 수행
객체의 협력은 메시지로만, 그 이상의 간섭은 지양해야 함
내부(구현)와 외부(인터페이스)의 분리가 필요 -> 캡슐화
내부 로직 수정이 필요할 때도
외부에 나가는 결과값만 제대로 맞춰준다면
다른 객체에서는 수정된 부분을 신경 쓸 필요가 없어짐

31. 자율적인 책임이 중요한 이유
1. 협력을 단순하게 만드는데 도움을 줌
2. 캡슐화를 통해 외부와 내부를 확실히 분리하는데 도움을 줌
3. 내부 로직을 변경하더라도 외부, 다른 객체의 구현에 영향을 미치지 않도록 해줌
4. 코드를 읽을 때 객체의 역할을 쉽게 이해할 수 있게 해줌

32. 객체지향, 어떤 기법이 있을까
더 많긴 하지만, 두 가지만 살펴보자면...
1. 책임 주도 설계
2. 테스트 주도 개발

33. 책임 주도 설계, Responsibility Driven Design
● 시스템이 사용자에게 제공해야 하는 기능과 그 책임을 파악한다.
● 시스템의 책임을 더 작은 책임들로 분할한다.
● 분할된 책임을 잘 수행할 수 있을 적절한 역할(객체)를 찾아 책임을 할당한다.
● 객체가 책임을 수행하는 중에 다른 객체의 도움이 필요한 경우 이를 책임질 적절한 객체를
찾는다.
● 그 객체에도 새로운 책임을 할당함으로써 두 객체가 협력하게 한다.
단연 포인트는 책임의 분할과 할당이라고 생각한다

34. 테스트 주도 개발, Test Driven Development
처음엔 실패할 수 밖에 없는 테스트를 하나 만들어두고,
그걸 해결하기 위한 코드를 일단 짠 후,
리팩토링으로 정리하며 좋은 코드를 얻는 방식

35. 테스트 주도 개발, Test Driven Development
처음엔 실패할 수 밖에 없는 테스트를 하나 만들어두고,
그걸 해결하기 위한 코드를 일단 짠 후,
리팩토링으로 정리하며 좋은 코드를 얻는 방식
테스트는 단순 테스트가 아니라, 해당 객체가 어떤 책임을 해줄 것이라는 ‘기대’를 담고 있는 것

36. 결론: 왜 객체지향을 써야 하는가
읽기 좋고 이해하기 쉬운 코드 구조로 협업을 더 잘 하려고
적절하고 느슨한 객체 사이의 관계를 구축해 수정해도 부담 없는
코드를 만들려고
테스트를 좀 더 하기 좋게 하려고

37. 결론: 왜 객체지향을 써야 하는가
더 좋은 코드를 짜기 위해서
읽기 좋고 이해하기 쉬운 코드 구조로 협업을 더 잘 하려고
적절하고 느슨한 객체 사이의 관계를 구축해 수정해도 부담 없는
코드를 만들려고
테스트를 좀 더 하기 좋게 하려고

38. 감사합니다!
Reference
<객체지향의 사실과 오해> - 조영호