Rich Hickey는 "인터페이스 / 클래스 / 타입]의 모든 특성으로 인해 재사용이 중단됩니다!"

Rich Hickey의 생각을 자극하는 goto 컨퍼런스 기조 연설 에서 29 분에 " Value of Values "는 Java와 같은 언어의 오버 헤드에 대해 이야기하고 있으며 "모든 인터페이스가 재사용을 중단시킵니다." 그는 무엇을 의미합니까? 그게 사실입니까?

답변을 검색 할 때 다음과 같은 결과를 얻었습니다.

• 최소한의 지식 원리 일명 API 인터페이스를 장려하는 데 미터 의 법칙 . Wikipedia에도 몇 가지 단점이 있습니다.

• 재사용이 아닌 사용을 주장하는 케 블린 헤니의 제국 의류 위기 가 적절한 목표입니다.

• Jack Diederich의 " Stop Writing Classes "대화는 일반적으로 오버 엔지니어링에 반대한다고 주장합니다.

분명히, 잘못 쓰여진 것은 쓸모가 없습니다. 그러나 잘 작성된 API의 인터페이스가 해당 코드를 사용하지 못하게하려면 어떻게해야합니까? 한 가지 목적을 위해 만들어진 어떤 것의 역사에는 다른 어떤 것에 더 많이 사용되는 예가 있습니다 . 그러나 소프트웨어 세계에서 의도하지 않은 목적으로 무언가를 사용하면 일반적으로 중단됩니다.

합법적이지만 의도하지 않은 일부 코드 사용을 방지하는 좋은 인터페이스의 좋은 예를 찾고 있습니다. 존재합니까? 나는 그것을 그림 수 없습니다.

Rich Hickey의 전체 프레젠테이션을 보지 못했지만 그를 올바르게 이해하고 29 분 마크에 대해 그가 말한 것을 판단하면 재사용을 죽이는 유형 에 대해 논쟁하는 것 같습니다 . 그는 "인터페이스"라는 용어를 "명명 된 유형"의 동의어로 느슨하게 사용하고 있습니다.

Java-land 에 type 과 { "name":"John" }type의 두 개의 엔티티 가 있는 경우 공통 인터페이스 또는 상위 (예 : 더 많은 코드 작성) 를 공유하지 않으면 상호 운용 할 수 없습니다 . 따라서 인터페이스 / 유형은 "재사용을 죽이는"것입니다. 비록 똑같이 보이고 똑같아 보이 더라도 , 이를 지원하기위한 추가 코드를 작성하지 않으면 다른 것과 상호 교환하여 사용될 수 없습니다. 참고 Hickey는 또한 많은 클래스를 필요로하는 Java 프로젝트 ( "누가 20 개의 클래스를 사용하여 Java 애플리케이션을 작성 했습니까?")에 대해 농담을합니다. 이는 위의 결과 중 하나 인 것 같습니다.Person{ "name": "Rover" }DogMammalPersonDog

그러나 "가치 중심"언어에서는 이러한 구조에 유형을 할당하지 않습니다. 그것들은 같은 구조를 공유하는 값들입니다 (제 예제에서는 둘 다 name문자열 값을 가진 필드를가집니다). 따라서 쉽게 상호 운용 될 수 있습니다.

요약하면,이 모든 것은 구조적 평등 대 명시 적 유형 / 인터페이스 평등에 관한 것 같습니다 . 내가 아직 보지 않은 비디오 부분에서 뭔가를 놓치지 않으면 :)

그는 인터페이스를 인스턴스화 할 수 없다는 기본 사실을 언급하고있을 것입니다. reuse인터페이스를 사용할 수 없습니다 . 이를 지원하는 코드 만 구현할 수 있으며 인터페이스 용 코드를 작성할 때는 재사용 할 수 없습니다.

Java는 인터페이스를 인수로 사용하는 많은 API의 프레임 워크를 제공 한 경험이 있지만 API를 개발 한 팀 은 이러한 인터페이스 에서 재사용 할 수있는 광범위한 클래스를 구현하지 않습니다 .

IWindow대화 상자에 대한 인터페이스 가있는 GUI 프레임 워크와 비슷하며 IButton컨트롤에 대한 인터페이스를 추가 할 수 있습니다 . 예외적으로, 그들은 당신에게 좋은 Button클래스를 제공 하지 않았습니다 IButton. 그래서 당신은 자신의 것을 만들어두고 있습니다.

핵심 기능을 제공하는 광범위한 기본 클래스를 가진 추상 프레임 워크가 더 재사용 가능하며, 추상 클래스가 프레임 워크를 사용하는 사람들이 액세스 할 수있을 때 가장 잘 작동합니다.

Java 개발자는 API 계층 만 노출 된 곳에서이 작업을 시작했습니다 interfaces. 이러한 인터페이스를 구현할 수는 있지만 해당 인터페이스를 구현 한 개발자의 클래스는 재사용 할 수 없습니다. 망토와 단검 스타일의 API 개발과 비슷합니다.

그의 프레젠테이션에서 슬라이드 13 ( Value of Values )이 이것을 이해하는 데 도움이된다고 생각합니다.

가치

• 방법이 필요 하지 않습니다
  • 코드없이 값을 보내면
    괜찮습니다.

내 이해는, 당신이 나에게 보낸 값을 두 배로 해야한다면 , 나는 단순히 다음과 같은 코드를 작성 한다고 제안합니다.

    MyValue = Double(YourValue)

보시다시피 위의 코드는 당신이 어떤 종류의 값을 보냈 든 완벽하게 재사용 할 수 있습니다.

이제 객체와 인터페이스가있는 언어에서 어떻게 보일까요?

    Doublable MyValue = YourValue.Double()

아 잠깐! 어떤 경우를 YourValue구현하지 않습니다 Doublable? 두 배로 늘릴 수는 없지만 완벽하게 될 수는 있지만 ... 방법이 없다면 Double어떨까요? (say라고 불리는 방법이 있다면 TwiceAsMuch어떨까요?)

아 문제가 생겼어 YourValue.Double작동 하지 않습니다. 더 이상 재사용 할 수 없습니다 . 위의 슬라이드를 읽었을 때, 이것은 히키가 "모든 인터페이스가 재사용을 죽인다"고 말했을 때의 의미에 관한 것입니다.

인터페이스는 객체가 해당 메소드와 함께 작동하는 코드와 함께 "메서드와 함께"전달된다고 가정합니다. 객체를 사용하려면 해당 코드를 호출하는 방법 , 호출 할 메소드 를 이해해야합니다 .

예상 된 방법 이 누락되면 의미 상 으로 원하는 작업이 객체에 완벽하게 맞는다 는 문제가 있습니다. 프레젠테이션에서 언급했듯이 값에는 메서드 가 필요 하지 않으며 ( "코드없이 값을 보낼 수 있고 괜찮습니다") 일반적인 방법으로 코드를 처리 할 수 ​​있습니다.

참고 사항 : 코드가없는 값 을 전달한다는 개념은 OOP 의 플라이급 패턴 을 생각 나게합니다 .

^{다른 유사한 객체와 가능한 많은 데이터를 공유하여 메모리 사용을 최소화하는 객체; 간단한 반복 표현이 허용 할 수없는 양의 메모리를 사용할 때 많은 수의 객체를 사용하는 방법입니다. 플라이급 객체는 정의 값 객체 입니다. 객체 인스턴스의 ID는 아무런 영향을 미치지 않으므로 동일한 값을 가진 두 개의 Flyweight 인스턴스는 동일한 것으로 간주됩니다.}

필자가 본 Flyweight 사용법은 일반적으로 객체에서 코드 (메소드, 인터페이스)를 제거하고 코드가없는 값 뿐만 아니라 주변에 물건을 전달하는 것과 동일한 접근 방식을 따랐습니다 .

이것은 슬라이드에서와 마찬가지로 "값은 메소드가 필요하지 않습니다. 코드없이 값을 보내면 괜찮습니다."

(즉, 내) 이상적인 세계 클래스와 인터페이스에서 항상 동작을 설명하지만 실제로는 너무 자주 데이터를 설명하는 것입니다. 어제 나는 누군가 BankAccount가 영화를 보는 것 이상 으로 소위 수업을 만드는 비디오를 보았습니다 int(실제로는 int단순히으로 남겼던 재사용을 '죽이기' 보다 유용하지는 않았습니다 int), '좋은'디자인이라는 이름으로 복잡한 데이터 표현을 지속적으로 재창조 할 때 낭비되는 코드, 땀, 눈물은 엄청납니다. 의미있는 방식으로 데이터를 사용하지 않는 경우 그대로 두십시오.

이제, Rich Hickey는 아기를 목욕물로 버리기 위해 만족하는 단계이며, 우리 모두가 가치의 땅 (명사 왕국의 이웃)에서 살아야한다고 말합니다. 한편, OOP는 신중하게 고용 될 때 재사용 (및 기능적 프로그래밍이 부족한 것으로 밝혀진 중요한 검색 가능성)을 촉진 할 수 있고 촉진한다고 생각합니다. 이 긴장을 가장 잘 포착하는 OOP 원칙을 찾고 있다면 http://c2.com/cgi/wiki?TellDontAsk (Demeter의 가까운 사촌) 일 것입니다.