센바 다이야 - <내 코드가 그렇게 이상한가요?>. 인사이트. [ 도서 정보 ]
책을 읽으며, 인상 깊거나 기억해 두고 싶었던 부분을 기록하였습니다!
이하에 인용하는 글 및 코드는 본 책에서 인용하였으며,
추가로 남기고 싶은 메모가 있었던 경우에는 각 인용의 하단에 별도로 작성하였음을 밝힙니다.
"이처럼 데이터와 로직 등이 분산되어 있는 것을 응집도가 낮은 구조라고 합니다." p.9
[ 추가 메모 ]
코드의 품질을 이야기할 때, 결합도가 낮고 응집도는 높은 것이 좋은 구조이다-라는 이야기를 많이 들었던 것 같습니다. 그 중에서도 응집도가 높은 구조가 뜻하는 바가 항상 궁금했었는데, 본문의 설명을 읽으면서 보다 개념을 명확히 이해할 수 있는 계기가 되었습니다!
"값 객체(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 메서드는 인스턴스 변수를 사용할 수 없습니다. 따라서 어떤 메서드를 static 메서드로 만든 시점에 이미 데이터와 데이터를 조작하는 로직 사이에 괴리가 생깁니다. p.61."
[ 추가 메모 ]
이 책을 읽기 한참 전에, 다른 개발자분으로부터 "객체 지향 관점에서, static 메서드를 쓰는 게 안 좋다더라-" 하는 이야기를 들은 적이 있었습니다. 그때는 명확한 이유를 듣지 못했는데, 해당 부분을 읽으며 조금 더 명확한 이유를 파악할 수 있게 되어 기록합니다! :)
"조건을 부품으로 만들고, 부품으로 만든 조건을 조합해서 사용하는 패턴입니다." p.119.
[ 본문 예제 ]
interface ExcellentCustomerRule {
/**
* @param history 구매 이력
* @return 조건을 만족하는 경우 true
*/
boolean ok(final PurchaseHistory history);
}
[ 추가 메모 ]
본문 예제와 같이, 특정한 interface를 구현하는 rule을 여러 개 생성하고, 특정한 Policy 클래스에 여러 rule을 hashSet 등의 형태로 할당하여 각 rule을 충족하는지 확인하는 패턴입니다. 낯선 패턴이었지만, 복잡한 조건문을 간결히 하는 데 유용할 것 같습니다!
"일급 컬렉션이란 컬렉션과 관련된 로직을 캡슐화하는 디자인 패턴입니다. p.141"
"같은 로직, 비슷한 로직이라도 개념이 다르면 중복을 허용해야 합니다." p.158
[ 추가 메모 ]
저에게는 새로운 관점으로 다가왔던 부분입니다. 유사한 로직의 반복은 무조건 안 좋은 지표라고 생각했지만, 때론 중복의 허용보단 결합을 낮추는 데 더 큰 의미가 있을 수 있음을 생각해 보려 합니다.
"실제로 지금 당장 필요한 것들만 만들라는 방침입니다. p.188"
"사용자가 예상하지 못한 놀라움을 최소화하도록 설계해야 한다는 접근 방법입니다. 이를 위해서는 로직과 이름을 잘 대응시켜야 합니다. p.234."
"<리팩터링 2판>(17.1.3절)을 보면, 이러한 전환을 '두 개의 모자'라고 표현합니다. 작업을 할 때는 '기능 추가' 모자와 '리팩터링 모자' 중에서 하나만 쓰고 있어야 한다는 표현이 나옵니다. p.318."