4주차: 7장 캡슐화

[choisohyun]

인상깊었던 책의 내용과 인상깊었던 이유
현업 등 코드에 반영할 수 있는 방법과 생각
관련 아티클이나 이해를 돕는 자료를 첨부
새롭게 알게된 점이나 이해가 어려웠던 점

[choisohyun]

캡슐화가 모두 능사는 아니다. 캡슐화를 했다가도 다시 인라인하거나 중개자를 제거할 수 있어야 한다.
쓰던 클래스의 역할이 어색해지는 순간이나 함수 분리에 대해 거부감을 가지지 않고 실행할 수 있어야겠다.

[LastCow9000]

컬렉션 변수로의 접근을 캡슐화하면서 게터가 컬렉션 자체를 반환하도록 한다면, 그 컬렉션을 감싼 클래스가 눈치채지 못하는 상태에서 컬렉션의 원소들이 바뀌어버릴 수 있다.

컬렉션을 다룰 때 주의 깊게 다뤄야 한다는 것을 다시 리마인드했습니다.

[suojae]

• mutable한 데이터에 어떻게든 직접 접근할 수 없게 만드는 것을 강조하는 챕터였다.
• 직접적으로 mutable한 데이터를 다루는게 아닌 깊은복사와 같은 immutable한 데이터를 제공하여 다루게하자는 부분이 인상깊었다

[RAINBOWJYP]

7.6장 클래스 인라인하기(Inline Class) 예시를 이해하기 어려웠습니다.

(리팩터링 하기전) TrackingInformation 클래스의 display메서드명을 trackingInfo로 바꾼게 끝이 아닌가 싶었습니다.
AI를 통해... 다른 예시로 이해를 하였습니다.

리팩터링 전

// Address.js
class Address {
    constructor(street, city) {
        this.street = street;
        this.city = city;
    }

    getFullAddress() {
        return `${this.street}, ${this.city}`;
    }
}

export default Address;

// Person.js
import Address from './Address';

class Person {
    constructor(name, street, city) {
        this.name = name;
        this.address = new Address(street, city);
    }

    getDetails() {
        return `${this.name} lives at ${this.address.getFullAddress()}`;
    }
}

export default Person;

리팩터링 후

Address 클래스를 Person 클래스에 통합하여 인라인합니다.

// Person.js
class Person {
    constructor(name, street, city) {
        this.name = name;
        this.street = street;
        this.city = city;
    }

    getFullAddress() {
        return `${this.street}, ${this.city}`;
    }

    getDetails() {
        return `${this.name} lives at ${this.getFullAddress()}`;
    }
}

export default Person;

이렇게 클래스를 인라인하면 코드의 복잡성을 줄이고, 관련된 기능을 한 곳에 모아 유지보수를 쉽게 할 수 있�다.
하지만 인라인하기 전에 해당 클래스가 정말로 불필요한지, 또는 다른 클래스와의 관계가 복잡해지지 않을지를 고려해야할 것 같다.

---

클래스를 안써봐서 소스 클래스? 타깃 클래스? 위임 메서드? 용어를 이해하지 못했는데,
소스 클래스는 '리펙터링을 통해 제거할' 클래스
타깃 클래스는 '소스 클래스 기능을 통합할' 클래스
위임 메서드는 '타깃 클래스에 생성될 메서드'로 소스 클래스의 메서드를 호출하여 작업을 수행하는거라고 AI가 알려줬습니다.

[BEMELON]

• 레코드 캡슐화 : 데이터를 직관적으로 묶어서 의미있는 단위를 제공하는 방식
• 컬렉션 캡슐화 : 레코드 캡슐화와 비슷한 관점, 하지만 원본이 아닌 사본을 제공하거나 읽기 전용 캡슐화를 만들어 원본 수정 가능성을 차단해야 함
• 기본형을 객체로 변경 : 기본형에 대해서 의미를 부여할 수 있고, 추적하기가 용이해짐
• 임시 변수를 질의 함수로 바꾸기 : 임시 변수로 변경하게 되면 함수의 경계가 명확해진다 -> 리팩토링하기 편해짐

---

• 클래스 추출하기 : 특정 데이터나 메소드 입루를 제거했을 때 어떤 일이 일어나는 지 확인하고, 로직에 영향이 없으면 분리하자
• 클래스 인라인하기 : 클래스 추출의 반대, 클래스의 역할이 사라지는 경우 적용할 수 있다

---

• 위임 숨기기 : 위임해서 처리하는 메소드가 있다면 위임 객체를 몰라도 될 정도의 캡슐화를 적용하자
• 중개자 제거하기 : 위임을 숨기는 범위가 넓어지는 경우, 객체가 중개자로 변하는 경우가 있음, 이 경우 중개자 대신 위임 객체를 직접 사용하는 것이 유용함

[hamo-o]

단순한 출력 이상의 기능이 필요해지는 순간 그 데이터를 표현하는 전용 클래스를 정의하라.

const getIsToday = (deadline: string): boolean => {
    /* ... */
}

const getIsCurrentWeek = (dateString: string): boolean => {
    /* ... */
}

위와 같이 동일한 API로부터 받아온 값들임에도 따로 유틸함수로만 관리하고 있어 코드의 응집도가 떨어졌다는 것을 알 수 있었습니다. 특정 데이터에서 여러 기능이 필요할 때 클래스를 활용해봐야겠습니다.

---

예컨대 컬렉션 변수로의 접근을 캡슐화하면서 getter가 컬렉션 자체를 반환하게 한다면, 그 컬렉션을 감싼 클래스가 눈치채지 못하는 상태에서 컬렉션의 원소들이 바뀌어버릴 수 있다.

 getPrize() {
    /* ... */
    return this.#prize;
  }

객체의 경우 # 접두사를 붙여도 예상하지 못한 변경이 생길 수 있을 것 같습니다. 원본 내용을 수정할 수 없는 읽기전용 프록시 또는 복제본을 반환하는 식으로 해결할 수 있다고 해서 더 자세히 알아봐야겠습니다.

[jamongsalguclub]

7.5 클래스 추출하기를 거꾸로 돌리는 7.6 클래스 인라인하기가 인상 깊었습니다.
이전에 좋은 코드라고 생각했어도 외부 상황이 변함에 따라 다시 안좋은 코드로 변질 할 수 있고 그에 따라 리팩토링을 해야겠다는 생각이 들었습니다.