잘 읽히는 코드 작성하기

• 메서드 선언부를 잘 활용하자

  • 메서드 이름을 잘 짓는 것도 중요하지만 메서드 시그니처도 중요하다

    • 메서드 사용자가 쉽게 이해하고 사용할 수 있도록 적절한 타입을 활용하자

    • 특정 매개변수가 해당 메서드에서 어떤 행위를 위한 것인지 파악할 수 있도록 이름을 지어주는 것도 좋다

  • void를 반환하는 메서드가 있다면 반환할 만한 값이 없는지 다시 한번 확인해보자

• 메서드를 추출하고 끝이 아니라 여러 방면에서 계속 고민해보자

  • 단순히 코드가 짧아지는 것을 떠나서 메서드의 역할이 명확한지, 사용하는 쪽에서 읽기 쉬운지 고민해봐야한다

• 리팩토링을 한 뒤에는 꼭 검증을 해서 프로그램이 잘 돌아가는지 확인해보자

추상화 레벨

• 주변과 동등한 추상화 레벨을 가져야 코드가 잘 읽힌다

  • 메서드를 호출하여 사용하는 쪽은 외부 세계 / 메서드가 구현되어 있는 쪽은 내부 세계로 나누어서 서로의 추상화 레벨을 동등하게 가져가자

    • 즉 메서드를 호출하는 코드가 계속 나열되다가 구체적인 조건을 따지는 코드를 읽으면 가독성이 떨어지게 된다

    • 특정 조건을 따지는 코드는 메서드로 추출해서 사용하는 외부 세계에서는 메서드명으로 행위를 유추하도록 하자

Early return

• 뇌는 하나의 작업만을 할 수 있는데 조건문을 이해하기 위해 여러 조건을 뇌 메모리에 올려두게 된다

  • 생각하던 걸 멈추고 다른 걸 생각해야 함

• Early return을 활용해 if 조건에 해당하면 return을 해버리자 -> 그럼 return되는 if 문만 기억하면 됨

• else를 사용하지 말자는게 아니라 굳이 사용이 필요하지 않다면 return 해버리자

객체 설계하기

• setter를 지양

  • 막연하게 그래야 되는 구나 라고 생각하고 있었는데 데이터가 변하더라도 객체 자신이 자신의 데이터를 핸들링 해야 한다는 것, setter 메서드는 그 의미에서부터 맞지 않다는 것을 이해하게 되었다

  • 외부에서 해당 객체의 데이터를 핸들링하면 안된다 → 객체 지향 의미부터 완전히 맞지 않음

  • 데이터를 변경해야 하는 경우 네이밍 자체도 set ~이 아닌 update ~로 지어주는 것이 좋다

• getter 지양

  • 사실 코드를 작성하면서 getter를 자주 사용하는 편이었는데 객체에게 무례한 것이라는 말이 와닿았다

    • person.get지갑.get신분증.findAge >= 19

  • 검증이 필요한 상황에서는 객체에 메서드를 만들어 메서드와 소통하는 것이 옳다

    • 객체 지향 프로그래밍 = 객체와 소통하며 협력하기

  • person.isAgeGreaterThanOrEqualTo(19)

SOLID 원칙

• SRP : 하나의 클래스는 변경의 이유가 하나만 존재하도록 단일 책임만 가진다

• OCP : 기존 코드를 수정하지 않고, 확장에는 열려 있고 수정에는 닫혀 있어야 한다

• LSP : 자식 클래스가 부모 클래스를 대체해도 기능은 깨지지 않고 의도대로 동작해야 한다

• ISP : 클라이언트가 자신이 사용하지 않는 기능에 의존하지 않도록 인터페이스를 작고 명확하게 분리한다

• DIP : 상위 계층은 하위 계층의 구현체가 아닌 추상체(인터페이스)에 의존하도록 설계한다

강의

• https://www.inflearn.com/course/readable-code-%EC%9D%BD%EA%B8%B0%EC%A2%8B%EC%9D%80%EC%BD%94%EB%93%9C-%EC%9E%91%EC%84%B1%EC%82%AC%EA%B3%A0%EB%B2%95