3줄 요약
- 무조건 객체 지향코드만 쓰기보다는 절차적인 코드와 비교하여 무엇이 적절한 지 생각하고 코드를 짜야한다.
- 아무 생각 없이 짜는 코드가 가장 나쁘다.
- 아닌건 아니라고 말할 수 있을만큼 배우자!
오늘 읽은 범위
6장 객체와 자료 구조
책에서 기억하고싶은 내용
- 자료를 세세하게 공개하기보다는 추상적인 개념으로 표현하는 편이 좋다. 아무 생각 없이 조회/설정 함수를 추가하는 방법이 가장 나쁘다.[119]
- 객체 지향 코드에서 어려운 변경은 절차적인 코드에서 쉬우며, 절차적인 코드에서 어려운 변경은 객체 지향 코드에서 쉽다.[122]
- 분별있는 프로그래머는 모든 것이 객체라는 생각이 미신임을 잘 안다. 때로는 단순한 자료 구조와 절차적인 코드가 가장 적합한 상황도 있다.[122]
- 디미터 법칙은 잘 알렺니 휴리스틱으로, 모듈은 자신이 조작하는 객체의 속사정을 몰라야 한다는 법칙이다.[123]
- (어떤) 시스템을 구현할 때, 새로운 자료 타입을 추가하는 유연성이 필요하면 객체가 더 적합하다. 다른 경우로 새로운 동작을 추가하는 유연성이 필요하면 자료 구조와 절차적인 코드가 더 적합하다. 우수한 소프트웨어 개발자는 편견 없이 이 사실을 이해해 직면한 문제에 최적인 해결책을 선택한다.[128]
읽은 소감과 떠오르는 생각
- 코딩을 처음 배울 때 모든 것은 객체라고 배웠다. 지금까지 객체 지향 구조가 무조건 정답인줄 알고있었다. 그래서 코드도 항상 객체지향적으로 쓰고 있었다. 하지만 저자는 모든 것이 객체라는 생각이 미신이라고한다. 저자의 저의는 절차적인 코드나 객체 지향 코드를 미래에 어떤 걸 변경할 지 생각하면서 이 2개 중 하나를 적절하게 사용하라는 것 같다.
- 이 사람은 어떤 객체에서 데이터를 변경할 때 해당 변수를 직접 건드리는게 아니라 get, set으로 컨트롤하는게 정석이라고 생각하고 있는 것 같다. 최근에 코딩할 때 돌이켜보면 useState도 결국 get,set으로 되어있는거구나싶다. 사실 뭐가 정답인지 모르겠다;; 계속 봐야겠다;;
- 옛날에 javabean 배울 때 어렵게 배운게 생각나는데 사이비 캡슐화라고 별다른 이익이 없다고 말한다 ㅋㅋㅋㅋ 강하다... 나도 이렇게 자신감있게 말할 수 있는 개발자가 되고싶다..;;;;
- 어차피 Lean, Agile 개발이 요즘 대세인데 자료 타입이 바뀔 수도 있고 동작도 바뀔 수 있다고 생각한다. 일단 나는 대세고 계속 해왔던 객체지향코드로 가야겠다...
궁금한 내용이나 잘 이해되지 않는 내용
- 모든 것은 객체가 맞긴 하지 않나.. => 저자가 모든 것이 객체라는 생각이 미신이라고 한 이유는 책에서도 말했듯 절차적인 코드가 유리할 때도 있기 떄문이라고 생각한다. 맞겠지요..?
- 코드를 짜고있다가 생각났는데 사실상 데이터모델은 한 번 정의하면 많이 바꾸지 않는다. 거기에 api를 추가하는게 대부분이다. 그럼 절차적인 코드가 더 낫다는건데 왜 다들 객체 지향인거야.... 나중에 더 잘해질 때 다시 한 번 이 글을 보고 다르게 생각할 수 있는 내가 되었으면 좋겠다.
나 원장이 아니다