OCaml의 OOP 구조체에서 타입을 결정하기

Question

OCaml의 OOP 구조체에 대해 배우고 있으며, 객체 외부에서 type 키워드를 사용하지 않고 polymorphic match 문을 표현하는 방법을 모를 때까지 부분적으로 이것을 구현했습니다.

class bar (param:string) = 
object (code) 

end;; 

class foo param = 
object (code) 
initializer 
    match param with 
    string -> Printf.printf "param is a string" 
    | bar -> Printf.printf "param is a bar"  
end;; 

let b = new bar "a string";; 
let f1 = new foo "test";; 
let f2 = new foo b;; 

즉석에서 전달되는 객체의 유형을 결정할 수 있습니까?

Answer 1

그 일치는 '문자열'에 'param'을 바인딩하는 것 외에는 아무것도 수행하지 않으며, ocaml은 두 번째 일치가 사용되지 않는다고 말해야합니다. 일치를 수행하려면 변형 유형을 사용해야한다고 생각합니다. 다음은 다형성 변형 유형을 사용하는 예입니다.

class bar (param:string) = 
    object (code) 
end 

class foo param = 
    object (code) 
    initializer 
    match param with 
    | `String str -> Printf.printf "param is a string" 
    | `Bar bar -> Printf.printf "param is a bar"  
end 

let b = new bar "a string" 
let f1 = new foo (`String "test") 
let f2 = new foo (`Bar b) 

Answer 2

일반적으로 OCaml은 유형의 런타임 식별을 지원하지 않습니다.

즉, 가비지 수집기가 작동하도록 런타임 표현에 포함 된 작은 유형 정보가 있습니다. 뭔가가 문자열인지 확인하려면, 당신은 할 수 있습니다 : OCaml의의 런타임 표현에

if Obj.tag (Obj.repr param) = Obj.string_tag then 

상세 정보 Interfacing C with Objective Caml에서 사용할 수 있습니다. 그러나 이러한 종류의 검사는 일반적으로 OCaml이 권장하는 프로그래밍의 종류에 반하는 것으로,이 특정 검사에서 유용하게 사용할 수있는 방법이 명확하지 않습니다 (문자열로 변환해야하며 형식에 혼란을 야기합니다 안전). 더 나은 해결책은 대수 데이터 형식 또는 다형성 변형을 사용하여 유효한 매개 변수 형식을 설명하고 그 위에 패턴 일치를 적용하는 것입니다.

유형 안전 다운 캐스트는 유용 할 수 있지만 사실 OCaml에서 지원되지 않습니다. 그것이 당신이 찾고있는 것이라면, 당신 자신의 메커니즘을 롤업 할 필요가있을 것이다.

Answer 3

다형 성 일치 구문의 개념은 객체 지향 프로그래밍과 모순됩니다! 행동의 사용자 정의는 객체에 캡슐화되어야합니다. 클래스에 "실제로 무엇입니까?"라고 묻는 코드는 디자인 문제를 나타냅니다.

type typ = A | B 

class bar = 
object 
    method typ = A 
end 

class rebar = 
object 
    method typ = B 
end 

class foo param = 
object 
    initializer 
    match param#typ with 
    | A -> print_endline "This is a A" 
    | B -> print_endline "This is a B" 
end 

는 사용하지 마십시오 다형성 변종을 위해 :

당신 정말 클래스는 실제로 가장 쉬운 방법은 그냥이 방법을 추가하는 것입니다 무엇을 말할 수 있으려면, 말했다 이는 유지 보수 작업에서 철저한 패턴 매칭의 이점을 깨뜨리는 것입니다.

이 경우에도 Liskov substitution principle을 무시하고 코드 유지 관리 담당자가 바쁜 날을 준비 할 가능성이 있습니다. 우리 세계는 그 잔인 함을 필요로하지 않습니다!