역할과 책임에 충실하면서 다른 객체와 잘 협력해 동작하는 객체. 프로그램이 거대해지면서 객체지향이라는 패러다임이 나왔고, 그것이 묻는 것도 좋은 객체를 만들고 있는가다.
뒤집으면 나쁜 객체가 무엇인지도 나온다. 한 객체에 여러 역할을 몰아준 경우가 그렇고, 이름과 맞지 않는 속성이나 기능을 달고 있어도, 제대로 동작하지 않아도, 다른 객체와 협력하지 못해도 마찬가지다.
이름과 맞지 않는 필드
“이름과 맞지 않는 속성”이라는 조건이 실전에서 가장 쓸모 있다. 클래스 이름을 보고 예상되지 않는 필드나 메서드가 있으면 그 객체는 역할이 하나가 아니라는 신호다.
UserService에 이메일 발송 로직이 들어 있다면 이름과 맞지 않는다. 이름을 UserAndEmailService로 바꾸는 대신 객체를 나누는 것이 답이고, 이것이 SRP다.
협력이 요구하는 것
객체 하나가 모든 것을 하지도 않는다. 메시지를 주고받으며 함께 일을 끝내기 때문에 좋은 객체의 조건에 협력이 들어간다. 협력하려면 상대를 알아야 하는데, 상대의 구체적인 모습까지 알면 결합이 강해진다. 그래서 추상 타입으로 알고 밖에서 받는다.
지나친 분리
반대 방향의 실수도 있다. 사칙연산 하나하나를 클래스로 빼면 책임이 연산이지 덧셈이 아니므로 지나친 분리다. 객체지향적으로 설계하다 보면 파일만 잔뜩 늘어나는 결과가 나오기 쉽다.
계산기를 만들 때 계산기 하나에 연산과 저장을 다 넣지도 않고, 덧셈과 뺄셈을 따로 두지도 않는다. 계산기와 연산과 표현식 정도의 책임으로 보는 것이 적당하다는 판단이 필요하다.