[워밍업 클럽 3기 BE code] 1주차
잘 읽히는 코드 작성하기
메서드 선언부를 잘 활용하자
메서드 이름을 잘 짓는 것도 중요하지만 메서드 시그니처도 중요하다
메서드 사용자가 쉽게 이해하고 사용할 수 있도록 적절한 타입을 활용하자
특정 매개변수가 해당 메서드에서 어떤 행위를 위한 것인지 파악할 수 있도록 이름을 지어주는 것도 좋다
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 : 상위 계층은 하위 계층의 구현체가 아닌 추상체(인터페이스)에 의존하도록 설계한다
강의
답변 0