리팩터링캡슐화[리팩터링] 캡슐화
[리팩터링] 캡슐화 리팩터링 저자에 따르면 모듈을 분리하는 가장 중요한 기준은 시스템에서 각 모듈이 자신을 제외한 다른 부분에 드러내지 않아야 할 비밀을 얼마나 잘 숨기느냐에 있다. 클래스는 본래 정보를 숨기는 용도로 설계되었고, 클래스는 내부 정보뿐 아니라 클래스 간의 연결 관계를 숨기는 데도 유용하다. 그리고 캡슐화의 가장 큰 단위는 클래스와 모듈이지만, 함수도 구현을 캡슐화한다. 오늘은 캡슐화 방법을 통해 어떻게 리팩터링해서 깔끔한 코드를 만들 수 있을지 함께 공부해서 좋은 코드를 만드는 것이 목표다. 레코드는 연관된 여러 데이터를 직관적인 방식으로 묶을 수 있어서 각각 따로 취급할 때보다 훨씬 의미있는 단위로 전달할 수 있게 해준다.그런데 단순한 레코드에는 단점이 있다. 계산해서 얻을 수 있는 값과 그렇지 않은 값을 명확히 구분해 저장해야 해서 번거롭다. 예를 들면 최종 세금같이 여러 상수들의 곱을 통해 최종 산출되는 값이 필요한 경우 번거로워 진다. 레코드 구조는 두가지로 구분할 수 있다. 필드명을 노출하는 형태와 필드를 외부로부터 숨겨서 원하는 이름을 쓰는 형태다. 예를들면 전자는 클래스같이 필드명이 노출되는 형태이고, 후자는 Map, HashMap, dictionary처럼 Map.get("키")와 같이 필드명이 노출되지 않는 형태다. 그런데 필드명을 노출하지 않는 형태는 불분명함이 크기때문에 필드명을 노출하는 형태가 선호된다. 1.1 레코드 캡슐화 절차 절차 레코드를 담은 변수를 캡슐화한다. (기본 리팩터링 6.1 변수 캡슐화 참고) 레코드를 감싼 단순한 클래스로 해당 변수의 내용을 교체한다. 이...2025-08-18
리팩터링[리팩터링] 기본적인 리팩터링
[리팩터링] 기본적인 리팩터링 최근 Nextjs로 만든 블로그를 리팩터링하면서 만족스럽지 않은 것 같아 다시 리팩터링을 공부해보고자 한다. 나는 "어떤 자세를 취해야 할까??" 혹은 "어느 정도까지 리팩터링 원칙을 적용해야할까?" 혹은 "책에서는 리팩터링이 성능을 낮추지만 리팩터링 후에는 오히려 성능 튜닝하기 편해진다는 식으로 말했었는데 과연 그런 여유를 가지며 리팩터링 할 수 있을까??"와 같은 생각을 자주 한다. 현업에서도 상황에 따라 적정선이 많이 달라지는 것 같다는 생각을 많이 했었고 결국 모든 것은 트레이드오프 관계로 이루어진다는 것이 현재 나의 생각이다... 이런 막연한 생각 말고 좀 더 구체적으로 상황에 따른 해법을 제시할 수 있으면 좋겠다. 그래서 내가 만든 컴포넌트 중 엉망인 부분을 리팩터링 책에 나온 기본적인 리팩터링을 적용하면 어떻게 느껴질지 실험해보고자 한다. 물론 시간이 많이 걸려서 책에 있는 예시도 많이 사용할 예정이다. 함수 호출하기는 인라인 코드를 별도로 함수로 만들어 호출하는 것을 의미한다. 함수(function) 추출하기에서 함수는 객체 지향 언어의 메서드(method)나 절차형 언어의 프로시저(procedure)나 서브루틴(subroutine)이라고 보고 똑같이 적용하면 된다. 코드를 "언제 함수로 묶어야 할까?"라는 기준은 너도 나도 다르다. 그 기준은 길이가 될 수 있고, 화면을 기준으로 될 수 있고, 재사용성을 기준으로 둘 수 있다. 리팩터링 책 저자는 "목적과 구현을 분리"하는 방식이 가장 합리적인 기준으로 본다. 개인 적인 해석으로는 추상화라고 생각한다. 구현한 코드...2025-08-12