앨런 케이는 스몰 토크 초기 역사에서“할당”이란 무엇을 의미 했는가?

나는 스몰 토크의 초기 역사를 읽었 으며 그 의미에 대한 나의 이해에 의문을 갖게하는 "할당"에 대한 몇 가지 언급이있다.

OOP는 많은 동기에서 비롯되었지만 두 가지가 중심이었습니다. 대규모는 세부 사항 숨기기와 관련된 복잡한 시스템을위한 더 나은 모듈 체계를 찾고 소규모는보다 유연한 할당 버전을 찾은 다음이를 완전히 제거하려고했습니다.

( 1960-66 년 ~ 60 년대 초반의 OOP 및 기타 형성 아이디어 , 섹션 I)

내가 Simula에서 얻은 것은 이제 바인딩과 과제를 목표로 바꿀 수 있다는 것 입니다. 프로그래머가 마지막으로 원했던 것은 비 유적으로 제시 되어도 내부 상태를 망쳐 놓는 것입니다. 대신, 객체는 동적 구성 요소로 사용하기에 더 적합한 상위 수준의 동작 사이트 로 제공되어야합니다 . (...) 오늘날 "개체 지향 프로그래밍 (object-oriented programming)"이라고 불리는 것의 상당수가 단순히 더 멋진 구조를 가진 구식 프로그래밍이라는 것은 불행한 일입니다. 많은 프로그램이 이제 더 비싼 첨부 프로 시저에 의해 수행되는 "할당 스타일"작업으로로드됩니다.

( "객체 지향"스타일 , 섹션 IV에서)

객체가 façades이고 객체에 인스턴스 변수를 설정하는 (즉, "assignment") 목적을 가진 메소드 (또는 "메시지")가 목적을 무력화하려는 의도로 해석하는 것이 맞습니까? 이 해석은 IV 절의 두 가지 후반 진술에 의해 뒷받침되는 것으로 보인다.

지속성 상태, 다형성, 인스턴스화 및 객체에 대한 목표와 같은 방법으로 함께 사용되는 네 가지 기술이 많은 힘을 설명합니다. 이 중 어느 것도 "개체 지향 언어"를 사용하지 않아도됩니다. ALGOL 68은 거의이 스타일로 바꿀 수 있습니다. OOPL은 디자이너의 마음을 특정 방향으로 집중시킵니다. 그러나 캡슐화 권한을 수행하는 것은 상태의 추상화뿐만 아니라 프로그래밍에서 상태 지향적 은유를 제거하기위한 약속입니다.

...과:

과제 진술 (추상적 인 진술조차도)은 매우 낮은 수준의 목표를 표현하며, 그 중 더 많은 것이 목표 달성을 위해 필요합니다. 일반적으로, 우리는 프로그래머가 시뮬레이션 여부에 상관없이 상태를 망칠 것을 원하지 않습니다.

불투명하고 불변 인 인스턴스가 여기에서 권장되고 있다고 말할 수 있습니까? 아니면 낙담 한 직접적인 상태 변화입니까? 나는이있는 경우 예를 들어, BankAccount클래스를, 그것의 확인을해야합니다 GetBalance, Deposit그리고 Withdraw인스턴스 메소드 / 메시지; SetBalance인스턴스 메소드 / 메시지 가 없는지 확인하십시오 .

기본 개념 (Sketchpad에 의해 영향을 받음)은 대부분의 변수 / 값이 (객체 내부에서 유지 관리되는) 서로 동적 인 관계에 있기 때문에 외부에서 직접 값을 재설정 할 수있는 것은 위험합니다. (어쨌든 스몰 토크에서) 적어도 세터 방법이 요구되기 때문에, 이는 원하는 설정과의 관련성을 유지하기 위해 내부 설정에 의해 외부 설정 동작이 중재 될 가능성을 허용한다. 그러나 세터를 사용하는 대부분의 사람들은 단순히 변수를 사용하여 내부 변수에 대한 직접 할당을 시뮬레이션하기 때문에 실제 OOP의 정신과 의도를 위반합니다.

그러나 객체는 시간에 "월드 라인"변화가 있습니다. 이것은 관계가 일치하는 객체의 역사 버전으로 생각할 수 있습니다. 이 체계에는 경쟁 조건이 없습니다. 객체는 안정적이고 더 이상 컴퓨팅되지 않을 때만 볼 수 있습니다. 이것은 HW의 2 상 클럭과 같습니다. (Strachey의 아이디어, McCarthy와 다른 아이디어이며 Lucid의 영향을받습니다.)

최고의 소원,

앨런 케이

Alan이이 질문에 이미 답변 했으므로 답장을 보내지 않는 것 같습니다. 그러나 Alan은 귀하가 가진 모든 질문에 답변하지 않았습니다.

특히:

불투명하고 불변 인 인스턴스가 여기에서 권장되고 있다고 말할 수 있습니까? 아니면 낙담 한 직접적인 상태 변화입니까? 예를 들어, BankAccount 클래스가 있다면 GetBalance, Deposit 및 Withdraw 인스턴스 메소드 / 메시지를 갖는 것이 좋습니다. SetBalance 인스턴스 메소드 / 메시지가 없는지 확인하십시오.

여기서 대답은 프로그램을 구성하기 위해 고차 행동을 사용하지 않는다는 것입니다. 실제 금융 서비스 시스템은 BankAccount 클래스에 예금 방법을 사용해서는 안됩니다. 왜냐하면 이것이 컴퓨터가 발명되기 전에 은행이 일한 방식이 아니기 때문입니다! ATM이 발명되었을 때, ATM에서 은행원이 한 일을 문자 그대로 자동화해야했습니다. 텔러의 역할은 고객에게 계정 상태를 알리는 것입니다. 이를 위해 고객은 입금 전표를 출납원에게 전달하는 것과 같은 몇 가지 방법으로 출납원과 대화 할 수 있습니다.

이러한 개체 (텔러, 입금 전표 등)를 직접 수정하여 문제 도메인은 시스템의 엔터티가 전달한 메시지에 따라 구성됩니다.

계정 자체가 중요한 역할을합니다. 계정이라는 개념은 말 그대로 자산, 부채, 소득 또는 지출과 관련하여 재무 유입 및 유출 계정을 의미합니다. 회계 시스템 또는 회계사는 이러한 흐름을 기록, 유지 및 재생하며 특정 시점의 계정 재무 상태를 알려줍니다. 텔러가 작성한 가장 최근의 보고서는 "지금 당장"으로 생각할 수 있지만 실제로는 아닙니다. 회계 담당자가 특정 시점에서 설명한 재무 상태입니다. 그것은 당신이 은행에 갈 때 "지금 당장"이라는 환상을 가지고 있습니다. 일반적으로 당신은 지불을 할 수있는 유일한 사람이기 때문입니다. 이것은 100 년 전 특히 사실이지만 오늘날 많은 사람들이 자동 결제를하고 있습니다.

이것이 왜 중요한가? 거래를 기록하기 위해해야 ​​할 일을 스스로에게 물어보십시오.

고객은 은행으로부터의 영수증을 포함하여 자신이 수행 한 모든 것에 대한 자체 감사 로그를 가지고 있습니다. 마찬가지로, 은행은 자신이 수행 한 모든 것에 대한 자체 내부 감사 로그를 보관합니다. 은행은 항상 수행 복식 회계를 그들에게 총계정 원장 및 대차 대조표에 기록 거래를 의미한다. 이를 통해 은행은 화해 를 수행 할 수 있습니다주어진 재정 기간 (매일, 매주, 매월, 분기 별, 매년, 2 년마다 등) 동안 장부를 마감 할 때 가짜 항목이 없는지 확인하십시오. 이것은 또한 기록되는 것에 대한 기록이 dem 등원이어야 함을 암시한다. 즉, 고유 트랜잭션을 모두 나열하는 프로그램을 작성하는 경우, audit 등원 트랜잭션 식별자를 로깅 메시지에 포함하기 때문에 내부 감사 로그에 가짜 복제본이 있어도 그렇게 할 수 있습니다.

자동 결제를 통해 자동 이체 및 계좌 입금이 가능하므로 회계 담당자가 귀하를 예측할 수도 있습니다. 이것은 컴퓨터가 회계 시스템에 미칠 수있는 영향을 깨달았습니다. 따라서 누군가 는 과거를 바라 보는 것뿐만 아니라 미래를 바라보고 이전보다 더 세밀하게 현금 흐름을 추정하는 Resources-Events-Agents 라는 회계 시스템 체계를 발명했습니다 . 기본적으로 REA는 기존 회계 시스템보다 많은 메타 데이터이므로 더 나은보고 및 비즈니스 분석이 가능합니다. 예를 들어, "가치 사슬"분석 및 "공급망"분석은 기존 회계와는 쉬운 일이 아닙니다.

마찬가지로 Agoric Computing 또는 Smart Contracts 는 시장 메커니즘에서 컴퓨팅에 이르는 아이디어를 제공합니다. 입금 전표를 제공 할 때 입금을 위해 수표 또는 지갑도 제공하는 것이 중요합니다. 수표를 수령하고 실제로 계정에 입금하는 데 리드 타임이 있으므로 통화를 관리하는 안전한 방법이 필요합니다. 결과적으로 객체 기능은 분산 보안 통화를 달성하는 자연스러운 방법입니다. 그들은 Bob이 그 수표를 쓴 후 Alice가 그녀의 모든 자금을 인출하여 Bob을 속이지 않도록 보장하는 데 사용될 수 있습니다.