너무 많은 추상화가 나쁠 수 있습니까?

프로그래머로서 우리의 목표는 주어진 도메인 모델과 비즈니스 로직에 대한 훌륭한 추상화를 제공하는 것입니다. 그러나이 추상화는 어디에서 멈추어야합니까? 추상화 와 모든 이점 (유연성, 변경 용이성 등) 과 코드 및 이해 의 이점 을 이해하는 것 사이 의 균형 을 맞추는 방법 .

나는 지나치게 추상화 된 코드를 작성하는 경향이 있다고 생각하며 그것이 얼마나 좋은지 모르겠다. 나는 종종 두 가지 부분으로 구성된 일종의 마이크로 프레임 워크처럼 작성하는 경향이 있습니다.

1. 마이크로 프레임 워크에 연결되는 마이크로 모듈 :이 모듈은 단일 장치로 이해, 개발 및 유지 관리가 쉽습니다. 이 코드는 기본적으로 요구 사항에 설명 된 기능을 실제로 수행하는 코드를 나타냅니다.
2. 연결 코드; 이제 여기에 문제가 있다고 생각합니다. 이 코드는 때때로 매우 추상화되어 처음에는 이해하기 어렵 기 때문에 복잡해집니다. 이것은 순수한 추상화, 사실의 기초, 제시된 코드에서 수행되는 비즈니스 로직이라는 사실 때문에 발생합니다. 이러한 이유로이 코드는 일단 테스트되면 변경되지 않을 것입니다.

이것이 프로그래밍에 대한 좋은 접근입니까? 그것은 많은 모듈에서 변경 코드를 매우 조각화하고 이해하기 쉽고 매우 쉽게 변경하지 않는 코드를 추상화 POV와 매우 복잡합니까? 모든 코드가 균일하게 복잡해야합니다 (즉, 코드 1이 더 복잡하고 상호 연결되어 있고 코드 2가 더 간단해야 함). "코드 변경"은 이해, 디버깅, 변경이 매우 쉽고 "링크 코드"는 매우 어렵습니다.

참고 : 이것은 코드 가독성에 관한 것이 아닙니다! 1과 2의 코드는 모두 읽을 수 있지만 2의 코드는 더 복잡한 추상화가 제공되고 코드 1은 간단한 추상화가 제공됩니다.

TC ++ PL4의 첫 단어 :

컴퓨터 과학의 모든 문제는 너무 많은 간접 계층의 문제를 제외하고 다른 수준의 간접 지시로 해결할 수 있습니다. – 데이비드 J. 휠러

(David Wheeler는 저의 논문 고문이었습니다. 중요한 마지막 줄이없는 인용문은 때때로 "컴퓨터 과학의 첫 번째 법칙"이라고 불립니다.)

물론 이죠 문제는 완벽하지 않다는 것입니다. 추상화가 위에있는 레이어의 모든 세부 사항은 이유가 있으며 많은 것을 단순화 할 수 있지만, 어느 시점에서 복잡성이 필요하지 않은 경우에는 처음에는 없을 것입니다. 그것은 어떤 시점에서 모든 추상화가 어떤 방식 으로든 유출 될 것임을 의미합니다 .

그리고 그것이 진짜 문제가있는 곳입니다. 추상화가 실패하면 작성한 코드와 실제로 진행되는 코드 사이에 계층화 된 것이 많을수록 문제를 파악하고 해결하기가 더 어려워집니다. 문제가있는 곳이 더 많기 때문입니다. 레이어가 많을수록 추적하기 위해 더 많이 알아야합니다.

네 그럼요.

프로그래밍을 설명하는 데 사용하는 비유는 Tailor와 비슷합니다. 양복을 만들 때, 좋은 재단사는 항상 옷의 전략적 위치에 소량의 옷감을 남겨 두어 옷의 전체적인 모양이나 구조를 바꾸지 않고 옷을 가져 오거나 꺼낼 수 있도록합니다.

Good Tailor는 세 번째 팔을 키우거나 임신 할 때를 대비하여 각 이음새에 직물을 다량으로 남겨 두지 않습니다. 잘못된 장소에 재료가 너무 많으면 몸에 좋지 않은 옷을 입을 수 있고 옷을 입지 않으면 여분의 옷감은 정상적인 사용에 방해가됩니다. 옷감이 적고 옷이 찢어지기 쉬우 며 착용자의 체격에 약간의 변화가 생기면 옷이 앉는 방식에 영향을 줄 수 없습니다.

아마 언젠가, 우리의 Good Tailor는 드레스를 너무 꽉 조여서 옷을 입어야합니다. 그리고 우리의 Good Tailor는 스타일과 착용감이 편안함과 확장성에 이어 두 번째로 임산부 착용을 요구할 것입니다. 그러나 그 특별한 직업을 수행하기 전에 좋은 재단사는 모든 사람들이 그러한 목표를 달성하기 위해 타협을 인식하도록 충분히 현명 할 것입니다.

때때로 이러한 타협은 올바른 길을 가고 사람들은 그들의 결과를 기꺼이 받아들입니다. 그러나 대부분의 경우, 가장 많이 계산되는 곳에 약간의 휴가를 두는 것이인지되는 혜택보다 중요합니다.

그래서 이것을 다시 추상화와 관련시킵니다. 그것은 거의 불가능한 방법과 마찬가지로 너무 많은 추상화 계층을 가질 수 있습니다. 우리의 재단사 친구들과 마찬가지로 프로그래머의 진정한 예술은 그것이 가장 중요한 곳에 조금 남겨 두는 것입니다.

주제로 돌아 가기

코드의 문제는 일반적으로 추상화가 아니라 종속성입니다. 당신이 지적했듯이, 문제가되는 개별 객체를 연결하는 코드는 암시 적 종속성이 있기 때문에 문제가됩니다. 어떤 시점에서 사물 간의 의사 소통은 구체적이어야하지만, 그 점이 어디인지 판단하려면 보통 약간의 추측이 필요합니다.

"마이크로"라는 말은 일반적으로 객체 레이아웃을 과도하게 과립 화했음을 나타내며 아마도 Type 을 Data 이어야하는 동의어로 사용하고있을 것입니다 . 일이 적다는 것은 또한 의사 소통에 필요한 의존성이 줄어든다는 것을 의미합니다.

이런 이유로 시스템 간 비동기 메시징을 좋아합니다. 메시지 가 아닌 서로 에 대한 두 시스템으로 끝납니다 . 통신 시스템 간의 연결을 줄입니다. 이 시점에서 시스템간에 종속성이 필요한 경우 올바른 위치에 종속 된 비트가 있는지 여부를 고려해야합니다. 그리고 종종 당신이하지 않는 경우입니다.

마지막으로 복잡한 코드는 복잡해질 것입니다. 종종 그 주위에 방법이 없습니다. 그러나 의존성이 적은 코드는 다양한 외부 상태에 의존하는 코드보다 이해하기가 훨씬 쉽습니다.

우리의 목표는 주어진 도메인 모델과 비즈니스 로직에 대한 훌륭한 추상화를 제공하는 것입니다.

나는 다른 견해를 가지고 있습니다. 우리의 목표는 비즈니스 문제를 해결하는 것입니다. 추상화는 솔루션을 구성하는 기술 일뿐입니다. 또 다른 대답은 옷을 만드는 재단사의 비유를 사용합니다. 내가 생각하고 싶은 또 다른 비유가 있습니다 : 해골. 코드는 골격과 같으며 추상화는 뼈 사이의 연결점입니다. 관절이 없다면, 전혀 움직일 수없고 쓸모없는 하나의 뼈로 감습니다. 그러나 관절이 너무 많으면 자립 할 수없는 조잡한 젤리 더미가 생깁니다. 비결은 올바른 균형을 찾는 것입니다. 움직임을 허용하기에 충분한 관절이지만 실제 정의 된 모양이나 구조가 없을 정도로 크지 않습니다.