TL : DR;

나는“필요한”수의 수준의 절제가 아래에 너무 적거나 너무 많다고 생각하지 않습니다. 그래픽 디자인과 마찬가지로, 좋은 OOP 디자인은 보이지 않아야하며 당연한 것으로 여겨 져야합니다. 나쁜 디자인은 항상 아픈 엄지 손가락처럼 튀어 나옵니다.

긴 대답

아마도 당신은 당신이 추상화하고있는 추상화 수준이 얼마나 많은지 모를 것입니다.

대부분의 추상화 수준은 우리에게 보이지 않으며 당연한 것으로 간주합니다.

그 추론은 나를 다음과 같은 결론으로 ​​이끌어줍니다.

추상화의 주요 목적 중 하나는 프로그래머가 시스템의 모든 작업을 항상 염두에 두어야 할 필요성을 줄이는 것입니다. 디자인으로 인해 무언가를 추가하기 위해 시스템에 대해 너무 많이 알면 추상화가 거의 없을 것입니다. 잘못된 추상화 (빈약 한 디자인, 빈약 한 디자인 또는 과도한 엔지니어링)로 인해 무언가를 추가하기에는 너무 많은 지식이 필요하다고 생각합니다. 하나의 극단적 인 경우에는 신 클래스 또는 많은 DTO를 기반으로하는 디자인이 있고, 다른 극단적 인 경우에는 헤아릴 수없는 후프를 뛰어 넘어 안녕하세요 세계를 달성 할 수있는 OR / 지속 프레임 워크가 있습니다. 두 경우 모두 너무 많이 알고 있습니다.

나쁜 추상화는 일단 달콤한 지점을 지나면 방해가되기 시작한다는 사실에서 가우스 벨을 고수합니다. 반면에, 좋은 추상화는 보이지 않으며, 거기에있는 것을 눈치 채지 못하므로 너무 많을 수 없습니다. API, 네트워크 프로토콜, 라이브러리, OS 라이브러리, 파일 시스템, 하웨어 계층 등의 계층에 애플리케이션이 구축되고 당연한 계층 수를 생각하십시오.

추상화의 다른 주요 목적은 구획화 (compartmentation)입니다. 따라서 이중 선체 및 별도의 탱크와 달리 선체의 일부에 구멍이있을 때 배가 완전히 범람하는 것을 방지하지 않고 특정 영역을 넘어서 오류가 침투하지 않습니다. 코드 수정으로 인해 관련이없는 것처럼 보이는 버그 가 발생하는 경우 추상화가 거의 없을 가능성이 있습니다.

답변