[독서] 실용주의 프로그래머 정리 - 05

실용주의 프로그래머 - 교보문고

구부러지거나 부러지거나

26. 결합도 줄이기와 디미터 법칙

  이전 글에서 '부끄럼 타는' 코드를 작성하는 것이 이롭다고 설명했습니다. 이때 '부끄럼 타는' 이란 자신의 모든 것을 드러내지 않고, 너무 많은 사람과 상호작용을 하지 않는다는 두 가지의 의미를 가지고 있습니다. 코딩을 하며 어떤 모듈들을 만들 때 각 모듈 간의 상호작용을 제한해야 합니다. 그러면 한 모듈이 변경되거나 교체된다 하더라도 다른 모듈들은 변경 없이 수행될 수 있을 것입니다.

 

디미터 함수 법칙은 프로그램에서 모듈간 결합도를 최소화하려 시도합니다. 이 법칙은 한 객체가 제공하는 메서드에 접근하기 위해 또 다른 객체들을 통하는 것을 허용하지 않습니다. 디미터 법칙은 코드를 더 적응성 있고 강하게 만들어 주지만 디미터 법칙을 적용하기 위한 간단한 메서드들이 상당수 필요해져서 잘못하면 성능  저하와 메모리 과부하라는 부작용을 가져올 수 있습니다.

 

그리고 디미터 법칙 역시 본인이 만들려는 애플리케이션에 맞게 장점과 단점을 잘 고려해야 합니다. 데이터 베이스 스키마 설계 시에 '반 정규화'를 통해서 성능을 개선하는 방식도 있는 것처럼 디미터 법칙과는 반대로 결합도를 높임으로써 중요한 성능 향상을 가져올 수도 있습니다. 해당 모듈들이 서로 결합하고 있다는 것을 잘 파악하고 있으며, 그것을 받아들일 수 있다면 괜찮은 설계라고 할 수 있을 것입니다. 하지만 그렇지 않다면 여러분은 깨지기 쉽고, 위험한 미래를 향해서 가고 있는 것일 것입니다.

 

 

27. 메타프로그래밍

  세부사항은 깔끔한 코드를 만드는 것을 방해합니다. 특히 변화가 잦을 때에는 더더욱 그렇습니다. 이런 저런 이유로 코드를 변경하게 될 때마다 새로운 버그가 시스템을 깨뜨릴 수 있는 위험을 낳게 됩니다. 그러므로 세부사항을 코드에서 몰아내야 합니다. 그렇게 하면 우리의 코드는 매우 설정 가능하게 되고 '소프트' 해집니다.

 

동적 설정

  우선 시스템을 설정가능하게 만들어야 합니다. 예를 들면 배경 색, 폰트, 데이터베이스 제품, 미들웨어 기술 등을 말입니다. 이런 아이템들은 통합하거나 엔지니어링 하지 말고 설정 옵션으로 구현해야 합니다.

 

메타데이터는 애플리케이션을 기술하는 모든 데이터를 말할 수 있습니다. 애플리케이션이 어떻게 실행되어야 하고, 어떤 자원을 이용해야 하는지 등을 기술한다면 메타데이터라 할 수 있습니다. 우리는 세부 내용은 이 메타데이터에 그리고 일반적인 내용들을 코드로 작성해야 합니다. 이렇게 한다면 몇가지 이점이 생깁니다.

 

- 설계의 결합도를 줄여 좀 더 유연하고 적응성 있는 프로그램을 만들 수 있습니다.

- 세부사항을 코드 밖으로 몰아냄으로써 보다 강하고 추상적인 디자인을 만들 수 있습니다.

- 애플리케이션을 커스터마이징 하기 위해서 다시 컴파일할 필요가 없습니다.

- 메타데이터는 범용 프로그래밍 언어보다 문제 도메인에 가까운 방식으로 표현될 수 있습니다.

- 동일한 애플리케이션 엔진과 상이한 메타데이터를 이용해 여러 다른 프로젝트를 진행할 수 있게 됩니다.

 

가능한 마지막 까지 세부 정의를 피하고, 세부사항은 소프트하게, 변화하기 쉽게 남겨두면 좋습니다. 빠르게 변화할 수 있는 해결안을 강구함으로써 많은 프로젝트의 방향전환에 유연하게 대처할 수 있게 될것 입니다.

 

28. 시간적 결합

  일반적으로 작업에 있어서 신경쓰이는 시간은 일정뿐입니다. 다만 이번에는 소프트웨어의 설계 요소 자체로서의 시간의 역할에 대해서 다뤄보고자 합니다. 시간에는 우리에게 의미 있는 두 가지 측면이 있습니다. 동시성과 순서가 그것입니다.

 

대부분 사람들은 직선적인 사고방식을 하게 되어있습니다. 이것을 하고, 그 다음에 저것을 하고. 하지만 이런 방식으로 생각을 하게 되면 시간적 결합, 즉 시간 측면에서의 결합을 만들게 됩니다. 예를 들자면 메서드 A는 언제나 반드시 메서드 B 이전에 호출이 되어야 하거나, 버튼 클릭을 처리하려면 먼저 화면이 갱신되어야 하는 등 시간적인 흐름대로 프로그램이 흘러가야만 하는 경우를 말합니다. 그러나 이런 접근 방법은 그다지 유연하지 않고, 현실적이지도 않습니다. 우리는 동시성을 허용할 필요가 있으며 시간이나 순서에 따른 의존성의 결합을 끊을 방법을 생각할 필요가 있습니다. 

 

우리는 일단 동시에 일어나도 되는 것은 어떤 것이고, 엄격한 순서에 따라 일어나야 하는 것은 어떤 것인지 찾아내야 합니다. 활동 다이어그램 같은 표기법을 사용해서 사용자들이 기술해 준 작업흐름을 기록하는 것이 그 방법 중 하나입니다.

 

개발 플랫폼으로 자바가 점점 더 많이 쓰이면서 더 많은 개발자들이 다중 쓰레드 프로그래밍을 접하게 되었습니다. 하지만 다중 쓰레드를 쓰는 프로그래밍은 몇 가지 설계상의 제약을 받게 되는데 이것은 오히려 좋은 일입니다. 이 제약 조건들을 지킴으로서 좋은 설계를 하는데에 많은 도움이 되기 때문입니다.