1. Holub on Patterns 1. OO와 디자인 패턴 기초 다지기 접근메소드와 수정 메소드는 나쁘다 우 정권

2. 접근 메소드와 수정 메소드는 나쁘다? 왜?

3. 구현을 노출하지 않는 건 OO 시스템의 기본 중 기본!객체를 사용하는 코드의 변경 없이 구현을 바꿀 수 있다 구현 은닉을 하지 않는다면 다른 OO 기능을 사용하는 것이 큰 의미가 없다. 접근 메소드와 수정 메소드는 캡슐화 원칙을 위반한다!

4. get/set 메소드생성 현장

5. 접근 방법만 복잡할 뿐 아무런 이점이 없다! get set

6. 많은 경우 get/set 메소드는private 필드를 접근하는 부적절한 용도로만 사용된다. 해결하고자 하는 문제를 명확하게 파악하지 못했음을 의미.객체간의 관계를 세심하게 디자인 했다면 대부분의 get/set 이 불필요 추측에 의한 디자인은 필요치 않은 기능을 추가하는데 불필요한 시간을 낭비한다. 유연성을 위한 프로그래밍이 아닌 게으름일 뿐!

7. 그럼 어떡하나요 ?!

8. 위임 Delegation 작업을 수행하는데 필요한 정보를 요구하지 마라. 정보를 가진 객체에 위임 하라.

9. get/set 없는 삶 문제는 코딩이 아닌 디자인 CRC 카드 커닝험이 고안한 디자인 프로세스 교수 방법론 유스 케이스 : 어떤 유용한 결과를 내는,엔드유저가 수행하는 단일 작업

10. CRC 카드 각 사람이 CRC 카드를 가지고 객체를 표현 하며, 서로 이야기를 통해 유스케이스를 구성하는 액티비티를 수행한다.

11. CRC 프로세스 협업자끼리만 이야기를 나눌 수 있다. 협업자가 아닌 다른 사람과 이야기가 필요할 경우그 사람과 이야기 할 수 있는 협업자를 찾는다. 불가능 하다면 그 사람을 CRC 카드 협업자에 추가 한다. 어떤 작업을 수행할 사람이 없다면 새로운 CRC 를 추가하거나 기존 CRC 에 추가한다. 만약 CRC 의 책임이 너무 많다면 책임의 일부를 처리할 새로운 CRC 를 생성한다. 유의 사항 사용하는 단어와 프로세스 모두 구현이 아닌 문제의 도메인에 집중한다. 정보를 묻는 대신 필요한 정보를 가진 협업자에게 작업을 요청 한다. 약간의 데이터를 넘겨주는 것은 괜찮지만, 데이터 흐름은 최소화 한다.

12. CRC 결과물 대화를 통해 해결한 문제를 기록하며 이는 곧 프로그램의 동적 모델이 된다. CRC 카드 결과물은 프로그램의 정적 모델이 된다.

13. OO 디자인 RUP, Crystal, XP 등의 디자인 프로세스가 있다. 중요한 건 OO 시스템의핵심은 객체들 간의 대화 나눔 이라는 것(메시징)! 메시징 시스템을 세심히 디자인 하였다면 get/set 메소드를 없애고 유연하게 만들 수 있다!

14. 그럼 get/set 은 어디다 쓰나요 다른 객체를 돌보는 경우컬렉션 범용 라이브러리자바빈즈, 스트럿츠 절차지향 경계 레이어DB,UI 고도의 범용성과 유연성이 필요할 경우 필연적으로 getter/setter 를 사용할 수 밖에 없다.어떤 용도와 목적으로 사용할 지 예측 할 수 없다.

15. but 여러분은 자신이 작성하는 코드가 어떤 용도로 사용될지 어느 정도 알고 있다. 대부분의 프로그래머들이 평소 작성하는 코드는 고도의 범용성을 필요로 하지 않는다.

16. 정리 프로그램의 유지 보수성은 객체 간에 흐르는 데이터 양과 반비례 한다. 구현을 노출 시키면 유지보수성이 나빠진다. 접근자와수정자는 조심스럽게 사용하라. 익숙한 것이 올바른 것은 아니다.

17. 그 외 몇 가지 이슈 - 부록 리팩토링 get/set 의 남용 문제는 조악한 디자인을 암시하며 이는 리팩토링이 아닌 프로그램 재디자인이 필요하다. 단순 필드 접근의 getter 보다는 클래스 객체를 반환하는 getter 가 덜 해롭다 예) double 값을 반환하는 메소드 보다 Money 객체를 반환하는 메소드가 낫다. 객체가 구현하는 인터페이스를 통해 넘겨주는 것이 베스트

18. 끗!