센바 다이야 - <내 코드가 그렇게 이상한가요?>. 인사이트. [ 도서 정보 ]
책을 읽으며, 인상 깊거나 기억해 두고 싶었던 부분을 기록하였습니다!
이하에 인용하는 글 및 코드는 본 책에서 인용하였으며,
추가로 남기고 싶은 메모가 있었던 경우에는 각 인용의 하단에 별도로 작성하였음을 밝힙니다.
구조의 응집도 p.9
"이처럼 데이터와 로직 등이 분산되어 있는 것을 응집도가 낮은 구조라고 합니다." p.9
[ 추가 메모 ]
코드의 품질을 이야기할 때, 결합도가 낮고 응집도는 높은 것이 좋은 구조이다-라는 이야기를 많이 들었던 것 같습니다. 그 중에서도 응집도가 높은 구조가 뜻하는 바가 항상 궁금했었는데, 본문의 설명을 읽으면서 보다 개념을 명확히 이해할 수 있는 계기가 되었습니다!
값 객체 p.38
"값 객체(value object)란 값을 클래스(자료형)로 나타내는 디자인 패턴입니다. ... 이러한 값을 값 객체로 만들어서 사용하면, 각각의 값과 로직을 응집도가 높은 구조로 만들 수 있습니다." p.38
[ 추가 메모 ]
값 객체에 대한 설명은 책에서 여러 차례 언급되는데, 대체로 기본형을 사용을 자제하고 값 객체의 활용을 고민하라는 이야기였던 것 같습니다. 책에는 관련된 좋은 예시가 많이 등장하지만, 책의 해당 부분을 읽고 직접 적용해 보았던 예제 코드가 있어, 이를 기록해 두고자 합니다.
< 블록체인 상의 토큰 컨트랙트 주소에 대한 값 객체 >
export class Address {
private readonly address: string;
constructor(address: string) {
const isValidAddress = ethers.utils.isAddress(address);
if (!isValidAddress)
throw new InternalServerErrorException(`Cannot create Address`, `Address ${address} is invalid`);
this.address = address;
}
public value(): string {
return this.address;
}
public isSameAddrWith(address: Address): boolean {
return this.address.toLowerCase() === address.value().toLowerCase();
}
public isZeroAddress(): boolean {
return this.address === ethers.constants.AddressZero;
}
}static 메서드 오용 p.60
"static 메서드는 인스턴스 변수를 사용할 수 없습니다. 따라서 어떤 메서드를 static 메서드로 만든 시점에 이미 데이터와 데이터를 조작하는 로직 사이에 괴리가 생깁니다. p.61."
[ 추가 메모 ]
이 책을 읽기 한참 전에, 다른 개발자분으로부터 "객체 지향 관점에서, static 메서드를 쓰는 게 안 좋다더라-" 하는 이야기를 들은 적이 있었습니다. 그때는 명확한 이유를 듣지 못했는데, 해당 부분을 읽으며 조금 더 명확한 이유를 파악할 수 있게 되어 기록합니다! :)
정책 패턴으로 조건 집약하기 p.119
"조건을 부품으로 만들고, 부품으로 만든 조건을 조합해서 사용하는 패턴입니다." p.119.
[ 본문 예제 ]
interface ExcellentCustomerRule {
/**
* @param history 구매 이력
* @return 조건을 만족하는 경우 true
*/
boolean ok(final PurchaseHistory history);
}[ 추가 메모 ]
본문 예제와 같이, 특정한 interface를 구현하는 rule을 여러 개 생성하고, 특정한 Policy 클래스에 여러 rule을 hashSet 등의 형태로 할당하여 각 rule을 충족하는지 확인하는 패턴입니다. 낯선 패턴이었지만, 복잡한 조건문을 간결히 하는 데 유용할 것 같습니다!
일급 컬렉션 p.141
"일급 컬렉션이란 컬렉션과 관련된 로직을 캡슐화하는 디자인 패턴입니다. p.141"
DRY(Don't repeat yourself)? p.158.
"같은 로직, 비슷한 로직이라도 개념이 다르면 중복을 허용해야 합니다." p.158
[ 추가 메모 ]
저에게는 새로운 관점으로 다가왔던 부분입니다. 유사한 로직의 반복은 무조건 안 좋은 지표라고 생각했지만, 때론 중복의 허용보단 결합을 낮추는 데 더 큰 의미가 있을 수 있음을 생각해 보려 합니다.
YAGNI(You Aren't Gonna Need It) p.188
"실제로 지금 당장 필요한 것들만 만들라는 방침입니다. p.188"
놀람 최소화 원칙 p.234.
"사용자가 예상하지 못한 놀라움을 최소화하도록 설계해야 한다는 접근 방법입니다. 이를 위해서는 로직과 이름을 잘 대응시켜야 합니다. p.234."
두 개의 모자 p.318.
"<리팩터링 2판>(17.1.3절)을 보면, 이러한 전환을 '두 개의 모자'라고 표현합니다. 작업을 할 때는 '기능 추가' 모자와 '리팩터링 모자' 중에서 하나만 쓰고 있어야 한다는 표현이 나옵니다. p.318."
