“조기 추상화”란 무엇입니까?

나는 문구가 arround에 던져지는 것을 들었고 나에게 논쟁은 완전히 미친 소리로 들린다. (여기서 내가 밀짚을 치고 있다면 미안하지만 내 의도는 아니다)

일반적인 경우가 무엇인지 알기 전에 추상화를 생성하고 싶지 않습니다. 그렇지 않으면 (1) 속하지 않은 추상화에 포함하거나 (2) 중요한 것을 생략 할 수 있습니다.

(1) 나에게 이것은 프로그래머가 실용적이지 않은 것처럼 들리지만, 최종 프로그램에는 존재하지 않을 것이라고 가정하여, 추상화 수준이 낮게 작업하고 있지만 문제는 아닙니다. 미숙 한 추상화, 미숙 한 구체화입니다.

(2) 중요한 것들을 생략하는 것이 한 가지입니다. 나중에 중요한 것으로 판명 된 사양에서 무언가가 생략 될 수 있습니다. 잘못 추측되면 클라이언트로부터 더 많은 정보를 얻는 것입니다.

우리는 항상 추상적 인 것에서부터 개념에 이르기까지 노력해야합니다. 왜냐하면 이것은 다른 방식이 아닌 가장 실용적인 방법입니다.

그렇게하지 않으면 고객에 대한 오해와 변화가 필요한 것들을 만들 위험이 있지만, 추상화를 구축하면 고객이 자신의 언어로 정의한 추상화만으로도이 위험에 노출되지 않습니다 (적어도 최소한 예, 고객이 세부 사항에 대해 마음을 바꿀 수는 있지만 원래 원하는 것을 전달하는 데 사용한 추상화는 여전히 유효한 경향이 있습니다.

다음은 예입니다. 고객이 품목 포장 로봇을 생성하기를 원한다고 가정합니다.

public abstract class BaggingRobot() {
    private Collection<Item> items;

    public abstract void bag(Item item);
}

우리는 클라이언트가 우리가 모르는 것들에 대해 더 자세히 설명하지 않고 사용한 추상화로부터 무언가를 구축하고 있습니다. 이것은 매우 융통성이 있습니다. 실제로 "배기 추상화"라고 불리는 것을 보았습니다. 실제로 배깅이 어떻게 구현되었는지를 가정하는 것이 더 시기상조입니다. . 수업을 업데이트하려면 서명을 변경하기 만하면됩니다. 그러나 상향식으로 시작한 사람에게는 큰 시스템 점검이 필요할 수 있습니다.

미숙 한 추상화, 미숙 한 구체화와 같은 것은 없습니다. 이 진술에 어떤 문제가 있습니까? 내 추리의 결함은 어디에 있습니까? 감사.

적어도 제 생각으로는, 조기 추상화는 상당히 일반적이며, OOP의 역사에서 특히 일찍 시작되었습니다.

적어도 내가 본 것에서 발생한 주요 문제는 사람들이 객체 지향 계층의 전형적인 예를 읽는다는 것이 었습니다. 앞으로 발생할 수있는 변화에 대처할 수있는 모든 것을 준비하는 방법에 대해 많은 이야기를 들었습니다 . 한동안 많은 기사들에게 공통적 인 또 다른 주제는 오리너구리와 같은 것들인데, "포유류는 모두 이렇습니다"또는 "새는 모두 그런 식입니다"라는 간단한 규칙을 무시합니다.

결과적으로 직원의 기록을 처리하는 데 필요한 코드이지만 결국 거미류 또는 갑각류를 고용 한 경우 준비가되도록주의 깊게 작성되었습니다.

추상화는 끝의 수단이라는 것을 기억하는 것이 중요합니다. 추상화를 사용하여 프로그램 전체의 동작을 균일하게 만들고 새로운 클래스를 추가해야 할 경우에 추상화가 필요한 순간에만 새 클래스를 간단하게 추가 할 수 있습니다.

추상화 가 필요할 수도 있기 때문에 추상화를 추가하지 않을 것입니다 (실제로 새로운 클래스를 추가해야한다고 생각할 근거가 없음). 여기에 적절한 은유가 배관 일 수 있습니다. 바라건대 여러분은 물이 상하로 동 / 서, 북 / 남쪽으로 흐를 수 있도록하는 6 방향 파이프가 가장 유연한 유형의 파이프 일 것입니다. 이론적으로 파이프가 필요한 어디에서나 6 방향 파이프를 사용할 수 있으며 불필요한 방향을 차단할 수 있습니다.

싱크대 아래의 누수 문제를 해결하려고 시도하고 파이프의 모든 섹션이 6 방향 파이프 조각이라는 것을 발견했다면, 그런 식으로 디자인 한 사람에게 머리카락을 당황하게하십시오. 문제의 위치를 ​​알뿐만 아니라 적절한 방식으로 처음부터 시작하는 것이 훨씬 간단합니다.

물론 코딩 은 배관이 아니지만 은유는 여전히 유효합니다. 추상화는 6 방향 파이프 조각을 사용하는 것과 같습니다. 가까운 장래에 파이프를 6 방향에서 모두 연결해야 한다고 생각할 때 사용하십시오 . 그렇지 않으면 추상화는 단순히 복잡한 문제 일뿐, 패턴이 필요없는 패턴을 사용하거나 모든 것을 시도하는 신 클래스를 사용하는 것과 크게 다르지 않습니다. 사용되지 않고 사용되지 않을 경우 궁극적으로 추가 클래스를 추가하지 않습니다.

물론, 프로그램 작성 기술은 개념적으로 매우 추상적입니다. 추상화는 추상화를 위해 존재하지 않지만 실제로 는 실용적 이기 때문에 언급 할 가치가 있습니다. 추상화를 사용해야 할 필요가 있다고 생각 되더라도 그 후에 배관 점검을 요청하지 마십시오. ;)

몇 년 전 객체 지향 분석 및 디자인에 대해 배웠을 때 고객이 필요로하는 시스템에 대한 명확한 영어 설명으로 시작했습니다.

이를 통해 명사 (또는 명사구)는 가능한 클래스로 간주됩니다. 모든 동사 (또는 동사구)는 클래스에서 잠재적 인 메소드가됩니다. 따라서 "포장 로봇"은 클래스가 될 수 있습니다 BaggingRobot. "가방을여십시오"는 방법이 될 수 있습니다 OpenBag.

몇 번의 반복 후에 이것은 클래스 다이어그램으로 바뀔 것입니다.

현재 추상 클래스는 없습니다. 고객은 배깅 로봇의 추상적 개념을 원하지 않습니다. 그들은 물건을 가방에 넣는 로봇을 원합니다. 모든 클래스는 구체적이며 일련의 메소드가 있습니다.

추상 클래스는 다음과 같이 분명해질 때만 소개됩니다.

• 계층 구조를 형성 할 수있는 몇 가지 유사한 클래스가 있습니다.
• 기본 클래스가 유용한 목적을 수행 할 수 있도록 실제로 공통점을 공유합니다.

나에게 "조기 추상화"는 모든 로봇이 어떤 로봇 으로부터 상속 BaggingRobot 받아야 한다고 가정하고 BaseRobot있으며, 더 나쁜 BaseRobot것은 모든 로봇에 공통적 인 것이 무엇인지 알기 전에 일련의 방법을 개발하려고 시도하는 것입니다.

아직 존재하지 않는 문제를 해결하고 싶거나 클라이언트가 요청한 내용이 잘못되었다고 생각하지 않는 한, 그럴만한 이유가 없다고 생각합니다. 이 경우 추상 또는 기타 추측 솔루션을 구현하는 것보다 더 많은 커뮤니케이션을 권장합니다. 클래스 정의에 대해 "추상적 인"내용을 발표하고 나중에이를 확장 할 수 있다는 것을 알고 안전하다고 느끼는 것은 무해한 것처럼 보일 수 있지만, 필요하지 않거나 디자인을 지나치게 복잡하게 만드는 방식으로 자신을 확장시킬 수 있습니다. 잘못된 것을 추상화함으로써

예를 들어, 로봇 자체 , 포장 품목 또는 포장 방법 이 줄 을 바꿀 것이라고 상상 하십니까?

조기 추상화는 실제로 추상화를 수행 할 충분한 이유가 없음을 의미하며 추상화는 많은 언어에서 무료가 아니기 때문에 정당화없이 오버 헤드가 발생할 수 있습니다.

편집 의견에서 OP의 일부 요점에 답변하기 위해 점 (1)과 (2)를보다 구체적으로 다루는 동안 긴 설명 체인이 필요없는 방식으로 설명하고 응답하도록 업데이트하고 있습니다.

(1) 나에게 이것은 프로그래머가 실용적이지 않은 것처럼 들리지만 , 최종 프로그램에는 존재하지 않을 것이라고 가정하여 , 추상화 수준이 낮게 작업하고 있지만 문제는 아닙니다. 미숙 한 추상화, 미숙 한 구체화입니다.

(Emphasis mine). 최종 프로그램에 문제가 있다고 가정하면 정확히 귀하의 예에서 볼 수있는 것은 아닙니다. 고객이 품목 포장 로봇을 요청했습니다. 언어가 다소 모호한 경우 매우 구체적인 요청입니다. 고객이 물품을 포장하는 로봇을 원하므로 한 쌍의 물체를 생산합니다.

public class Item {
/* Relevant item attributes as specified by customer */
}

public class BaggingRobot {
  private Collection<Item> items;

  public void bag(Item item);
}

모델은 간단하고 정확하며 솔루션에 복잡성을 추가하지 않고 고객이 요구 한 것보다 더 많은 것을 원한다고 가정하지 않고 고객이 설정 한 요구 사항을 따릅니다. 이되게 할 때 로봇이 상호 교환 포기할 역학을 가지고 들어, 그들은 필요성을 명확히하는 경우에만 다음 당신은 지금 가리킨 수 있기 때문에 당신이 인터페이스 또는 추상의 다른 방법을 만드는 것이 타당 함을 보여주기 위해 충분한 정보를 가지고 할 특정 값 에 추가되는 추상화를 통한 시스템.

반대로, 순수한 실용주의로부터 추상화로 시작한다면 별도의 인터페이스를 만들고이를 구현하여 구현하거나 추상 클래스 또는 원하는 추상화 방법을 만드는 데 시간을 소비합니다. 고객이 이에 만족하고 추가 확장이 필요하지 않은 것으로 판명되면 시간과 자원을 낭비하고 /하거나 시스템에 오버 헤드와 복잡성을 도입하지 않아도됩니다.

(2)와 관련하여, 나는 중요한 것을 생략하는 것이 조기 추상화의 특징이 아니라는 데 동의합니다 . 추상화 여부에 관계없이 중요한 것을 생략 할 수 있으며, 추상화 체인에서 멀리 떨어져 있지 않다면 어느 쪽이든 분류하기가 어렵거나 쉽지 않습니다.

대신 , 추상화가 도메인 모델을 난독화할 위험이 있음을 의미하는 것으로 해석합니다. 잘못된 추상화는 도메인 모델 및 도메인 이해의 추가 성장에 큰 영향을 줄 수있는 관계를 생성하기 때문에 시스템을 추론하기가 매우 어려울 수 있습니다. 모델을 잘못된 토끼 구멍으로 내림으로써 추상화 되는 것 보다는 시스템 전체 에 대한 중요한 정보를 생략 할 위험이 있습니다.