소수설에서 태어난 다양한 주장들에 대해 알아보자. ADT와 PDA, Alan Kay에 대해 알아보자.

지금까지..

  • 주류 OO에 대해 배웠다.
  • 이제는 소수설들이 어떤 것들이 있었는지 알아보자.
  • 취할 것은 취하고, 아닌 것은 아닌 것임을 알기 위해 배운다.
  • 말도 안되는 주장을 하는 사람에 대해 미리 대처할 수 있도록 배워두자.
    • 이럴 때는 이런걸 써야해요! - (잘모르니) 정말요?
    • 이런 상황을 막아야 한다.

OOP 토론시 피해야 할 사람

  1. 처음 듣는 주장을 하며 "그건 올바른 OOP가 아니야" 하는 사람
  2. 이건 "순수 OOP 언어가 아니야" 하는 사람
  3. "모든 프로그램은 OOP로 만들어야 해" 하는 사람
  4. "<어쩌고>한 <누구>가 이리 말했으니 너는 틀려" 하는 사람 : 권위에 호소하는 것은 본질을 훼손시킬 가능성이 높음
  5. "이 방법만 따르면 문제가 해결돼" 하는 사람

ADT와 PDA

Object-Oriented Programming Versus Abstract Data Types: William R.Cook

  • 초창기에 OOP를 바라보던 두가지 관점
  • 현재는 둘다 섞여있음
  • Abstract Data Types: 추상적 데이터 타입
  • Procedural Data Abstraction: 절차적 데이터 추상화 - 함수에 가까움
  • 대다수는 ADT로 보고 있음
  • PDA는 처음 개체지향 프로그래밍이 대두되며 사용했던 단어때문에 전통이라 우기는 중

Alan Kay가 개체를 바라보는 입장

  • 소수설 주창자 중 가장 영향력 있는 사람: Alan Kay
  • OOP라는 용어를 처음 만든 사람
  • Alan Kay의 OOP 정의: "OO의 핵심은 메시지"
    • 우리가 배웠던 것은 캡슐화, 데이터, 개체처럼 세계를 본다 이런 것이었음
    • 근데 이사람은 "이거해" 가 중심이라고 봄
  • 본인의 주장을 Smalltalk 이라는 언어로까지 만든 대단한 사람
  • 생물학, 수학 전공 (?)

불쌍한 Alan Kay..

  • 극단적 주장을 하는 사람들: PDA에 기반
  • 자기들의 주장에 대한 근거를 Alan Kay도 그랬다로 대곤 함
  • 하지만 확인해보면 Alan Kay는 보통 그런적이 없음 ㅋㅋ
  • 근거가 빈약한 사람들이 권위에 호소하려고 이용하는 것.
  • 명예 회복 인터뷰
    • 이메일 답변임

Alan Kay의 입장에 대한 이유

  • 그에게 개체란 생물학에서 세포같은 존재
    • 자기 결정권을 가진 생명체
  • 생물학 전공자기 때문에 그렇게 본다고 말함
  • 굳이 컴퓨터 환경에서 비슷한 것을 찾으면, 네트워크에 존재하는 컴퓨터
    • 즉, 단순한 개체보다는 자기 결정권을 가진 존재라 생각함
  • 개체로부터 데이터라는 존재를 지워버리고 싶었다.
  • 메시지로 서로간의 상호작용, 즉 데이터 변경을 하고 싶었다.
    • 확실한 PDA 진영
  • Smalltalk에도 개체들로 구성된 살아 숨쉬는 환경임
    • 시뮬레이션 도는 느낌

Alan Kay가 이용당하는 순간들

  • 내 주장은 Alan Kay의 주장에 기초하고 있기 때문에 옳다.

Alan Kay가 처음 OO를 창시한 사람이다? (X)

  • 자기는 아니라고 함
  • 이미 ADT를 기반으로 개체지향 비슷한 움직임은 진행되고 있었다고 함
  • 거기의 자신의 주장을 한 것일 뿐
  • 당시 소프트웨어 공학자들은 이 주장을 받아들이지 않았고,
  • ADT를 기반으로 오늘날의 개체지향이 완성됨
  • 아직도 자기 주장에 기반을 둔 소수설이 있다는 것을 신기하다고 생각
  • 그런데 "지금 하는게 뭐냐"라고 물어봐서 OO라는 답을 하긴 했다고 함
  • 자기 주장에 맞지 않는 용어였고, 오히려 메시지 지향 "Message-Oriented"라 했어야 한다고 함
    • 데이터는 중요하지 않고 메시지 전달만 중요했기 때문
    • 실제로 함수 시그내처도 좀 다름

Smalltalk의 메서드 호출

public class Calculator {
    
    public int add(int a, int b) {
        return a + b;
    }

    ... 

    some method..{ 
        int val = Add(1, 2) // 컴파일 에러
    }
}
  • 실수로 메서드 이름 잘못적으면 컴파일 에러가 남
  • smalltalk에서는 그렇지 않음
  • 이미 존재하는 메서드를 호출한다는 개념이 없다.
  • 컴파일 중에 올바른 메서드 시그내처를 호출하는지 검사도 불가
  • 그보다는 다른 개체에 "이거 해줘"라고 메시지만 보내는 시스템
    • 요청을 받은 개체는 메서드를 가지고 있을 수도, 아닐 수도 있음
    • 그럼에도 요청을 보낼 수 있음
public Object execute(String methodName, Object[] args) {
    switch (methodName) {
        case "add":
            // 인자 두개 받아서 리턴
        case "mad": // multiply , add
            // args[0] * args[1] + args[2] 반환
    }
}
  • 굳이 표현해보면 위와 비슷흐다.
  • 메소드 이름만 받고, 그걸 검사해서 함수 실행
  • 만약 이상황에서 "add" 메서드 호출용으로 인자가 들어왔는데, 내가 원한거랑 다르다면?
    • 예외..
  • 속하지 않는 메서드 이름이 들어온다면?
    • 예외..
  • 그렇다면 smalltalk의 다형성이란?
    • 어떤 메서드 시그내처를 미리 정의하고 따르는 개념이 아님
    • 다형성이 부모 클래스 공통 시그내처에 의존하지 않음
    • methodname의 문자열만 처리할 수 있으면 다형성
      • 일반적인 다형성이 아님
  • smalltalk는 예외를 많이 사용할 수 밖에 없다.
    • 동적 타입을 선호할 수록 예외로부터 안전한 프로그래밍을 중시

Alan Kay는 정적 타입 언어에 반대한다, 이른 바인딩에 반대한다.

  • smalltalk의 모든 것은 늦은 바인딩
  • 모든 것이 동적이기 때문
  • 특히 alan kay는 모든 것에 극도로 늦은 바인딩을 원했음
  • 인터뷰를 근거로보면 alan kay가 정적 타입에 반대한 것이 아님
  • 다만 정적 타입 언어를 사용할 때 힘들었다고 함, 나는 싫었다가 전부

동적 타입의 문제

  • 실수를 유발한다.
  • 컴파일러가 실수를 잡아줄 수 없다.

Reference

profile
Goal, Plan, Execute.

2개의 댓글

comment-user-thumbnail
2023년 3월 31일

멋진 글 잘 보았습니다. 스몰토크에서 메서드 시그니처가 틀려도 컴파일 오류가 발생하지 않는다는 걸 처음 알았네요.

1개의 답글