11. 기획자
역할: 신기능을 기획하기
개발자
역할: 기능을 개발하기
객체의 특징 3. 협력은 하되, 자신의 역할에만 집중한다
서로 내부 구조 모름. 공개된 메서드만 호출
가능
“requestPlans”만 있군..
12. 기획자 개발자
객체지향은 ‘단순한 클래스 잘 만들기’가 아니다
위 객체의 특징들을 어떻게 잘 살릴지 고민한 결과가
객체지향
1. 필요에 따라 적당한 상태와 행동을 구성하는 것
2. 객체 사이의 협력 관계를 구축하는 것
3. 각 객체가 가져야 할 역할과 책임을 적절히 부여하는 것
객체지향 설계의 핵심
13. 객체지향을
처음 본 나
근데 왜 이렇게 귀찮게
만들지? 그냥
전역에다가 대충 함수
만들어서 쓰면 되는거
아닌가...
14. 객체지향을
처음 본 나
근데 왜 이렇게 귀찮게
만들지? 그냥
전역에다가 대충 함수
만들어서 쓰면 되는거
아닌가...
그래서
전역에다가
마구잡이로
코드를
짜버린 나
플젝 사이즈 커지니까
뭐가 어디있는지도,
어디에 쓰이는지도
모르겠고… 다시
손대기도 부담스럽네;;
ㅅㄱ
15. 객체 & 객체지향을 이용하면 얻을 수 있는
이점은?!
역할, 책임, 협력으로 만들어진 지속가능한 코드 구조
수정하기 쉽고, 확장성 있고, 이해하기 쉬운….
아니 뭐… 어떻게?
16. 책임과 협력의 관계
개발자
무지성으로 코드짜기, 디버그하기, 테스트하기, 빌드하기 메서드를 제공한다면 기획자는...
어떤 협력이 필요한지 생각하지 않고, ‘개발자’라는 클래스를 구현한다면...
개발자가 할 수 있는 일..?
코드짜고, 테스트하고, 빌드하고…
이런 메서드를 클래스에 만들어두고 쓰게 하면
되겠지?
17. 책임과 협력의 관계
개발자
무지성으로 코드짜기, 디버그하기, 테스트하기, 빌드하기 메서드를 제공한다면 기획자는...
자신의 역할을 넘어 너무나 많은 것을 신경 써야 하는 기획자
협력 관계가 복잡해짐, 의존성 ON, God object ON
어떤 협력이 필요한지 생각하지 않고, ‘개발자’라는 클래스를 구현한다면...
개발자가 할 수 있는 일..?
코드짜고, 테스트하고, 빌드하고…
이런 메서드를 클래스에 만들어두고 쓰게 하면
되겠지?
기획자
내가 코드 짜라, 디버깅해라, 하나하나
다 말해줘야 하냐고~
18. 책임과 협력의 관계
기획자 개발자
명확한 책임이 깔끔한 협력을 만든다
너무 세세하지 않으면서, 너무 추상적이지도 않은 ‘적절한 책임’을 가지고
있어야 함
19. 책임과 협력의 관계
기획자 개발자
명확한 책임이 깔끔한 협력을 만든다
개발자는 ‘기획을 받아 원하는 것을 개발해내 전달하기’ 라는
책임을 가진다
기획자는 개발자의 해당 책임을 호출하고 기다리기만 하면 된다
= 기획자가 해야 하는 역할을 넘어서지 않아도 된다
협력 관계가 깔끔해진다
20. 협력은 어떻게 이루어질까
메시지를 전송하는 방법
(= 공개된 메서드를 호출하는 방식)
공개된…?
(“Developer는 이 메서드를 갖고 있구나?!” 라고 알 수
있는)
23. 추상화와 타입
기획
자
iOS 앱
개발자
개발자
얘는 개발자구나...
그러면 일단 누구든 간에
개발은 할 수 있겠군...
개발자.develop()
개발자라는 타입이란걸 알고 있으면
기획자는 복잡하게 생각할 필요 없이
“아! 얘는 개발은 할 수 있겠군!”
이라고 판단, .develop() 메서드를 호출할 수 있다
=> 추상화를 통해 깔끔해진 협력 관계
24. 추상화와 타입
기획
자
iOS 앱
개발자
개발자
얘는 개발자구나...
그러면 일단 누구든 간에
개발은 할 수 있겠군...
개발자.develop()
기획자는 해당 대상이 ‘개발자’라는 타입인 것만 신경
씀
이게 사실은 안드로이드여도, 서버여도, 웹이어도
상관없음
‘개발자’라는 역할을 수행하는 그 어떤 객체든
들어와서 붙을 수 있음
=> 역할을 통해 객체의 대체가능성
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. 결론: 왜 객체지향을 써야 하는가
더 좋은 코드를 짜기 위해서
읽기 좋고 이해하기 쉬운 코드 구조로 협업을 더 잘 하려고
적절하고 느슨한 객체 사이의 관계를 구축해 수정해도 부담 없는
코드를 만들려고
테스트를 좀 더 하기 좋게 하려고