추상화 원리(컴퓨터 프로그래밍)

Abstraction principle (computer programming)

소프트웨어 공학 및 프로그래밍 언어 이론에설 때마다 실용적인(코드 중복에 강조와 자주)를 추상적으로 프로그래밍 언어나 소프트웨어 도서관 경우 일반인이 제공하게 사용함으로써 정보에 대한 프로그램에 중복을 줄이려는 목표를abstraction 원칙(추상화 또는 원칙)은 기본적인 의견이다.ation 해결을 필요하다.이 원리는 때때로 프로그래머에 대한 권고사항으로 언급되기도 하지만, 추상화를 사용하는 것이 바람직한 이유를 스스로 이해한다고 가정할 때 프로그래밍 언어의 요구사항으로 언급되기도 합니다.이 원칙의 기원은 불분명하다.그 원칙은 여러 번, 때로는 약간의 변형과 함께 다른 이름으로 재창조되었다.

프로그래머에 대한 권장사항으로 읽힐 때 추상화 원리는 "Don't repeat yourself"(DRY) 원리로 일반화할 수 있습니다.이는 일반적으로 정보의 중복을 피하고 소프트웨어 개발 프로세스에 관련된 인적 작업의 중복을 피할 것을 권장합니다.

원칙

Benjamin C의 공식에서 프로그래머에 대한 권고사항입니다. Pierce in Types and Programming Languages(2002), 추상화 원칙은 다음과 같습니다([1]원본에서는 강조).

프로그램의 각 중요한 기능은 소스 코드의 한 곳에서만 구현해야 합니다.유사한 기능이 다른 코드 조각에 의해 수행되는 경우, 일반적으로 다양한 부분을 추상화하여 하나로 결합하는 것이 유리합니다.

프로그래밍 언어의 요건으로서 David A에 의한 공식화.슈미트 유형 프로그래밍 언어의 구조(1994)에서 추상화 원리는 다음과 같습니다.[2]

의미론적으로 의미 있는 구문 클래스의 구문에 이름을 붙일 수 있습니다.

이력 및 변종류

바로 이 이름 아래 추상화 원리가 긴 책 목록에 나타난다.여기에서는 반드시 불완전한 목록을 제시합니다.간결할 경우 공식도 함께 제시합니다.

  • Alfred John Cole, Ronald Morrison(1982) S-algol을 사용한 프로그래밍 입문: "추상"은 언어 디자인에 적용될 때 의미론적으로 의미 있는 모든 구문 범주를 정의하고 그 범주의 [3]추상화를 가능하게 합니다.
  • Bruce J. MacLennan(1983) 프로그래밍 언어의 원리: 설계, 평가 및 구현: "여러 번 언급하는 것을 피하십시오.[4] 반복 패턴을 배제하십시오.
  • Jon Pearce(1998) Scheme의 프로그래밍과 메타 프로그래밍: "구조와 기능은 독립적이어야 합니다."[5]

이 원리는 객체 지향 프로그래밍에서 디자인 패턴의 중심 역할을 하지만, 이 주제에 대한 대부분의 글은 원리에 이름을 붙이지 않습니다.4인방의 영향력 있는 책은 "여기서 초점은 다양한 개념, 즉 많은 디자인 패턴의 주제를 캡슐화하는 것이다."라고 말한다.이 문장은 다른 저자에 의해 "변화하는 것을 찾아 [6]캡슐화하라"는 문구로 바뀌었습니다.

이번 세기에 이 원칙은 "Once and Only Once"라는 슬로건을 내걸고 익스트림 프로그래밍에서 재창조되었습니다.이 원칙의 정의는 첫 번째 출현에서 다소 간결했다: "중복 [7]코드 없음".소프트웨어 개발의 다른 문제에 적용할 수 있는 것으로 나중에 자세히 설명되었습니다. "자동화할 가치가 있는 모든 프로세스를 자동화하십시오.여러 번 작업을 수행하는 경우 스크립트를 [8]작성하십시오.

시사점

추상화 원리는 종종 추상화를 용이하게 하기 위해 의도된 일부 메커니즘의 맥락에서 언급된다.제어 추상화의 기본 메커니즘은 함수 또는 서브루틴입니다.데이터 추상화에는 다양한 형태의 다형이 포함됩니다.데이터와 제어 추상화를 조합할 수 있는 보다 정교한 메커니즘에는 클래스, 폴리타이피즘 등의 추상 데이터 유형이 있습니다.복잡한 시나리오에서 중복을 줄일 수 있는 보다 풍부한 추상화를 추구하는 것은 프로그래밍 언어 연구와 설계의 원동력 중 하나입니다.

경험이 부족한 프로그래머는 프로그램에 추상화를 너무 많이 도입하고 싶은 유혹을 느낄 수 있습니다.추상화는 한 [citation needed]번 이상 사용되지 않습니다.이 문제를 강조하는 보완 원칙은 "You Ann't Need It"이고, 더 일반적으로는 KISS 원칙이다.

코드는 보통 수정되기 때문에 추상화 원칙을 따를 경우 코드의 리팩터링이 필요할 수 있습니다.코드를 다시 작성하기 위한 노력은 일반적으로 추상화의 향후 예상 이점에 대해 상각되어야 합니다.이것을 지배하는 경험의 법칙은 마틴 파울러에 의해 고안되었고 3의 법칙으로 대중화 되었다.코드 조각이 두 번 이상 복사될 경우, 즉 3개 이상의 복사본을 가지게 될 경우 추상화해야 한다고 명시되어 있습니다.

일반화

"Don't repeat yourself" 또는 "DRY 원칙"은 다중 계층 아키텍처의 맥락에서 개발된 일반화입니다. 여기서 관련 코드는 필요에 따라 계층 간에 어느 정도 복제되며 일반적으로 다른 언어로 사용됩니다.실제적인 측면에서,[citation needed] 여기서 권장하는 것은 반복을 피하기 위해 코드 생성기나 데이터 변환과 같은 자동화된 도구에 의존하는 것입니다.

하드웨어 프로그래밍 인터페이스

코드 최적화 외에도, 프로그래밍에서 추상화 수준의 계층적/재귀적 의미는 "추상 수준"과 "추상 계층"이라고도 불리는 하드웨어 통신 계층 간의 인터페이스를 가리킵니다.이 경우 추상화 수준은 대부분의 경우 인터페이스와 동의어입니다.예를 들어 셸 코드와 상위 레벨과 하위 레벨 언어 간의 인터페이스를 조사할 때 추상화 수준은 운영체제명령어(C 등)에서 콜과 명령어를 등록하고 회선 레벨(어셈블리와 바이너리 등)로 변경됩니다.이 예에서는 추상화 수준 간의 경계 또는 인터페이스가 [9]스택입니다.

레퍼런스

  1. ^ Pierce, Benjamin (2002). Types and Programming Languages. MIT Press. p. 339. ISBN 0-262-16209-1.
  2. ^ 데이비드 A.Schmidt, 유형 프로그래밍 언어의 구조, MIT Press, 1994, ISBN 0-262-19349-3, 32페이지
  3. ^ Alfred John Cole, Ronald Morrison, S-algol 프로그래밍 소개, CUP Archive, 1982, ISBN 0-521-25001-3, 150페이지
  4. ^ Bruce J. MacLennan, 프로그래밍 언어의 원리: 설계, 평가 및 구현, Holt, Rinehart 및 Winston, 1983 페이지 53
  5. ^ Jon Pearce, 프로그래밍 및 메타 프로그래밍, Birkhauser, 1998, ISBN 0-387-98320-1, 페이지 40
  6. ^ Alan Shallay, James Trott 디자인 패턴 설명: 객체 지향 디자인에 대한 새로운 관점, Adison-Wesley, 2002, ISBN 0-201-71594-5, 페이지 115
  7. ^ Kent Beck, Extreme 프로그래밍 설명: 변화를 받아들이다, 제2판, Adison-Wesley, 2000, ISBN 0-201-61641-6, 페이지 61
  8. ^ 색채, 익스트림 프로그래밍 포켓 가이드, O'Reilly, 2003, ISBN 0-596-00485-0
  9. ^ Koziol, Shellcoders Handbook", Wiley, 2004, 페이지 10, ISBN 0-7645-4468-3