객체 지향 프로그래밍

Object-oriented programming
여기서 "객체 지향" 리다이렉트 합니다.객체 지향의 다른 의미는 객체 방향을 참조하십시오.
"객체 지향 프로그래밍 언어"는 여기서 리디렉션됩니다.객체 지향 프로그래밍 언어 목록은 객체 지향 프로그래밍 언어 목록을 참조하십시오.
프로그래밍 패러다임

OOP(object-oriented programming)는 "objects"의 개념에 기초한 프로그래밍 패러다임으로, 데이터와 코드는 필드 형태의 데이터(속성 또는 속성으로 알려져 있음)와 프로시저 형태의 코드(메서드로 알려져 있음)를 포함할 수 있습니다.

오브젝트의 일반적인 기능은 프로시저(또는 메서드)가 오브젝트에 연결되어 오브젝트의 데이터 필드에 액세스하여 수정할 수 있다는 것입니다.이 OOP 브랜드에는 보통 다음과 같은 특별한 이름이 있습니다.self현재 개체를 참조하는 데 사용됩니다.OOP에서 컴퓨터 프로그램은 서로 [1][2]상호작용하는 물체로 만들어 설계된다.OOP 언어는 다양하지만 가장 많이 사용되는 언어는 클래스 기반입니다. 즉, 객체는 클래스의 인스턴스이며 객체 유형도 결정됩니다.

가장 널리 사용되는 프로그래밍 언어(예: C++, Java, Python 등)의 대부분은 멀티패러다임이며 객체 지향 프로그래밍을 어느 정도 지원하며, 일반적으로 필수 절차 프로그래밍과 결합되어 있습니다.중요한 객체 지향 언어로는 Java, C++, C#, Python, R, PHP, Visual Basic 등이 있습니다.NET, JavaScript, Ruby, Perl, SIMSCRIPT, Objective-C, Dart, Swift, Scala, Kotlin, Common Lisp, MATLAB 및 Smalltalk.

역사

클래스의 UML 표기법.이 버튼 클래스에는 데이터 및 함수에 대한 변수가 있습니다.상속을 통해 하위 클래스를 버튼 클래스의 하위 집합으로 만들 수 있습니다.오브젝트는 클래스의 인스턴스입니다.

객체 지향 프로그래밍의 현대적인 의미에서 "객체"와 "지향"을 호출하는 용어는 1950년대 후반과 1960년대 초에 MIT에 처음 등장했다.인공지능 그룹의 환경에서 "개체"는 이미 1960년에 특성(속성)[3][4]을 가진 식별된 항목(LISP 원자)을 참조할 수 있었다.앨런 케이는 1966년 [5]LISP의 내부적 이해에 대한 그의 생각에 큰 영향을 미친 것을 나중에 인용했다.

저는 사물이 생물학적 셀이나 네트워크상의 개별 컴퓨터처럼 메시지로만 통신할 수 있다고 생각했습니다(메시지는 처음에 사용되었습니다.메시지를 프로그래밍 언어로 효율적으로 실행하는 방법을 알기 위해서는 시간이 걸렸습니다).

Alan Kay, [5]

또 다른 초기 MIT의 예는 1960-1961년에 Ivan Sutherland가 만든 Sketchpad이다. Sutherland는 Sketchpad에 대한 그의 논문에 기초한 1963년 기술 보고서의 용어집에서 "객체"와 "인스턴스"의 개념을 정의했지만 그래픽 [6]상호작용에 특화되어 있었다.또한 MIT ALGOL 버전 AED-0은 데이터 구조("플렉스")와 프로시저 간에 직접 연결을 확립하여 나중에 "메시지", "방법" 및 "구성원 기능"[7][8]으로 불리게 되었다.

Simula는 클래스 및 객체, 상속 및 동적 [9]바인딩과 같은 객체 지향 프로그래밍의 필수적인 부분을 오늘날 도입했습니다.객체 지향의 Simula 프로그래밍 언어는 화물 항구를 [9]통해 선박과 선박의 움직임을 연구하고 개선하기 위한 모델과 같은 물리적 모델링과 관련된 연구자들에 의해 주로 사용되었다.

1970년대에 스몰톡 프로그래밍 언어의 첫 번째 버전은 제록스 PARC에서 Alan Kay, Dan Ingalls 및 Adele Goldberg에 의해 개발되었습니다.Smalltalk-72는 프로그래밍 환경을 포함하고 동적으로 입력되었으며 처음에는 컴파일되지 않고 해석되었습니다.Smalltalk는 언어 수준에서 객체 방향을 적용하고 그래픽 개발 환경을 적용한 것으로 유명해졌다.스몰톡은 다양한 버전을 거쳤고 언어에 대한 관심이 커졌다.[10]Smalltalk는 Simula 67에서 소개된 아이디어에 영향을 받았지만 클래스를 동적으로 [11]만들고 수정할 수 있는 완전히 역동적인 시스템으로 설계되었다.

1970년대에 Smalltalk는 Lisp 머신을 통해 개발자들에게 소개된 객체 기반 기술을 통합하도록 Lisp 커뮤니티에 영향을 미쳤다.Lisp에 대한 다양한 확장(예를 들어 LOUPS 및 플레이버, 다중 상속 및 믹스인 도입)에 대한 실험은 결국 기능적 프로그래밍과 객체 지향 프로그래밍을 통합하고 메타 객체 프로토콜을 통해 확장을 허용하는 Common Lisp Object System으로 이어졌다.1980년대에는 메모리 내의 오브젝트에 대한 하드웨어 지원을 포함하는 프로세서 아키텍처를 설계하려는 시도가 몇 번 있었지만 성공하지 못했습니다.예를 들어 인텔 iAPX 432 및 Linn Smart Rekursiv 등이 있습니다.

1981년 Goldberg는 Byte Magazine 8월호를 편집하여 Smalltalk와 객체 지향 프로그래밍을 더 많은 독자들에게 소개했다.1986년, 컴퓨팅 머신 협회는 제1회 객체 지향 프로그래밍, 시스템, 언어 및 애플리케이션에 관한 회의(OOPSLA)를 개최했습니다.이 회의에는 예기치 않게 1,000명이 참가했습니다.1980년대 중반 ITT Inc.에서 Smalltalk를 사용하던 Brad Cox에 의해 Objective-C가 개발되었고, 박사논문에 Simula를 사용하던 Bjarne Strostrup은 결국 객체 지향 C++[10]를 만들기 위해 노력했다.1985년, 베르트랑 마이어는 또한 에펠 언어의 첫 번째 디자인을 만들었다.소프트웨어의 품질에 초점을 맞춘 Eiffel은 완전한 객체 지향 프로그래밍 언어이며 소프트웨어 라이프 사이클 전체를 지원하는 표기법입니다.Meyer는 객체 지향 소프트웨어 구축에서 소프트웨어 엔지니어링과 컴퓨터 과학에서 얻은 소수의 핵심 아이디어를 바탕으로 에펠 소프트웨어 개발 방법을 설명했습니다.에펠의 품질 초점에 필수적인 것은 방법과 언어 모두에 필수적인 마이어의 신뢰성 메커니즘인 Design by Contract입니다.

2002년부터 2018년까지의 TIOBE 프로그래밍 언어 인기 지수 그래프.2000년대에는 객체 지향의 Java(파란색)와 ProceduralC(검은색)가 1위를 다투었다.

1990년대 초중반에 객체 지향 프로그래밍은 기술을 지원하는 프로그래밍 언어가 널리 보급되면서 지배적인 프로그래밍 패러다임으로 발전했다.여기에는 Visual FoxPro 3.0,[12][13][14] C++[15] 및 Delphi가[citation needed] 포함됩니다.객체 지향 프로그래밍 기술에 크게 의존하는 그래픽 사용자 인터페이스의 인기가 높아짐에 따라 그 지배력은 더욱 강화되었습니다.밀접하게 관련된 동적 GUI 라이브러리와 OOP 언어의 예는 Smalltalk에 기반한 객체 지향 동적 메시지 확장인 Objective-C로 작성된 Mac OS X의 Cocoa 프레임워크에서 찾을 수 있습니다.OOP 툴킷은 또한 이벤트 구동 프로그래밍의 인기를 높였다(단, 이 개념은 OOP에 국한되지 않음).

ETH 취리히에서 Niklaus Wirth와 그의 동료들은 데이터 추상화 및 모듈러 프로그래밍과 같은 주제도 연구해 왔다.Modula-2(1978)는 두 가지를 모두 포함하였고, 후속 설계인 Oberon은 물체 방향, 클래스 등에 대한 독특한 접근법을 포함하였다.

객체 지향 기능은 Ada, BASIC, Fortran, Pascal 및 COBOL을 포함한 기존의 많은 언어에 추가되었습니다.이러한 기능을 당초 설계되어 있지 않은 언어에 추가하면, 코드의 호환성과 유지보수에 문제가 생기는 일이 자주 있습니다.

최근에는 주로 객체 지향적이면서도 절차적 방법론과 호환되는 언어들이 많이 등장했습니다.Python과 Ruby라는 두 가지 언어가 있습니다.아마도 최근에 가장 상업적으로 중요한 객체 지향 언어는 C#과 Visual Basic뿐만 아니라 Sun Microsystems에 의해 개발된 Java일 것입니다.NET(VB)NET)는, 모두 Microsoft 용으로 설계되어 있습니다.NET 플랫폼이 두 프레임워크 각각은 구현에서 추상화를 생성함으로써 OOP 사용의 이점을 나름대로 보여줍니다.VB.NET 및 C#은 언어 간 상속을 지원하므로 한 언어로 정의된 클래스에서 다른 언어로 정의된 하위 클래스까지 사용할 수 있습니다.

특징들

객체 지향 프로그래밍은 객체를 사용하지만 OOP를 지원한다고 주장하는 언어로 모든 관련 기술과 구조가 직접 지원되는 것은 아닙니다.오퍼랜드에 대한 연산을 수행합니다.다음 기능은 클래스 지향 및 객체 지향(또는 OOP 지원 멀티패러다임)으로 간주되는 언어에서 공통적으로 볼 수 있습니다.단,[16][17][18][19] 주목할 만한 예외가 있습니다.

다음 항목도 참조하십시오.프로그래밍 언어(객체 지향 프로그래밍)와 객체 지향 프로그래밍 용어 목록 비교

OOP 이외의 언어와 공유

모듈러 프로그래밍 지원을 통해 조직 목적으로 프로시저를 파일 및 모듈로 그룹화할 수 있습니다.모듈 이름이 지정되므로 한 모듈의 식별자가 다른 파일 또는 모듈에서 동일한 이름을 공유하는 프로시저 또는 변수와 충돌하지 않습니다.

오브젝트 및 클래스

OOP(개체 지향 프로그래밍)를 지원하는 언어는 일반적으로 코드 재사용 및 확장성을 위해 클래스 또는 프로토타입의 형태로 상속을 사용합니다.클래스를 사용하는 그룹은 다음 두 가지 주요 개념을 지원합니다.

  • 클래스 – 특정 유형 또는 객체의 클래스에 대한 데이터 형식 및 사용 가능한 프로시저의 정의. 데이터 및 프로시저(클래스 메서드라고 함) 자체를 포함할 수도 있습니다.즉, 클래스에는 데이터 멤버와 멤버 함수가 포함됩니다.
  • 오브젝트 – 클래스의 인스턴스

사물은 때때로 현실 세계에서 발견되는 사물과 일치한다.예를 들어, 그래픽 프로그램에는 "circle", "square", "menu" 등의 객체가 있을 수 있습니다.온라인 쇼핑 시스템에는 "쇼핑 카트", "고객" 및 "제품"[20]과 같은 개체가 있을 수 있습니다.열린 파일을 나타내는 객체나 측정값을 미국 관습에서 미터법으로 변환하는 서비스를 제공하는 객체와 같이 객체가 더 추상적인 엔티티를 나타낼 수 있습니다.

각 개체는 특정 클래스의 인스턴스라고 합니다(예를 들어 이름 필드가 "Mary"로 설정된 개체는 클래스 Employee의 인스턴스일 수 있습니다).오브젝트 지향 프로그래밍의 프로시저는 메서드라고 불리며 변수는 필드, 멤버, 속성이라고도 합니다.그 결과 다음과 같은 용어가 발생합니다.

  • 클래스 변수 – 클래스 전체에 속합니다.각각의 복사본은 1개뿐입니다.
  • 인스턴스 변수 또는 속성– 개개의 객체에 속하는 데이터.각 객체는 각각 독자적인 복사본을 가집니다.
  • 멤버 변수: 특정 클래스에 의해 정의되는 클래스 변수와 인스턴스 변수를 모두 나타냅니다.
  • 클래스 메서드– 클래스 전체에 속하며 프로시저 호출로부터의 클래스 변수 및 입력에만 액세스할 수 있습니다.
  • 인스턴스 메서드– 개개의 객체에 속하며 객체가 호출하는 특정 객체의 인스턴스 변수, 입력 변수 및 클래스 변수에 액세스할 수 있습니다.

오브젝트는 복잡한 내부 구조를 가진 변수처럼 접근되며, 많은 언어에서 효과적으로 포인터이며, 힙 또는 스택 내의 메모리 내의 해당 오브젝트의 단일 인스턴스에 대한 실제 참조 역할을 합니다.이들은 외부 코드와 내부 코드를 분리하는 데 사용할 수 있는 추상화 계층을 제공합니다.외부 코드는 특정 입력 매개 변수 집합을 사용하여 특정 인스턴스 메서드를 호출하거나 인스턴스 변수를 읽거나 인스턴스 변수에 쓰는 방법으로 개체를 사용할 수 있습니다.객체는 생성자로 알려진 클래스의 특수한 메서드 유형을 호출하여 생성됩니다.프로그램은 실행할 때 독립적으로 작동하는 동일한 클래스의 인스턴스를 많이 만들 수 있습니다.이 방법은 동일한 절차를 다른 데이터 세트에 쉽게 사용할 수 있는 방법입니다.

클래스를 사용하는 객체 지향 프로그래밍은 클래스 기반 프로그래밍이라고도 하지만 프로토타입 기반 프로그래밍은 일반적으로 클래스를 사용하지 않습니다.그 결과 개체와 인스턴스의 개념을 정의하기 위해 유의하게 다르지만 유사한 용어가 사용됩니다.

일부 언어에서는 특성 및 혼합과 같은 다른 개념을 사용하여 클래스 및 개체를 구성할 수 있습니다.

클래스 베이스와 프로토타입 베이스

클래스 기반 언어에서는 클래스를 미리 정의하고 클래스를 기반으로 개체를 인스턴스화합니다.2개의 오브젝트가 Fruit 클래스에서 인스턴스화된 경우 기본적으로 과일이므로 동일한 방법으로 처리할 수 있습니다.예를 들어 프로그래머는 color 또는 sugar_content, is_ripe 등의 동일한 속성이 존재할 것으로 예상할 수 있습니다.

프로토타입 기반 언어에서 개체는 기본 엔터티입니다.수업은 존재하지도 않는다.객체의 프로토타입은 객체가 연결된 다른 객체에 불과합니다.모든 오브젝트에는 하나의 프로토타입 링크(및1개만)가 있습니다.프로토타입으로 선택한 기존 개체를 기반으로 새 개체를 만들 수 있습니다.사과와 오렌지의 두 가지 다른 물체가 있다면 사과와 오렌지를 과일이라고 부를 수 있으며, 사과와 오렌지 모두 과일을 원형으로 가지고 있다.과일 클래스라는 개념은 명시적으로 존재하는 것이 아니라 동일한 프로토타입을 공유하는 객체의 동등성 클래스로 존재합니다.프로토타입의 속성 및 방법은 이 프로토타입에 의해 정의된 동등성 클래스의 모든 객체에 위임됩니다.객체가 개별적으로 소유한 속성 및 메서드는 동일한 등가 클래스의 다른 객체와 공유할 수 없습니다.예를 들어, sugar_content 속성이 예기치 않게 애플에 존재하지 않을 수 있습니다.프로토타입을 통해 구현할 수 있는 것은 단일 상속뿐입니다.

동적 디스패치/메시지 전달

메서드 호출에 응답하여 실행할 프로시저 코드를 선택하는 것은 객체의 책임이지 외부 코드가 아닙니다.일반적으로 오브젝트와 관련된 테이블에서 메서드를 선택하는 것은 외부 코드가 아닙니다.이 기능은 다이내믹디스패치라고 불립니다콜의 변동성이 콜된 오브젝트의 1종류 이상에 의존하고 있는 경우(즉, 적어도1개의 다른 파라미터 오브젝트가 메서드 선택에 관여하고 있는 경우), 복수의 디스패치에 대해 말할 수 있습니다.

메서드 콜은 메시지 전달이라고도 합니다.디스패치를 위해 오브젝트에 전달되는 메시지(메서드의 이름과 입력 파라미터)로 개념화됩니다.

데이터 추상화

Data Abstraction은 오용을 방지하기 위해 의미론적으로 관련된 함수에만 데이터를 표시하는 설계 패턴입니다.데이터 추상화의 성공은 객체 지향적이고 순수한 기능적 프로그래밍에서 설계 원리로 데이터를 숨기는 것을 빈번히 통합하게 합니다.

클래스에서 호출 코드가 내부 객체 데이터에 액세스하는 것을 허용하지 않고 메서드를 통해서만 액세스를 허용하는 경우, 이는 추상화 또는 추상화라고 알려진 정보의 강력한 형식입니다.일부 언어(Java 등)에서는 클래스가 액세스 제한을 명시적으로 강제할 수 있습니다.예를 들어, 내부 데이터는private키워드 및 지정 메서드는 클래스 밖에서 사용하는 것을 목적으로 하고 있습니다.public키워드를 지정합니다.방법은 다음과 같은 퍼블릭, 프라이빗 또는 중간 수준에서도 설계할 수 있습니다.protected(같은 클래스 및 그 서브클래스로부터의 액세스는 허용되지만 다른 클래스의 오브젝트는 허용되지 않습니다).다른 언어(Python 등)에서는 관례(예:private메서드는 밑줄로 시작하는 이름을 가질 수 있습니다).

캡슐화

캡슐화는 오브젝트의 내부 동작에 외부 코드가 관여하는 것을 방지합니다.이를 통해 코드 리팩터링이 쉬워집니다.예를 들어 클래스 작성자는 외부 코드를 변경하지 않고('퍼블릭' 메서드 호출이 동일한 방식으로 작동하는 한) 해당 클래스의 개체가 데이터를 내부적으로 표시하는 방법을 변경할 수 있습니다.또한 프로그래머들이 특정 데이터 세트에 관련된 모든 코드를 같은 클래스에 넣도록 장려하고, 다른 프로그래머들이 쉽게 이해할 수 있도록 정리합니다.캡슐화는 디커플링을 촉진하는 기술입니다.

구성, 상속 및 위임

오브젝트는 인스턴스 변수에 다른 오브젝트를 포함할 수 있습니다.이것을 오브젝트 합성이라고 합니다.예를 들어 Employee 클래스의 객체는 "first_name" 및 "position"과 같은 자체 인스턴스 변수와 더불어 주소 클래스의 객체를 직접 또는 포인터를 통해 포함할 수 있습니다.오브젝트 구성은 "has-a" 관계를 나타내기 위해 사용됩니다.즉, 모든 종업원은 주소를 가지고 있기 때문에 모든 종업원 오브젝트는 주소 오브젝트를 저장할 수 있는 장소(직접 내장된 장소 또는 포인터를 통해 주소 오브젝트)에 액세스 할 수 있습니다.

클래스를 지원하는 언어는 거의 항상 상속을 지원합니다.이를 통해 클래스를 "is-a-type" 관계를 나타내는 계층으로 정렬할 수 있습니다.예를 들어 Class Employee는 Class Person에서 상속할 수 있습니다.부모 클래스에서 사용할 수 있는 모든 데이터 및 메서드는 자식 클래스에도 동일한 이름으로 표시됩니다.예를 들어 클래스 Person은 변수 "first_name" 및 "last_name"을 메서드 "make_full_name()"으로 정의할 수 있습니다.이러한 항목은 "직급" 및 "월급" 변수를 추가할 수 있는 "직원" 클래스에서도 사용할 수 있습니다.이 기술을 사용하면 실제 관계를 직관적으로 미러링할 수 있을 뿐만 아니라 동일한 절차와 데이터 정의를 쉽게 재사용할 수 있습니다.개발자는 데이터베이스 테이블과 서브루틴 프로그래밍을 사용하는 대신 사용자에게 더 친숙한 오브젝트, 즉 [21]응용 프로그램 도메인의 오브젝트를 활용합니다.

서브클래스는 슈퍼클래스에서 정의된 메서드를 덮어쓸 수 있습니다.일부 언어에서는 다중 상속이 허용되지만, 이로 인해 재정의 해결이 복잡해질 수 있습니다.일부 언어는 mixin을 특별히 지원하지만 다중 상속이 있는 모든 언어에서 mixin은 단순히 is-a-type-of-relation을 나타내지 않는 클래스입니다.일반적으로 mixin은 여러 클래스에 동일한 메서드를 추가하기 위해 사용됩니다.예를 들어 UnicodeConversionMixin 클래스는 공통 부모를 공유하지 않는 FileReader 클래스와 WebPageScraper 클래스에 포함된 경우 Unicode_to_ascii() 메서드를 제공할 수 있습니다.

추상 클래스는 개체로 인스턴스화할 수 없습니다. 인스턴스화할 수 있는 다른 "구체" 클래스로 상속하기 위한 목적으로만 존재합니다.자바에서는final키워드를 사용하면 클래스의 서브클래스를 방지할 수 있습니다.

상속에 대한 구성 원칙은 상속 대신 구성을 사용한 관계를 시행하는 것을 옹호한다.예를 들어, 클래스 Employee는 클래스 Person에서 상속하는 대신 각 Employee 개체에 내부 Person 개체를 지정할 수 있습니다. 그러면 클래스 Person이 많은 공용 속성 또는 메서드를 가지고 있더라도 이 개체를 외부 코드로부터 숨길 수 있습니다.Go와 같은 일부 언어는 상속을 전혀 지원하지 않습니다.

"개방/폐쇄 원칙"은 클래스 및 기능이 "확장에는 개방되어야 하지만 수정에는 폐쇄되어야 한다"고 주장한다.

위임은 상속 대신 사용할 수 있는 또 다른 언어 기능입니다.

다형성

서브타이핑(다형성의 일종)은, 콜 코드가 서포트되고 있는 계층내의 어느 클래스(부모 클래스 또는 그 하위 클래스)로부터 독립할 수 있는 경우입니다.한편 상속 계층의 개체 간에 동일한 작업 이름이 다르게 작동할 수 있습니다.

예를 들어, 원과 정사각형 유형의 객체는 Shape라는 공통 클래스에서 파생됩니다.도형의 각 유형에 대한 그리기 함수는 자신을 그리는 데 필요한 기능을 구현하지만 호출 코드는 그리려는 특정 도형의 유형에 무관심할 수 있습니다.

이는 클래스 계층 외부의 코드를 단순화하고 관심사를 강력하게 분리할 수 있는 또 다른 유형의 추상화입니다.

개방 재귀

오픈 재귀를 지원하는 언어에서 오브젝트 메서드는 같은 오브젝트(자체 포함) 상의 다른 메서드를 호출할 수 있습니다.일반적으로 다음과 같은 특별한 변수 또는 키워드를 사용합니다.this또는self. 이 변수는 레이트바운드로, 한 클래스에서 정의된 메서드가 나중에 그 서브클래스에서 정의된 다른 메서드를 호출할 수 있습니다.

OOP 언어

다음 항목도 참조하십시오.객체 지향 프로그래밍 언어 목록

Simula(1967)는 일반적으로 객체 지향 언어의 주요 특징을 가진 최초의 언어로 받아들여진다.그것은 객체라고 불리는 것이 가장 중요한 정보 표현인 시뮬레이션 프로그램을 만들기 위해 만들어졌다.Smalltalk(1972~1980)는 OOP 이론의 많은 부분이 개발된 또 다른 초기 사례이다.물체의 방향 정도에 대해서는 다음과 같은 구별을 할 수 있다.

  • "순수한" OO 언어라고 불리는 언어는 문자 및 구두점과 같은 원어체에서 전체 클래스, 프로토타입, 블록, 모듈 등에 이르기까지 모든 언어가 하나의 개체로 일관되게 취급되기 때문입니다.이들은 특히 OO 방법을 용이하게 하고 시행하도록 설계되었습니다.예:루비, 스칼라, 스몰톡, 에펠, 에메랄드,[22] 제이드, 셀프, 라쿠.
  • 주로 OO 프로그래밍을 위해 설계된 언어이지만 일부 절차적 요소가 있습니다.예: Java, Python, C++, C#, Delphi/Object Pascal, VB.네트워크
  • 역사적으로 절차적 언어였지만 일부 OO 기능을 통해 확장된 언어입니다.예: PHP, Perl, Visual Basic(BASIC에서 파생), MATLAB, COBOL 2002, Fortran 2003, ABAP, Ada 95, Pascal.
  • 오브젝트의 기능(클래스, 메서드, 상속)의 대부분을 가지는 언어. 단, 완전히 원래의 형태입니다.예: Oberon(Oberon-1 또는 Oberon-2).
  • OO 프로그래밍과 유사하지만 객체 지향의 모든 기능이 없는 추상 데이터 유형을 지원하는 언어입니다.여기에는 객체 기반 언어 및 프로토타입 기반 언어가 포함됩니다.예: JavaScript, Lua, Modula-2, CLU.
  • OO를 포함한 여러 패러다임을 지원하는 카멜레온 언어.Tcl은 프로토타입 기반 프로그래밍과 클래스 기반 OO를 모두 지원하는 하이브리드 객체 시스템인 TclOO에서 두각을 나타내고 있습니다.

동적 언어의 OOP

최근 몇 년간 객체 지향 프로그래밍은 동적 프로그래밍 언어에서 특히 인기를 끌고 있습니다.Python, PowerShell, Ruby 및 Groovy는 OOP 원리에 기반한 동적 언어이며 Perl과 PHP는 Perl 5와 PHP 4 이후, ColdFusion은 버전 6 이후 객체 지향 기능을 추가해 왔습니다.

인터넷 상의 HTML, XHTML 및 XML 문서의 Document Object Model은 널리 사용되는 JavaScript/ECMAScript 언어에 바인딩되어 있습니다.JavaScript는 아마도 가장 잘 알려진 프로토타입 기반 프로그래밍 언어일 것입니다. 클래스(클래스 기반 프로그래밍과는 대조적으로)에서 상속되지 않고 프로토타입에서 복제를 사용합니다.이 접근방식을 채택하는 다른 스크립트 언어로는 Lua가 있습니다.

네트워크 프로토콜의 OOP

클라이언트 서버 환경에서 서비스를 요청하기 위해 컴퓨터 간에 흐르는 메시지는 클라이언트와 서버 모두에 알려진 클래스 개체에 의해 정의된 개체의 선형화로 설계할 수 있습니다.예를 들어 단순한 선형화된 개체는 길이 필드, 클래스를 식별하는 코드 포인트 및 데이터 값으로 구성됩니다.보다 복잡한 예로는 명령어의 길이와 코드 포인트로 구성된 명령어와 명령어의 파라미터를 나타내는 선형화된 개체로 구성된 값이 있습니다.이러한 각 명령어는 클래스(또는 슈퍼 클래스)가 명령을 인식하고 요청된 서비스를 제공할 수 있는 오브젝트에 서버에서 지시되어야 합니다.클라이언트와 서버는 복잡한 객체 지향 구조로 가장 잘 모델링됩니다.Distributed Data Management Architecture(DDM; 분산 데이터 관리 아키텍처)는 이 접근방식을 채택하여 클래스 개체를 사용하여 다음 4가지 수준의 정식 계층에서 개체를 정의했습니다.

  • 길이, 코드 포인트, 데이터 값 등 메시지를 형성하는 데이터 값을 정의하는 필드입니다.
  • 메시지 및 파라미터에 대한 Smalltalk 프로그램에서 발견되는 것과 유사한 오브젝트 및 오브젝트 컬렉션.
  • 메타데이터 및 레코드로 구성된 파일의 디렉토리 및 파일과 같은 IBM i Objects와 유사한 관리자.관리자는 포함된 개체에 대한 메모리와 처리 리소스를 개념적으로 제공합니다.
  • 디렉토리 서비스, 보안 및 동시성 제어 등의 측면을 지원하는 완전한 처리 환경을 구현하기 위해 필요한 모든 관리자로 구성된 클라이언트 또는 서버.

DDM 정의 분산 파일 서비스의 초기 버전입니다.이후 분산 관계형 데이터베이스 아키텍처(DRDA)의 기반으로 확장되었습니다.

설계 패턴

객체 지향 설계의 과제는 몇 가지 접근방식으로 해결됩니다.가장 일반적인 것은 감마 등에 의해 코드화된 설계 패턴으로 알려져 있다.보다 넓게는, 「설계 패턴」이라고 하는 용어는, 소프트웨어 설계에서 일반적으로 발생하는 문제에 대한 일반적인 반복 가능한 솔루션 패턴을 가리킬 수 있습니다.이러한 일반적인 문제 중 일부는 객체 지향 개발에 고유한 의미와 해결책을 가지고 있습니다.

상속 및 동작 서브타이핑

다음 항목도 참조하십시오.객체 지향 설계

상속이 의미론적인 "a" 관계를 만든다고 가정하는 것은 직관적이다. 따라서 하위 클래스에서 인스턴스화된 객체는 슈퍼 클래스에서 인스턴스화된 객체 대신 항상 안전하게 사용될 수 있다.대부분의 OOP 언어, 특히 가변 객체를 허용하는 모든 언어에서 이러한 직관은 안타깝게도 잘못된 것입니다.OOP 언어(변환 가능한 개체 포함)의 유형 검사기에 의해 적용되는 하위 유형 다형성은 어떤 컨텍스트에서도 동작적인 하위 유형을 보장할 수 없습니다.동작 서브타이핑은 일반적으로 결정할 수 없기 때문에 프로그램(컴파일러)에 의해 구현될 수 없습니다.구문적으로 검출할 수 없는 잘못된 용도를 고려하여 클래스 또는 객체 계층을 신중하게 설계해야 합니다.이 문제는 리스코프 대체 원리라고 불립니다.

4가지 디자인 패턴

주요 기사:설계 패턴(컴퓨터 과학)

설계 패턴: 재사용 가능한 객체 지향 소프트웨어의 요소(Elements of Reusable Object-Oriented Software)는 1994년 에리히 감마, 리처드 헬름, 랄프 존슨, 존 블리시데스에 의해 출판된 영향력 있는 책으로 종종 유머러스하게 "4대강"으로 불린다.오브젝트 지향 프로그래밍의 기능과 함정을 탐색하는 것과 함께, 이 문제를 해결하기 위한 23개의 일반적인 프로그래밍 문제와 패턴을 설명합니다.2007년 4월 현재 이 책은 36쇄에 들어갔다.

이 책에서는 다음과 같은 패턴을 설명하고 있습니다.

객체 지향 및 데이터베이스

주요 기사:객체-관계 임피던스 불일치, 객체-관계 매핑 및 객체 데이터베이스

객체 지향 프로그래밍과 RDBMS(Relational Database Management System)는 모두 오늘날 소프트웨어에서 매우 일반적입니다.릴레이셔널 데이터베이스는 오브젝트를 직접 저장하지 않기 때문에(일부 RDBMS에는 오브젝트 지향 기능이 있지만), 일반적으로 두 세계를 브리지할 필요가 있습니다.객체 지향 프로그래밍 액세스와 데이터 패턴을 관계형 데이터베이스와 브리징하는 문제는 객체-관계형 임피던스 미스매치로 알려져 있습니다.이 문제에 대처하는 방법에는 여러 가지가 있지만 [23]단점이 없는 일반적인 해결책은 없습니다.가장 일반적인 접근법 중 하나는 Visual FoxPro와 같은 IDE 언어 및 Java Data Objects 및 Ruby on Rails ActiveRecord와 같은 라이브러리에서 볼 수 있는 객체 관계 매핑입니다.

RDBMS를 대체하기 위해 사용할 수 있는 객체 데이터베이스도 있지만 RDBMS만큼 기술적으로나 상업적으로 성공을 거두지는 못했습니다.

실제 모델링 및 관계

OOP는 실제 객체 및 프로세스를 디지털 대응물과 관련짓기 위해 사용할 수 있습니다.그러나 OOP가 직접 현실 세계 매핑을 용이하게 한다는 점(비평 섹션 참조) 또는 현실 세계 매핑이 가치 있는 목표라는 점에는 모두가 동의하는 것은 아닙니다.Bertrand Meyer는 객체 지향 소프트웨어[24] 구축에서 프로그램은 세계의 모델이 아니라 세계의 일부의 모델입니다. "현실은 두 번 제거된 사촌입니다."라고 주장합니다.동시에 OOP의 몇 가지 주요 제한사항이 [25]지적되었다.예를 들어, 원-타원 문제는 OOP의 상속 개념을 사용하여 처리하기가 어렵다.

그러나 Niklaus Worth(현재는 Worth의 법칙으로 알려진 "소프트웨어는 하드웨어보다 더 빠르게 느려지고 있다"는 격언을 대중화한 사람)는 OOP에 대해 "이 패러다임은 '실제 세계'의 시스템 구조를 밀접하게 반영하고 있기 때문에 복잡한 시스템 w에 매우 적합하다"고 말했다.복잡한 행동"[26] (KISS 원칙 대비)

Steve Yegge와 다른 사람들은 자연어가 행동보다 사물(목적어/명사)[27]을 엄격하게 우선시하는 OOP 접근법이 부족하다고 지적했습니다.이 문제로 인해 OOP는 절차적 [28]프로그래밍보다 더 복잡한 솔루션을 겪을 수 있습니다.

OOP 및 제어 흐름

OOP는 소스 [29]코드의 재사용성과 유지보수성을 높이기 위해 개발되었습니다.제어 흐름의 투명한 표현은 우선순위가 없으며 컴파일러에 의해 처리되도록 되어 있습니다.병렬 하드웨어와 멀티스레드 코딩의 관련성이 높아짐에 따라 [30][31][32][33]OOP로 달성하기 어려운 투명한 제어 흐름을 개발하는 것이 더욱 중요해졌습니다.

데이터 중심 설계와 비교하여 책임감

책임 중심 설계는 계약 측면에서 분류를 정의한다. 즉, 분류는 책임과 그 분류가 공유하는 정보를 중심으로 정의되어야 한다.Wirfs-Brock 및 Wilkerson은 데이터 기반 설계를 통해 클래스가 유지되어야 하는 데이터 구조를 중심으로 정의됩니다.저자들은 책임 중심 설계가 더 바람직하다고 생각한다.

확실한 가이드라인과 파악 가이드라인

SOLID는 Michael Featurs가 개발한 니모닉으로 5가지 소프트웨어 엔지니어링 설계 원칙을 설명합니다.

CRAPP(General Responsibility Assignment Software Patterns)는 Craig Larman이 제창하는 또 다른 가이드라인 세트입니다.

비판

OOP 패러다임은 재사용성과 모듈화라는 [34][35]정해진 목표를 달성하지 못하고, 소프트웨어 설계와 모델링(데이터/객체)의 한 측면을 지나치게 강조하여 다른 중요한 측면(계산/알고리즘)[36][37]을 희생시키는 등 여러 가지 이유로 비판을 받아왔다.

Luca Cardelli는 OOP 코드가 프로시저 코드보다 "내부적으로 덜 효율적이며" OOP가 컴파일하는 데 시간이 오래 걸릴 수 있으며 OOP 언어는 "클래스 확장과 수정에 관해 극도로 열악한 모듈러 특성"을 가지고 있으며 매우 [34]복잡한 경향이 있다고 주장했다.후자의 요점은 Erlang의 주요 발명가인 Joe Armstrong에 의해 재차 강조되고 있습니다.[35]그는 다음과 같이 말하고 있습니다.

오브젝트 지향 언어의 문제는 암묵적인 환경을 가지고 있다는 것입니다.바나나를 원했지만 고릴라가 바나나를 들고 정글 전체를 들고 있었다.

포토크 등의 연구.님은 OOP와 [38]절차적 접근법 사이에 생산성에 큰 차이가 없는 것으로 나타났습니다.

Christopher J. Date는 OOP에 [39]대해 합의된 엄격한 정의가 없기 때문에 OOP와 다른 테크놀로지의 중요한 비교는 어렵다고 말했습니다.그러나 Date와 Darwen은 OOP를 RDBMS를 [40]지원하는 일종의 맞춤형 시스템으로서 사용하는 OOP에 대한 이론적 기반을 제안했습니다.

Lawrence Krubner는 다른 언어(LISP 방언, 기능 언어 등)와 비교하여 다음과 같이 주장했다.OOP 언어는 고유한 강점이 없으며 불필요한 [41]복잡성에 큰 부담을 줍니다.

Alexander Stephanov는 객체 방향을 일반 프로그래밍과 [36]비교합니다.

OOP는 기술적으로 타당하지 않습니다.단일 유형에 따라 다른 인터페이스의 관점에서 월드 분해를 시도합니다.실제 문제에 대처하려면 여러 유형에 걸친 인터페이스 패밀리인 멀티소트 대수가 필요합니다.나는 OOP가 철학적으로 타당하지 않다고 생각한다.그것은 모든 것이 물체라고 주장한다.그것이 사실이라고 해도, 모든 것이 물건이라고 말하는 것은 전혀 말이 되지 않는다.

Paul Graham은 대기업에서 OOP의 인기는 "중용한 프로그래머들로 구성된 대규모 그룹(그리고 자주 변화)"에 기인한다고 주장했습니다.Graham에 따르면 OOP에 의해 부과된 규율은 프로그래머 한 명이 "너무 많은 피해를 주는"[42] 것을 막는다.

Leo Brodie는 오브젝트의 독립형 특성과 소프트웨어 개발의 반복하지[44] 않는 원칙을 위반하여 코드를 복제하는[43] 경향 사이의 연관성을 제안했습니다.

Steve Yegge는 기능 [45]프로그래밍과는 달리 다음과 같은 점에 주목했습니다.

객체 지향 프로그래밍은 명사를 최우선으로 합니다.왜 당신은 연설의 한 부분을 떠받들려고 그렇게 멀리까지 가십니까?왜 어떤 개념이 다른 개념보다 우선해야 하는가?OOP가 갑자기 우리가 실제로 생각하는 방식에서 동사를 덜 중요하게 만든 것은 아니다.이상하게 비뚤어진 관점이네요

Clojure를 만든 Rich Hickey는 객체 시스템을 지나치게 단순한 현실 세계의 모델이라고 묘사했다.그는 OOP가 시간을 적절하게 모델링할 수 없다는 점을 강조했습니다.소프트웨어 시스템의 [37]동시화가 진행됨에 따라 이는 점점 더 문제가 되고 있습니다.

Unix 프로그래머이자 오픈 소스 소프트웨어 옹호자인 Eric S. Raymond는 객체 지향 프로그래밍을 "One True Solution"으로 제시하는 주장에 대해 비판적이며 객체 지향 프로그래밍 언어는 투명성을 [46]파괴하는 두꺼운 계층형 프로그램을 장려하는 경향이 있다고 썼습니다.Raymond는 이를 Unix 및 C 프로그래밍 [46]언어로 채택한 접근법에 비해 불리하게 비교합니다.

UTF-8과 Go의 작성에 관여하고 있는 프로그래머 Rob Pike는 객체 지향 프로그래밍을 [47]"컴퓨팅의 로마 숫자"라고 부르며 OOP 언어는 데이터 구조나 알고리즘에서 [48]유형으로 초점을 전환하는 경우가 많다고 말합니다.게다가 그는 단순히 룩업 [49]테이블을 사용하는 것이 아니라 6개의 새로운 클래스를 만드는 것이 문제에 대한 "이성적인" 해결책이었던 Java 교수의 예를 들었다.

Bob Martin은 상속과 관련하여 소프트웨어이기 때문에 관련 클래스가 반드시 그들이 [50]나타내는 것의 관계를 공유하는 것은 아니라고 말합니다.

형식 의미론

다음 항목도 참조하십시오.프로그래밍 언어의 형식적 의미론

개체는 개체 지향 시스템에서 런타임 엔터티입니다.개인, 장소, 은행 계좌, 데이터 테이블 또는 프로그램이 처리해야 하는 항목을 나타낼 수 있습니다.

객체 지향 프로그래밍에서 사용되는 개념을 공식화하려는 시도가 여러 번 있었습니다.OOP 개념의 해석에는 다음과 같은 개념과 구조가 사용되었습니다.

오브젝트의 배후에 있는 컨센서스 정의나 이론을 찾으려는 시도는 그다지 성공적이지 않았으며(다만, 많은 OOP의 개념과 구조에 대한 공식적인 정의는[52] A Badi & Cardelli, 객체 이론 참조), 종종 크게 엇갈린다.예를 들어, 어떤 정의는 정신 활동에 초점을 맞추고, 어떤 정의는 프로그램 구성에 초점을 맞춘다.가장 간단한 정의 중 하나는 OOP가 통사적이고 범위 지정 설탕이 위에 있는 다른 지도에 대한 함수와 포인터를 포함할 수 있는 "지도" 데이터 구조 또는 배열을 사용하는 행위라는 것입니다.상속은 지도를 복제하여 수행할 수 있습니다("프로토타이핑"이라고도 함).

「 」를 참조해 주세요.

시스템들

모델링 언어

레퍼런스

  1. ^ Kindler, E.; Krivy, I. (2011). "Object-Oriented Simulation of systems with sophisticated control". International Journal of General Systems: 313–343. {{cite journal}}:Cite 저널 요구 사항 journal=(도움말)
  2. ^ 섹션 1.6 "개체 지향 프로그래밍Lewis, John; Loftus, William (2008). Java Software Solutions Foundations of Programming Design 6th ed. Pearson Education Inc. ISBN 978-0-321-53205-3."
  3. ^ McCarthy, J.; Brayton, R.; Edwards, D.; Fox, P.; Hodes, L.; Luckham, D.; Maling, K.; Park, D.; Russell, S. (March 1960). "LISP I Programmers Manual" (PDF). Boston, Massachusetts: Artificial Intelligence Group, M.I.T. Computation Center and Research Laboratory: 88f. Archived from the original (PDF) on 17 July 2010. In the local M.I.T. patois, association lists [of atomic symbols] are also referred to as "property lists", and atomic symbols are sometimes called "objects". {{cite journal}}:Cite 저널 요구 사항 journal=(도움말)
  4. ^ McCarthy, John; Abrahams, Paul W.; Edwards, Daniel J.; Hart, swapnil d.; Levin, Michael I. (1962). LISP 1.5 Programmer's Manual. MIT Press. p. 105. ISBN 978-0-262-13011-0. Object — a synonym for atomic symbol
  5. ^ a b "Dr. Alan Kay on the Meaning of "Object-Oriented Programming"". 2003. Retrieved 11 February 2010.
  6. ^ Sutherland, I. E. (30 January 1963). "Sketchpad: A Man-Machine Graphical Communication System". Technical Report No. 296, Lincoln Laboratory, Massachusetts Institute of Technology via Defense Technical Information Center (stinet.dtic.mil). Archived from the original on 8 April 2013. Retrieved 17 July 2019.
  7. ^ 시뮬라 언어의 발전, Kristen Nygaard, Ole-Johan Dahl, 페이지 254 Uni-kl.ac.at
  8. ^ Ross, Doug. "The first software engineering language". LCS/AI Lab Timeline. MIT Computer Science and Artificial Intelligence Laboratory. Retrieved 13 May 2010.
  9. ^ a b Holmevik, Jan Rune (1994). "Compiling Simula: A historical study of technological genesis" (PDF). IEEE Annals of the History of Computing. 16 (4): 25–37. doi:10.1109/85.329756. S2CID 18148999. Archived from the original (PDF) on 30 August 2017. Retrieved 3 March 2018.
  10. ^ a b Bertrand Meyer (2009). Touch of Class: Learning to Program Well with Objects and Contracts. Springer Science & Business Media. p. 329. Bibcode:2009tclp.book.....M. ISBN 978-3-540-92144-8.
  11. ^ Kay, Alan. "The Early History of Smalltalk". Archived from the original on 10 July 2008. Retrieved 13 September 2007.
  12. ^ 1995년 (6월) Visual FoxPro 3.0, FoxPro는 절차적 언어에서 객체 지향 언어로 진화합니다.Visual FoxPro 3.0에는 데이터베이스 컨테이너, 심리스 클라이언트/서버 기능, ActiveX 테크놀로지 지원, OLE Automation 및 늘 지원이 도입되었습니다.폭스 릴리즈의 개요
  13. ^ FoxPro History 웹 사이트:Foxprohistory.org
  14. ^ 1995 Visual FoxPro 3.0 리뷰어 가이드:DFpug.de
  15. ^ Khurana, Rohit (1 November 2009). Object Oriented Programming with C++, 1E. ISBN 978-81-259-2532-3.
  16. ^ 데보라 암스트롱객체 지향 개발의 쿼크.OOP의 대부분의 정의에서 발견된 많은 기본 개념을 인기 순서대로 확인한 거의 40년간의 컴퓨터 문헌에 대한 조사:상속, 객체, 클래스, 캡슐화, 메서드, 메시지 전달, 다형성 및 추상화.
  17. ^ John C. Mitchell, 프로그래밍 언어 개념, 캠브리지 대학 출판부, 2003, ISBN 0-521-78098-5, 페이지 278.리스트:동적 디스패치, 추상화, 서브타입 다형성 및 상속.
  18. ^ Michael Lee Scott, Programming Language Pragmatics, Edition 2, Morgan Kaufmann, 2006, ISBN 0-12-633951-1, 페이지 470. 캡슐화, 상속 및 동적 디스패치 목록.
  19. ^ 섹션 18.1 Pierce, Benjamin (2002). Types and Programming Languages. MIT Press. ISBN 978-0-262-16209-8."오브젝트 지향 프로그래밍이란?"리스트:동적 디스패치, 캡슐화 또는 멀티메서드(복수 디스패치), 서브타입의 다형성, 상속 또는 위임, 오픈 재귀('this'/'self')
  20. ^ Booch, Grady (1986). Software Engineering with Ada. Addison Wesley. p. 220. ISBN 978-0-8053-0608-8. Perhaps the greatest strength of an object-oriented approach to development is that it offers a mechanism that captures a model of the real world.
  21. ^ Jacobsen, Ivar; Magnus Christerson; Patrik Jonsson; Gunnar Overgaard (1992). Object Oriented Software Engineering. Addison-Wesley ACM Press. pp. 43–69. ISBN 978-0-201-54435-0.
  22. ^ "The Emerald Programming Language". 26 February 2011.
  23. ^ Neward, Ted (26 June 2006). "The Vietnam of Computer Science". Interoperability Happens. Archived from the original on 4 July 2006. Retrieved 2 June 2010.
  24. ^ 마이어, 제2판, 230페이지
  25. ^ M.Trofimov, OOP – 세 번째 "O" 솔루션: OOP를 엽니다.퍼스트 클래스, OMG, 1993, 제3권, 제3호, 페이지 14.
  26. ^ Wirth, Nicklaus (2006). "Good Ideas, Through the Looking Glass" (PDF). Computer. 39 (1): 28–39. doi:10.1109/mc.2006.20. S2CID 6582369. Archived from the original (PDF) on 12 October 2016. Retrieved 2 October 2016.
  27. ^ Yegge, Steve (30 March 2006). "Execution in the Kingdom of Nouns". steve-yegge.blogspot.com. Retrieved 3 July 2010.
  28. ^ Boronczyk, Timothy (11 June 2009). "What's Wrong with OOP". zaemis.blogspot.com. Retrieved 3 July 2010.
  29. ^ Ambler, Scott (1 January 1998). "A Realistic Look at Object-Oriented Reuse". drdobbs.com. Retrieved 4 July 2010.
  30. ^ Shelly, Asaf (22 August 2008). "Flaws of Object Oriented Modeling". Intel Software Network. Retrieved 4 July 2010.
  31. ^ James, Justin (1 October 2007). "Multithreading is a verb not a noun". techrepublic.com. Archived from the original on 10 October 2007. Retrieved 4 July 2010.
  32. ^ Shelly, Asaf (22 August 2008). "HOW TO: Multicore Programming (Multiprocessing) Visual C++ Class Design Guidelines, Member Functions". support.microsoft.com. Retrieved 4 July 2010.
  33. ^ Robert Harper (17 April 2011). "Some thoughts on teaching FP". Existential Type Blog. Retrieved 5 December 2011.
  34. ^ a b Cardelli, Luca (1996). "Bad Engineering Properties of Object-Oriented Languages". ACM Comput. Surv. 28 (4es): 150–es. doi:10.1145/242224.242415. ISSN 0360-0300. S2CID 12105785. Retrieved 21 April 2010.
  35. ^ a b 암스트롱, 조In Coders at Work: 프로그래밍 기술에 대한 성찰.피터 세이벨, EDCodersatwork.com 2010년 3월 5일 Wayback Machine에서 아카이브 완료, 2009년 11월 13일에 액세스.
  36. ^ a b Stepanov, Alexander. "STLport: An Interview with A. Stepanov". Retrieved 21 April 2010.
  37. ^ a b 리치 히키, JVM Languages Summit 2009의 기조연설은 아직입니까?2009년 11월
  38. ^ Potok, Thomas; Mladen Vouk; Andy Rindos (1999). "Productivity Analysis of Object-Oriented Software Developed in a Commercial Environment" (PDF). Software: Practice and Experience. 29 (10): 833–847. doi:10.1002/(SICI)1097-024X(199908)29:10<833::AID-SPE258>3.0.CO;2-P. S2CID 57865731. Retrieved 21 April 2010.
  39. ^ C. J. Date, 데이터베이스 시스템 개요, 650페이지
  40. ^ C. J. 데이트, 휴 다웬미래 데이터베이스 시스템 기반: 제3선언 (제2판)
  41. ^ Krubner, Lawrence. "Object Oriented Programming is an expensive disaster which must end". smashcompany.com. Archived from the original on 14 October 2014. Retrieved 14 October 2014.
  42. ^ Graham, Paul. "Why ARC isn't especially Object-Oriented". PaulGraham.com. Retrieved 13 November 2009.
  43. ^ Brodie, Leo (1984). Thinking Forth (PDF). pp. 92–93. Retrieved 4 May 2018.
  44. ^ Hunt, Andrew. "Don't Repeat Yourself". Category Extreme Programming. Retrieved 4 May 2018.
  45. ^ "Stevey's Blog Rants: Execution in the Kingdom of Nouns". Retrieved 20 May 2020.
  46. ^ a b Eric S. Raymond (2003). "The Art of Unix Programming: Unix and Object-Oriented Languages". Retrieved 6 August 2014.
  47. ^ Pike, Rob (2 March 2004). "[9fans] Re: Threads: Sewing badges of honor onto a Kernel". comp.os.plan9 (Mailing list). Retrieved 17 November 2016.
  48. ^ Pike, Rob (25 June 2012). "Less is exponentially more". Retrieved 1 October 2016.
  49. ^ Pike, Rob (14 November 2012). "A few years ago I saw this page". Archived from the original on 14 August 2018. Retrieved 1 October 2016.
  50. ^ "Uncle Bob SOLID principles". YouTube.
  51. ^ Poll, Erik. "Subtyping and Inheritance for Categorical Datatypes" (PDF). Retrieved 5 June 2011.
  52. ^ a b Abadi, Martin; Cardelli, Luca (1996). A Theory of Objects. Springer-Verlag New York, Inc. ISBN 978-0-387-94775-4. Retrieved 21 April 2010.

추가 정보

외부 링크

Wiki 인용문에는 객체 지향과 관련된 인용문이 있습니다.
Wikdiversity는 객체 지향 프로그래밍에 대한 학습 리소스를 보유하고 있습니다.
Wikibooks는 다음과 같은 주제에 관한 책을 가지고 있습니다.