객체지향 (역할, 책임, 협력)
조영호님의 특강👍👏🙇♀️
객체지향에서는 역할, 책임, 협력이 핵심이다.
가장 중요한 것은 책임이다.
책임-주도 설계
Responsibility-Driven Design
- 런타임시 움직임이 있는것을 책임이라고 본다.
1.애플리케이션의 요구사항을 파악한다.
2.요구사항을 시스템의 책임으로 변환한다.
3.시스템의 책임을 객체의 책임으로 변환한다.
4.책임을 담당할 수 있는 적절한 객체를 선택한다.
-> 클래스나 객체를 먼저 선택하는게 아니라 책임을 먼저 선택하고, 책임에 적합한 객체를 선택해야한다!
5.객체의 책임 일부를 수행하기 위해 외부의 도움이 필요하다면 다른 객체에게 도움을 요청한다.
6.책임을 담당할 수 있는 적절한 객체를 선택한다.
메소드는 송신하는 쪽의 입장에서 이름을 짓는 것이 적합하다. → "수신하는 쪽에서 무엇을 한다" 가 아닌, "송신하는 쪽에서 무엇을 원한다" 라고 짓는게 적합하다.
What(책임)을 결정한 다음에 → Who(어떤 객체가 수행할지)를 결정한다.
Q. 클래스가 많은쪽이 좋다는 말은 DB설계할때도 테이블을 최대한 많이 쪼개는게 좋다는 말인가? (by Kyu)
No. 테이블 설계와 객체 설계 패러다임은 완전 다르다.
테이블은 데이터의 중복을 제거하면서 관련된 데이터들을 같이 모으는게 좋다.
테이블은 데이터 관점이고 객체는 행동 관점(런타임에 어떤 행동을 수행할건지)이다.
테이블을 설계하는 정규화 원칙과 객체를 설계하는 책임 기반 설계 원칙의 연관성은 없다.
결합도와 의존성
결합도가 높고 의존성이 높으면 안 좋다고 이야기한다. 하지만 객체끼리 메시지를 주고받으면서 협력하기 때문에 결합도와 의존성은 불가피하다.
때문에 응집도를 높이고(SRP) 결합도를 낮추도록(DIP) 설계하는게 핵심이다.
Q. DI와 IoC?
Dependency Inversion : A가 B의 기능을 쓸 때 전통적인 Dependency의 방향은 A → B로 흐른다.
그런데 B가 인터페이스(혹은 추상클래스)이고 B 밑에 서브 클래스들이 있다고 하면, Dependency가 반대로 B의 서브클래스에서 A로 흐른다. 즉, 의존성을 역전시킨다.
Inversion of Control (제어 역전) : 헐리우드 원칙, 내가 클래스를 만드는데 내가 스프링의 어떤 코드를 호출을 하는게 아니라 스프링이 나의 코드를 호출한다. 호출하는 쪽이 제어권을 갖고 있다. 내가 코드를 호출하면 제어가 나한테 있는것이고, 내가 호출할 수 있는 제어권이 스프링과 같은 프레임워크에게 넘어가면 제어가 역전 되었다고 본다.
오늘 한일
- 오늘 조영호님의 특강을 들었다. 개발 공부를 하는데에 필독서 저자의 강의를 듣는게 신기하다고 생각했는데 너무 좋았다. 특히 DI와 IoC에 대한 내용은 검색해봐도 무슨 소리인가.. 싶었는데 아주 명쾌하게 설명해주셨다👏👏 대략 중요하다고 생각되는 내용들만 정리를 해보았다.
- 객체지향에서는 역할, 책임, 협력(이 중 책임이 제일 중요)이 핵심이고, What(책임)을 결정한 다음에 → Who(어떤 객체가 수행할지)를 결정한다.
- 메소드명 지을때 송신하는 쪽의 입장에서 이름을 짓는 것이 적합하다. → "수신하는 쪽에서 무엇을 한다" 가 아닌, "송신하는 쪽에서 무엇을 원한다" 라고 짓는게 적합하다. (이부분 기억하고 코딩해야지)
- 오늘 코테 스터디에서 6문제나 풀어서 너무 좋다.(마지막 문제는 Dong의 도움으로 해결할 수 있었지만) 컨디션이 오늘만 같으면 좋겠다.
- 코쿼 멤버들이랑 airbnb 프로젝트 이야기하다가 로치에게 DB에 대한 키워드를 얻었다. full 스캔, range 스캔, 부등호로 검색하면 full scan을 하고 between으로 검색하면 range 스캔을 한다. 이부분 더 찾아봐야겠다.
- DB 테이블 탐색 방식
Todo
- a4 한장으로 객체지향의 컨셉 자기말로 정리해서 내기 (숙제!)
숙제!ㅠㅠㅠㅠㅠ 저도 아직 못했는데 이젠 미룰 수 없게 되었네요ㅠㅠ 오늘 조영호님 세미나 정리해주셔서 감사합니당ㅎㅎㅎ