[아이템 51] 메서드 시그니처를 신중히 설계하라
Closed this issue · 9 comments
p310 ....객체 생성에 사용한 빌더 패턴을 메서드 호출에 응용..
- 여기서 빌더 패턴에 대해 #2 에 나눴던 이야기를 참조하시면 도움이 될 듯 싶습니다.
여기서 빌더 패턴에 대해 #2 에 나눴던 이야기를 참조하시면 도움이 될 듯 싶습니다.
빌더 패턴에 관한 이야기도 덕분에 추가하고, 조금 더 학습할 수 있었습니다.
사실 잘 이해가지 않는건, 메소드를 많이 만들지마라? 이부분인것 같아요
관심사가 제대로 분리되지 않은걸 분리를 잘시키라는건지? 아니면 단순히 메소드를 많이 만들지 말라는건지 이해가 잘가지 않네요
사실 잘 이해가지 않는건, 메소드를 많이 만들지마라? 이부분인것 같아요
관심사가 제대로 분리되지 않은걸 분리를 잘시키라는건지? 아니면 단순히 메소드를 많이 만들지 말라는건지 이해가 잘가지 않네요
- 관심사 분리가 어떤 걸 의미하는 걸까요?
- 저는 후자의 느낌으로 이해했어요.
- 너무 무분별하게 메소드를 쪼개면, 전반적인 코드 이해를 하기가 힘들어질꺼라 생각해요.
- 그래서 이 아이템에서는 메서드를 쪼개는 기준에 대해 언급한 것 같아요
사실 잘 이해가지 않는건, 메소드를 많이 만들지마라?
저도 이 부분이 읽다가 잘 이해가 가지 않았는데,
Don’t go overboard in providing convenience methods. (편의 메서드를 너무 많이 만들지 말자.) 라는 표현에서
convenience methods 가 정확히 무엇을 의미하는 것일까요?
public 으로 선언되어, class 혹은 패키지 바깥에서 사용할 수 있는 메서드를 의미하는 것일 까요?
사실 잘 이해가지 않는건, 메소드를 많이 만들지마라? 이부분인것 같아요
관심사가 제대로 분리되지 않은걸 분리를 잘시키라는건지? 아니면 단순히 메소드를 많이 만들지 말라는건지 이해가 잘가지 않네요
관심사 분리가 어떤 걸 의미하는 걸까요?
저는 후자의 느낌으로 이해했어요.
- 너무 무분별하게 메소드를 쪼개면, 전반적인 코드 이해를 하기가 힘들어질꺼라 생각해요.
- 그래서 이 아이템에서는 메서드를 쪼개는 기준에 대해 언급한 것 같아요
저는 관심사(특정 클래스 혹은 개체 에서 분리될 수 있는 데도 관심사가 겹쳐져있는?)가 제대로 분리되지 않아서 메소드가 많아진다고 생각했는데, 생각해보니 의미를 두기 위해 한두라인을 메소드로 나눠버리면 무분별하게 많아질 수 도 있겠다 라는 생각이 드네요.
사실 잘 이해가지 않는건, 메소드를 많이 만들지마라?
저도 이 부분이 읽다가 잘 이해가 가지 않았는데,
Don’t go overboard in providing convenience methods.(편의 메서드를 너무 많이 만들지 말자.) 라는 표현에서
convenience methods가 정확히 무엇을 의미하는 것일까요?
public 으로 선언되어, class 혹은 패키지 바깥에서 사용할 수 있는 메서드를 의미하는 것일 까요?
편의 메소드에 대해서 알아보고 있는데, 정확히 어떤 뜻인지 모르겠네요. 월요일날 다같이 이야기 해봐도 좋을것 같아요.
사실 잘 이해가지 않는건, 메소드를 많이 만들지마라?
저도 이 부분이 읽다가 잘 이해가 가지 않았는데,
Don’t go overboard in providing convenience methods.(편의 메서드를 너무 많이 만들지 말자.) 라는 표현에서
convenience methods가 정확히 무엇을 의미하는 것일까요?
public 으로 선언되어, class 혹은 패키지 바깥에서 사용할 수 있는 메서드를 의미하는 것일 까요?
찾았네요 단순히 이런뜻인가봐요
편의 함수, 편의 메소드
원문: https://en.wikipedia.org/wiki/Convenience_function
편의 함수는 자주 하는 작업을 더 쓰기 편하게 만들기 위해 만들어집니다. 편의 함수(convenience function) 또는 편의 메소드(convenience method)는 프로그래밍 라이브러리 또는 프레임워크에서 꼭 필요하지는 않은(비본질적) 서브루틴입니다.
이 편의 함수들은 지루한 작업을 줄이기 위해 그 라이브러리를 만든 사람이 임의로 덧붙였을 수도 있습니다. 또는, 무엇을 편의 함수로 만들면 좋을지에 대해 개발자들이 커뮤니티에서 토론하며 작업한 리팩토링 결과일 수도 있습니다.
편의 함수가 하는 일은 거의 항상 다른 연산들로도 표현될 수 있습니다. 편의 함수에는 라이브러리를 쓸 데 없이 길고 번거롭게 만들고, 추상화를 떨어뜨리며, 유지 보수를 어렵게 만드는 단점도 있습니다.
이런 관점에서, 어셈블리어 위에 구현되는 모든 프로그래밍 언어는 기계어 작성을 피하기 위한 '편의 언어'입니다.
01/25 스터디간 깨달았던 내용정리
David 가 이야기 했던대로, 편의 메소드는 클라이언트 입장에서 이해하니 좀 잘 이해가 됬다. 우리가 기본적인 기능을 제공하는 것 이외에 사용자의 편의 혹은 해당 라이브러리 이어질 수 있는 반복적인 작업을 조금 더 편리하게 하자고 메소드를 만들때에도 기본적으로 제공하는 API 들로도 구성할 수 있다면 만드는 것보다는 사용자가 응용하도록 하는게 조금 더 라이브러리 유지보수 측면에서도 좋아질 것이란 생각이 든다.