프로그래밍은 솔루션을 개발하는 과정입니다.코드, 데이터, 함수 및 알고리즘의 견고한 구조 형태의 "라이브"동적 작업. 정의되지 않은 의미에서 엄격한 구문을 형성하는 절차입니다. 실제 문제는 알고리즘 화 측면에서 잘 알려진 큰 문제입니다. 원하는 솔루션을 얻으려면 문제를 정확한 구문 구조에 배치해야합니다.
OOP는이 고대 프로그래밍 개념을 깨기 위해 두 번 시도했지만, 고전적인 스타일의 데이터 코딩 및 알고리즘의 족쇄는 여전히 강력합니다.
레벨 및 자격
컴퓨팅은 컴퓨팅에서 시작되었지만정보 처리 분야로의 이동 가속화가 증가하는 속도는 아직 고전적 프로그래밍이 불가능 해지고 존재를 멈출만큼 충분히 높지 않습니다.
개발자가 주장하지 않고 고객이 실제 문제에 대한 실제 솔루션을 요구하지 않는 것도 객관적입니다. 양쪽 모두 사용 가능한 도구와 익숙한 기능에 의해 제한되는 것에 익숙합니다.
OOP 다형성의 형태, 코드 캡슐화의 개념 및 속성 (메소드)의 상속은 프로그래밍 분야에 있지만 해결되는 문제 분야에는 없습니다.
사례-도서관PHPOffice / PHPWord. 그것을 사용하려면 개발자의 자격이 필요하고 자신의 개체 시스템을 만들어야하지만 현재 수준의 고객 (고객 요구 사항)은 프로그래머가 자신의 개발로 재정의하는 사소한 구성입니다 (그렇지 않으면 요구 사항은 만족하십시오). 다음과 같은 상황 :
이 경우 라이브러리를 사용하는 것은 작업입니다.예를 들어, 졸업장이나 논문의 형식화는 표준에 따라 공식화되어야합니다. 고객은 자신의 요구 사항을 제시했고 프로그래머는 훨씬 더 나아갔습니다.
문서는 완전히 구문 분석되고 필요한 형식으로 어셈블되었으며 모든 중첩 수준의 테이블로 작업하고 셀을 병합 및 분할하고 모든 방향으로 인쇄했습니다.
다형성과 OOP
다형성에 대한 더 나은 정의는 객체 지향 프로그래밍 아이디어 개발의 역사를 참조하는 것보다 더 나은 정의는 없습니다. 실현되지 않은 본질적으로 지금까지.
각 저자는 OOP의 시작과 본질에 대한 자신의 개념을 가지고 있습니다. 모든 세심한 독자에게이 개념은 정확하고 객관적입니다. 그러나 오늘날까지 모든 사람들은 무조건적인 공리로 세 가지 입장만을 받아들입니다.
- 캡슐화;
- 다형성;
- 계승.
일부는 더 많은 것을 추가합니다 : 추상화, 그리고 대부분의 경우 이것은 OOP의 본질을 설명하기위한 기초로 사용됩니다.
따라서 OOP에 대한 의견은 다형성입니다. 한 가지를 설명하고, 다른 방식으로 구성되거나, 반대로 서로 다른 것을 설명하지만 4 개의 동일한 위치를 기반으로합니다.
민주적 시작은이 지역의 전형적인 것이 아닙니다정보 기술이지만 그럴만 한 이유가 있습니다. 같은 것에 대한 많은 의견의 조합과 공존은 실제 다형성이 작용하는 것입니다.
다형성의 인기있는 정의
OOP는 정보 기술 개발의 다음 단계입니다. 이것에 대해 논쟁하는 사람은 거의 없지만 기본 공리와 조항은 의미론 측면에서 너무 많이 다르기 때문에 전체 범위 밖에서 주목할 가치가 없습니다.
- 프로그래밍에서 다형성은 다양한 기본 형식 (데이터 유형)에 대해 동일한 인터페이스를 제공하는 기능입니다.
- 다형성은 객체가 다른 구현을 갖는 능력입니다.
- 다형성은 기능의 능력입니다 ...
- 클래식 (C / C ++ 제작자) : "하나의 인터페이스-많은 구현".
- 파라 메트릭 다형성은 ...
- 다형성-유형 이론의 위치 ...
- 캡슐화와 상속없이 추상화는 불가능합니다. 상속 없이는 다형성이 불가능한 것처럼 ...
우리는이 모든 것이 동일한 것을 의미한다는 데 동의 할 수 있습니다. 그러나 생각, 본질 및 내용의 표현 형태는 동일하지 않습니다. 그러나 여전히 공통점이 있습니다.
엔티티 : 개발자-고객
클래식 소프트웨어 개발에는프로그래머 및 작업 (클라이언트, 고객)의 가용성. 프로그래머는 문제를 조사하고 형식화 한 다음 솔루션으로 이어지는 코드를 만듭니다. 고객은 제안 된 모든 또는 일부만 거부하고 결함을 지적하고 프로그래머는 다시 작업을 수행합니다.
문제 해결 과정의 이러한주기는 완전히 다른 두 개체가 여기에 명확하게 결합되어 있음을 시사합니다.
- 컴퓨터는 스스로 문제를 해결할 수 없습니다.
- 컴퓨터가 문제를 "이해"하고 "해결"할 수있는 프로그램이 필요합니다.
과제는 고객의 역량 영역이며 프로그램은이것은 프로그래머의 능력 영역 인 컴퓨터의 능력에 대한 작업의 "적응"을위한 알고리즘입니다. 후자의 역할은 컴퓨터를 작업의 요구 사항에 "적응"하는 것이며 이것은 불필요합니다!
객체 지향 프로그래밍 제안 요약... 물체가 있습니다-이것은 고객의 영역입니다. 있다객체의 구현은 프로그래머의 도메인입니다. 고객과 개발자간에 "기술적"연결이 없습니다. 이 아이디어는 오늘날까지 구현되지 않은 기본이지만 이미 꾸준히 작동하고 있습니다.
창, 버튼 및 기타 개체
Air Art Technology의 역사, Object Magazine,Turbo Vision, Graph Vision은 이미 역사입니다. 이러한 OOP 구현을 기억하는 사람은 거의 없으며 실제로 사용되지도 잊혀지지 않지만 Windows 창 인터페이스는 수백만 명의 사용자에게 친숙하며 PHP, JavaScript 및 인터넷 기술의 기타 언어로 된 개체는 수십만 코드 개발자가 사용합니다. , 웹 리소스 방문자 수백만 명이 이에 대해 알고 있습니다.
이것은 아마도 유일한 올바른 방법 일 것입니다.개발자를위한 캡슐화, 상속, 다형성, 그러나 사용자를위한 것이 아닌 OOP를 개발해야했습니다. 이 위치가 Windows 소프트웨어의 시각적 디자인 (인터페이스) 개발, Turbo Vision 및 Graph Vision과 같은 응용 프로그램의 주요 역할이었던 것이 특징입니다.
같은 제품의 개념은Air Art Technology와 Object Magazine은 크게 달랐습니다. 여기서 추상 객체는 정보 구조의 첫 번째 조상으로서 추상 수준에서 정보 처리 코드를 캡슐화했습니다. 창, 버튼, 시각 디자인 요소는 여기에서 부차적이었습니다.
첫 번째 버전 (Windows 등)) OOP 패러다임 : 캡슐화, 상속, 다형성은 추상적 인 조상 수준에서 지정되었고, 코드의 구현은 원하는 구조와 내용에 따라 상속 분기를 따라 각 특정 자손 수준에서 형성되었습니다.
두 번째 버전 (Air Art Technology 및Object Magazine) 추상 객체의 수준이 중요합니다. 특정 후손이 가지는 것은 요점이 아닙니다. 중요한 것은 상속 분기가 루트 추상화에 이르기까지 모든 부모의 요구 사항을 충족한다는 것입니다.
객체 및 객체 시스템 : 알고리즘
이상적인 객체 지향 개념은 객체와 객체 시스템 만 조작 할 수 있습니다.
현대 프로그래밍 언어에서객체 (클래스)는 일반적으로 객체에 대한 설명과 객체의 인스턴스로 이해되며, 또한 객체에 대한 설명을 사용하기 위해 언어는 프로그래머가 정적 객체로 작업 할 수 있도록 허용하는 반면 동적 객체는 고유 한 내용과 구조를 가지고 있지만 동일한 메서드 (속성) 설명을 사용하는 설명의 인스턴스입니다.
현재 관행은 객체의 개념을 다음과 같이 분류합니다.도구, 즉 프로그래밍 언어, 인터페이스, 데이터베이스에 대한 액세스, 네트워크 연결이지만 고객의 관심사를 나타내는 것은 없으며 문제가 해결됩니다.
이것은 간단한 OOP에 이상적입니다.다형성을 통해 특히 다양한 디자인 요소를 수행 할 수 있지만 동일한 코드로 관리 할 수 있습니다. 그러나 여기서 우리는 객체 지향 분석의 주제로 전혀 간주되지 않는 문제의 대상에 대해 이야기하지 않습니다.
프로그래머는 OOP를 도구로 채택했습니다.작업의 품질과 생산성을 향상 시켰지만 고객에게 "그들의 영역"을 한 방울도 양보하지 않았습니다. OOP의 기본 개념 (캡슐화, 상속, 다형성)은 개발 분야에 남아 있었고 문제 분야로 이식되지 않았습니다.
개체 및 개체 시스템 : 문제 및 솔루션
컴퓨터-프로그래머-작업.중간 링크는 불필요합니다. 이상적으로는 상대적으로 의존적 인 두 개의 윤곽이 있어야합니다 : (컴퓨터-프로그래머)-작업. 즉, 사용자, 고객 또는 방문자는 자신의 문제를 해결할 수있는 도구가 있습니다. 고객은 도구가 구현되는 방식에 관심이 없습니다.
이상적으로는이 컴퓨터는고객이 원하는 것을 이해하고 원하는 것을 수행합니다. 어떻게 생겼을까 요? 브라우저를 통해 액세스 할 수있는 로컬 프로그램이나 웹 사이트, 분산 정보 처리를위한 특수 프로그램, 고객을위한 정보 시스템은 중요하지 않습니다.
작업과 컴퓨터 사이에불필요한 링크이지만 첫 번째는 두 번째로 이해되고 해결됩니다. 이 목표를 달성하기 위해서는 컴퓨터와 고객이 하나의 객체 시스템으로 연결되어야하며 각 객체의 의미, 구조 및 내용은 고객이 결정하고 객체의 방법과 속성은 프로그래머가 구현합니다.
고객의 업무가필요한 개체 시스템과 이러한 개체의 메서드 및 속성 구현에 대한 작업은 시간에 따라 분리됩니다. 객체 시스템 (프로그래머)의 구현이 시맨틱 콘텐츠 (고객)에서 멀수록 프로세스가 더 좋아집니다.
고객과 프로그래머를 방해하는 것은 없습니다문제를 해결하는 과정에서 상호 작용하지만 의미론의 명확한 분리가 중요합니다. 모든 사람은 자신의 일을해야하며 프로그래머는 작업의 범위를 마스터 할 의무가 없으며 고객은 코드를 이해해서는 안되며 더욱이 당사자는 서로 관련되지 않은 조언을 제공해서는 안됩니다.
전통 및 객체 프로그래밍
기본 OOP는 다음을 가정합니다.캡슐화, 상속, 다형성이 친숙하고 수요가 많은 형태로 코드의 품질과 신뢰성이 눈에 띄게 향상되고 프로그래머의 작업 속도가 크게 향상되며 다른 많은 긍정적 인 특성이 있습니다.
하지만 여전히 존재합니다. 고전적인 프로그래밍은 그 위치보다 열등하지 않으며 많은 객체 지향 아이디어가 고전적인 코드로 구현됩니다.
그러나 OOP 및 재귀의 아이디어는 적절한객체 지향 스타일의 작성 및 사고와 관련이없는 일반 코드를 작성하는 논리에 대한 고전적 구문 연산자의 구문에 영향을줍니다.
목록과 대기열이 변경되었으며 개념이있었습니다.첫 번째와 마지막 배열 요소, "for each"루프가 나타나고 이름 지정, 사용 및 실행의 참조 변형이 이전보다 훨씬 더 많이 요구되었습니다.
사실, 변수가 사라 졌다는 사실은"명확한"얼굴 (변수 유형은 필요에 따라 변경 될 수 있으며 변수를 설명 할 필요가 없음)은 사실 고전이 오랫동안 객체 지향적이었으며 OOP의 기본 원칙을 인식했다고 말합니다. 캡슐화 , 상속, 다형성이 필수적인 아이디어로.
핵심은 무엇인가 : 물체 또는 시스템
기본 개념적 위치로서의 추상화객체의 책임 (구현) 영역이 어디에 있든 상관없이 OOP는 첫 번째 추상 객체 수준 또는 특정 자손 수준에 관계없이 질문을 열어 둡니다. 모든 것을 시작할 위치, 객체에서 아니면 시스템에서?
객체를 기초로하면 절대시스템이 그 안에있을 것이기 때문에 시스템이 될 것이고, 그 자신은 매우 구체적인 시작의 딱딱한 이미지가 될 것입니다. 여기서 추상화로 인해 문제가 발생합니다. 초기 객체는 해결되는 문제의 주요 사항을 정확하게 수정합니다. 즉, 더 이상 다른 문제로 이전 할 수 없습니다.
객체 시스템을 기초로하면시스템 시스템이 확보됩니다. 특정 작업과 관련하여 상상하기 어렵고 개발을 시작하는 곳도 이해하기 어렵습니다. 대체로 엔티티, 구현 형태, 함수의 실제 매개 변수 수의 차이가있는 OOP 다형성은 대표 처음에있는 시스템에 대해 다음과 같습니다.
- 문제 해결 옵션 (예 : 메뉴)
- 초기 조건에 대해 (다른 조건, 데이터에서 문제 적용);
- 작동 모드 (테스트, 튜닝, 작업)에 대해.
그러나 이것 등은 문제 해결의 기초로 사물 시스템을 두어야 할 이유를 제공하지 않습니다. 단일 시작 개체를 정의하는 것으로 충분합니다.
문제 해결 과정의 역사
OOP의 가장 중요한 원칙 : 다형성과 추상화-객체 시스템으로서 초기 객체의 우선 순위를 지정합니다. 닭 이냐 계란이 먼저 냐에 대한 논쟁에서 닭이 이깁니다.
모든 것이객체 시스템이 아닌 추상 객체로 시작합니다. 그러나 시간의 요소를 고려하여 첫 번째 추상부터 시작하여 각 객체의 수준에 적용하면 솔루션의 시작 부분에 객체와 시스템을 모두 두는 모순 된 아이디어는 합리적입니다.
고전적인 프로그래밍 개념이문제를 해결하는 과정에서 데이터, 데이터베이스의 내용, 파일 등을 변경 한 다음 OOP 다형성의 개념, 캡슐화 및 시간 계수는 객체 시스템의 내용, 구조 및 속성을 변경합니다. 해결되는 문제.
OOP 프로그래머는파일, 데이터베이스, 알고리즘의 개념-이것들은 세부 사항입니다. 여기서 프로그래머는 객체에서 생각하지만 객체는 시간 내에 존재하고 원하는 것을 달성하는 과정에서 변경됩니다.
따라서 처음에는 시스템으로서의 객체가 있습니다.객체와이 시스템의 논리-시간 척도 : 작업 시작, 첫 번째 객체 형성, 데이터 입력 또는 수집, 다음 객체 형성, 그러나 첫 번째 객체가 다음 솔루션으로 진행하는 것을 방해하는 것은 없습니다.
각 수준의 개체는 다음과 같이 작동합니다.객체의 독립 시스템, 즉 하나의 객체이지만 시작된 프로세스와 시간의 가치와 관련하여 시간 척도의 객체 시스템입니다. OOP의 본격적인 구현을 위해 다형성, 상속 및 시간 요소가 함께 첫 번째의 역학을 제공합니다. 고객이 설계 한 프로세스 과정에서 작업 실행.
실제 OOP 다형성 예제
OOP가 할 수있는 작업의 복잡성은프로그램 작성의 고전적 버전과 비교할 수 있습니다. 물론 일반적인 방법으로 문제를 해결하는 것은 항상 가능하지만 시간과 노력이 얼마나 "비용"이 드는지에 대한 질문은 종종 결과를 쓸모 없게 만듭니다.
도서관은 최근에 개발되었습니다PHPOffice / PHPWord,하지만 그 기능을 사용하려면 거의 항상 자신 만의 개체 시스템을 만들어야합니다. 예를 들어, 간단한 * .docx 파일 :
많은 파일의 zip 아카이브이며Office Open XML 형식 (OpenXML, OOXML)의 폴더. 각 파일은 XML 태그로 작성되며 문자, 단어, 표, 목록 등의 요소가 추가, 변경되는 경우 파일의 내용은 항상 완전한 요소를 포함하지 않는 일련의 태그를 나타 내기 시작합니다. 종종 하나의 요소가 많은 태그로 작성됩니다.
이 파일을 일련의 태그로 상상하면 흥미로운 그림을 얻을 수 있습니다.
처음이자 유일한 단락이문서는 많은 태그로 표시됩니다. 테이블과 그 안에 내장 된 테이블의 경우 모든 요소에 대한 설명의 양은 눈에 띄지 않지만 객체 지향 응용 프로그램에서 사용할 수 있습니다.
실제로 그림에서 녹색은 테스트입니다.태그 출력, 노란색-매개 변수 및 태그 유형, 베이지 색-내용. 생성 된 객체는 기계 처리를 지향합니다. 사람의 경우 문서 파일 열기, 서식 지정 및 쓰기 작업 만 가능합니다.
솔루션은 간단하고 실용적이지만 수행되는 기능의 대부분과 개체 간의 복잡한 관계로 인해 구현이 사람보다 컴퓨터에 더 집중됩니다.
OOP 영역의 상태
사이트 관리 시스템, 기술 개발서버 설정 및 관리, 동적 사이트 개발 경험으로 모든 사람이 객체 지향 프로그래밍에 액세스 할 수있게되었습니다. 문제는 어떻게 생각을 바꾸고 순차적으로 실행되는 코드의 맥락이 아니라 객체 수준에서 생각하는 데 익숙해 지는가입니다.
일반적으로 클래식 프로그래밍에서 전환객체 지향에는 2 ~ 3 개월이 걸리지 만 비용은이자로 상환됩니다. 현대 프로그래밍 언어, 주로 PHP와 JavaScript의 잠재력은 가장 정교한 개발자를 만족시킬 것입니다.
현대 OOP-다형성, 상속 및객체의 속성을 형성 할 수있는 가능성은 편리하고 실용적이며 언어 구문 및 보조 도구는 작업의 편안함과 코드의 효율성을 제공합니다.
개체 아이디어 관점
클래식 프로그램은 얼마나 오래 지속됩니까?OOP가 어떻게 발전 할 것인지는 말하기 어렵습니다. 분명히 도구 개발자는 소비자 (사용자, 고객)의 컨텍스트를 고려할 계획이 없습니다.
OOP 툴킷 (다형성, 상속, 캡슐화 및 추상화)은 개발자 지향적입니다.
최신 정보 시스템 및 웹 리소스현실을 반영하고, 실제 물체의 기능을 보장하고, 기능을위한 환경을 만들기 위해 노력합니다. 프로그래밍과는 거리가 멀고 자신의 능력 영역에 완전히 몰입 한 소비자가 사용할 수있을 정도로 간단합니다.
