O que Rich Hickey quis dizer quando disse: “Toda essa especificidade [de interfaces / classes / tipos] mata sua reutilização!”

40

Na palestra inteligente da conferência do Rich Hickey, " O Valor dos Valores " aos 29 minutos ele está falando a sobrecarga de uma linguagem como Java e faz uma declaração como: "Todas essas interfaces eliminam sua reutilização". O que ele quer dizer? Isso é verdade?

Na minha busca por respostas, eu encontrei:

  • O Princípio do Mínimo Conhecimento AKA A Lei do Demeter , que incentiva interfaces de API herméticas. A Wikipedia também lista algumas desvantagens.

  • Imperial Clothing Crisis de Kevlin Henney, que argumenta que usar, não reutilizar é o objetivo apropriado.

  • " Parem de escrever as aulas " de Jack Diederich "que argumenta contra o excesso de engenharia em geral.

Claramente, qualquer coisa escrita o bastante será inútil. Mas como a interface de uma API bem escrita impediria que o código fosse usado? Há exemplos na história de algo feito para um propósito que é usado mais para algo else . Mas no mundo dos softwares, se você usa algo para um propósito que não foi planejado, ele geralmente quebra.

Estou procurando um bom exemplo de uma boa interface que impede o uso legítimo, mas não intencional, de algum código. Isso existe? Eu não posso imaginar isso.

    
por GlenPeterson 24.05.2013 / 00:29
fonte

4 respostas

31
Não assisti a apresentação completa de Rich Hickey, mas se eu o entendi corretamente, e a julgar pelo que ele diz sobre a marca de 29 minutos, ele parece estar discutindo sobre tipos matando a reutilização. Ele está usando o termo "interface" livremente como sinônimo de "tipo nomeado", o que faz sentido.

Se você tiver duas entidades { "name":"John" } do tipo Person e { "name": "Rover" } do tipo Dog , no Java-land elas provavelmente não poderão interoperar, a menos que compartilhem uma interface ou ancestral comum (como Mammal , que significa escrever mais código). Portanto, as interfaces / tipos aqui estão "matando sua reutilização": mesmo que Person e Dog pareçam iguais, um não pode ser usado de forma intercambiável com o outro, a menos que você escreva um código adicional para suportar isso. Nota Hickey também brinca sobre projetos em Java que precisam de muitas classes ("Quem aqui escreveu um aplicativo Java usando apenas 20 classes?"), O que parece uma conseqüência do que foi dito acima.

Em linguagens "orientadas a valor", no entanto, você não atribuirá tipos a essas estruturas; eles são apenas valores que compartilham a mesma estrutura (no meu exemplo, ambos têm um campo name com um valor String) e, portanto, podem facilmente interoperar, por exemplo, eles podem ser adicionados à mesma coleção, passados aos mesmos métodos, etc.

Para resumir, tudo isso parece ser algo sobre a igualdade estrutural vs Tipo de explícito / igualdade de interface . A menos que eu tenha perdido alguma coisa das partes do vídeo que eu ainda não assisti:)

    
por 26.05.2013 / 00:41
fonte
27

Ele provavelmente está se referindo ao fato básico de que uma interface não pode ser instanciada. Você não pode reuse uma interface. Você só pode implementar código que ofereça suporte a ele e, quando você escreve código para uma interface, não há reutilização.

O Java tem um histórico de fornecimento de estruturas de muitas APIs que usam uma interface como argumentos, mas a equipe que desenvolveu a API nunca implementa uma ampla variedade de classes para que você reutilize as interfaces.

É como uma estrutura de GUI que possui uma interface IWindow para uma caixa de diálogo e, em seguida, é possível adicionar IButton interfaces para controles. Exceto, eles nunca lhe deram uma boa Button classe que implementa IButton . Então você é deixado criando o seu próprio.

Estruturas abstraídas que têm uma ampla gama de classes base que fornecem funcionalidades básicas são mais reutilizáveis, e que funciona melhor quando essas classes abstratas são acessíveis para aqueles que usam o framework.

Os desenvolvedores de Java começaram a fazer isso onde as camadas da API expuseram apenas interfaces . Você pode implementar essas interfaces, mas nunca poderá reutilizar classes do desenvolvedor que implementou essas interfaces. É como um estilo de capa e punhal de desenvolvimento de APIs.

    
por 24.05.2013 / 01:59
fonte
13

Acho que o slide 13 em sua apresentação ( O valor dos valores ) ajuda a entender isso:

Values

  • Don’t need methods
    • I can send you values without code
      and you are fine

Meu entendimento é que, Hickey sugere que, se eu precisar, digamos, dobrar o valor que você enviou para mim, eu simplesmente escrevo código parecido com

    MyValue = Double(YourValue)

Veja, o código acima é o mesmo, não importa o tipo de valor que você enviou - uma espécie de reutilização perfeita .

Agora, como isso ficaria na linguagem com objetos e interfaces?

    Doublable MyValue = YourValue.Double()

oh espere! e se YourValue não implementar Doublable ? não que não possa ser duplicado, pode perfeitamente ser, mas ... e se simplesmente não houver nenhum método Double ? (e se houver um método chamado digamos TwiceAsMuch ?)

Ah, nós temos um problema. YourValue.Double não funciona, não pode mais ser reutilizado . De acordo com minha leitura do slide acima, isso é sobre o que Hickey queria dizer quando disse: "Todas essas interfaces matam sua reutilização!"

Veja, as interfaces assumem que os objetos são passados "junto com seus métodos", junto com o código que opera neles. Para usar objetos, é preciso entender como invocar esse código, o que método chamar.

Quando o método esperado está faltando, há um problema, mesmo que semanticamente , a operação desejada faça todo o sentido para um objeto. Como afirmado na apresentação, os valores não precisam de métodos (eu posso lhe enviar valores sem código e você está bem), permitindo escrever código lidando com eles de uma maneira genérica.

Nota: a noção de passar em torno de valores sem código de alguma forma me lembra de um padrão de peso a> em OOP.

an object that minimizes memory use by sharing as much data as possible with other similar objects; it is a way to use objects in large numbers when a simple repeated representation would use an unacceptable amount of memory... Flyweight objects are by definition value objects. The identity of the object instance is of no consequence therefore two Flyweight instances of the same value are considered equal...

Os usos do Flyweight que eu vi normalmente seguem a mesma abordagem de retirar o código (métodos, interfaces) dos objetos e passar coisas por aí como, bem, valores sem código , esperando que receber código tem meios necessários para operar nestes.

Isso parece muito com o slide, "os valores não precisam de métodos. Posso enviar valores sem código e você está bem".

    
por 24.05.2013 / 01:03
fonte
1

Em uma (isto é, minha) classe mundial e interfaces ideais sempre descrevem o comportamento, mas o fato é que muitas vezes elas acabam descrevendo dados. Ontem mesmo eu assisti a um vídeo de alguém construindo uma chamada classe BankAccount que não era nada mais do que uma glorificada int (na verdade ela era muito menos útil que uma int , assim 'matando' a reutilização que eu teria tinha sido simplesmente deixado como int ), tudo em nome do 'bom' design. A quantidade de código, suor e lágrimas desperdiçadas continuamente reinventando representações confusas de dados é impressionante; Se você não estiver usando os dados de uma maneira significativa, por favor, apenas deixe que seja.

Agora, esta é a fase em que Rich Hickey se contenta em jogar o bebê para fora com a água do banho e dizer que todos devemos ir morar na terra dos valores (um vizinho do reino dos substantivos). Eu penso, por um lado, que a OOP pode e promove a reutilização (e, principalmente, a descoberta, que eu acho carente de programação funcional) quando empregada de forma criteriosa. Se você está procurando um princípio OOP que melhor capte essa tensão, eu acho que pode ser o link (que, claro, é um primo próximo de Demeter)

    
por 27.06.2013 / 16:33
fonte