유스콘22
객체지향 : 변경을 캡슐화한 객체들이 메시지를 통해 협력하는 프로그래밍
- 메시지
- 객체들이 협력하기 위해 사용할 수 있는 유일한 의사소통 수단
- 수신자는 메시지를 처리할 책임을 다하기 위해, 메시지를 처리할 방법인 메소드를 선택한다
협력
- 무엇인가를 요청
- 메시지 전송이 유일한 커뮤니케이션 수단
책임
- 협력에서 수행하는 행동
ex) product 는 재고를 감소시키는 책임을 함
메시지
condition.isSatisfiedBy(screening);
수신자 오퍼레이션명 인자
- GRASP
책임할당을 위한 소프트웨어 패턴
책임을 수행하는데 필요한 정보를 갖고 잇는 객체에게 책임을 지게 한다
-> iNFORMATION EXPERT
-> 높은 응집도, 낮은 결합도
-> 유지 보수 쉬움
응집도 : 변경 발생 시 모듈 내부에서 발생하는 변경의 정도
- 높은 응집도 유지해라
- 복잡성 관리할 수 있는 수준으로 유지해라
- 결합도
- 다른 모듈에 대해 얼마나 많은 지식을 가졌는지 나타내는 척도
- 낮은 결합도를 유지해라
- 의존성 낮추고, 변화의 영향을 줄이고, 재사용성을 증가시킨다
** 오퍼레이션명
- 협력과 관련된 의도만을 포함하도록 메시지 형성
- 이름은 송신자 입장에서 정해야 함
- 내부에서 어떤 일을 하는지 알도록 정하면 안됨.
외부에서 객체에게 명령하듯이 메시지를 전송해야 한다
메시지 정리
- 직접적인 데이터 공유 X, 메시지로 객체의 자율성 보장
- 메시지 만들 때, 협력/책임/역할을 고려
- 캡슐화
- 변경될 수 잇는 어떤 것이라도 감추는 것!!!!
- 내부 구현 변경으로, 외부 객체가 영향받으면 캡슐화를 위반한 것
- 변화와 불안정성이 다른 요소에 나쁜 영향 미치지않도록 방지
- 데이터 캡슐화 => 데이터 은닉도 캡슐화의 일부긴 한데 이게 전부는 아님
- private 변수
- public 메소드로 변수 값 변경
- 메소드 캡슐화
-
객체 캡슐화 -> 컴포지션 (합성)
-> 컴파일 타임에만 고정 -
서브타입 캡슐화 -> 다형성
- overloading
- dynamic binding (동적바인딩)
-> 실행될 메소드를 런타임에 결정하는 방식
-> 변하는 것이 있다면 타입 분리하고, 변화하는 것을 각 타입의 책임으로 할당하여 변화에 유연하게 대처하자!
역할 : 교체할 수 있는 책임의 집합
기프트카드 + 포인트 -> 머니라는 역할 부여
3.상속
- DRY 원칙 : 코드 안에 중복 존재해서는 안된다
- 코드 재사용이 목적이면 안되고, 타입 계층을 구현하는 게 목표여야 함
-> - 상속은 클래스간의 결합도를 높임
- 추상화
- 추상적인 존재에 의존해야 결합도를 낮출 수 잇음
되면 한다