do jmp às Interfaces – A história do acoplamento

No princípio era o jmp. E o call. E o ret. E os saltos condicionais. E com isto os heróicos programadores da época conseguiam criar laços e blocos cuja execução dependia de alguma condição ter sido satisfeita. E a máquina começou a pensar. Um label indicava ao assembler aonde determinada rotina estava começando, e o assembler transformava aquele label em um endereço de memória. Entre o label e o ret estava o que conhecemos hoje por procedure.

E então nascia a linguagem de alto nível. E os whiles. E os fors. E os ifs. E com isto os saltos condicionais tornaram-se mais humanos e transformaram-se em blocos quase compreensíveis. O label deu lugar a um cabeçalho com informações de passagem de parâmetro e o ret deu lugar à declaração do final daquele bloco. Nascia também a procedure, ou function, caso retorne algum valor.

Variáveis públicas acessíveis demais. Variáveis locais acessíveis de menos. E nascia a orientação a objetos com objetivo de ligar informação e código em uma mesma entidade. Cada objeto tem seus próprios membros, e cada procedure ou function — agora método — chamado através daquele objeto, têm acesso irrestrito aos seus respectivos membros. Nascia o encapsulamento, e a preocupação com a segurança da informação.

Objetos estáticos são inflexíveis, e então nascia o ponteiro para objetos com o objetivo de tornar seu manuseio, digamos, mais dinâmico. Depois de polido e ganhar novos recursos, os ponteiros para objetos passaram a se chamar classe.

E nascia o polimorfismo. Métodos das classes passam a ser escritos pensando sempre em reaproveitamento e customização. Registro de classes, métodos virtuais, acesso a rotinas de classes abstratas. E explodia o uso do reaproveitamento de código.

E com o fortalecimento do polimorfismo e reaproveitamento de código, quem enfraquecia era o acoplamento. A rotina que precisa de um recurso não precisa mais depender daquele recurso. Cria-se uma classe abstrata, utiliza-se o recurso através de um método virtual desta classe, implementa-se o recurso através de uma classe descendente e sobrecarregando o método, e por fim registra-se a classe que implementa o recurso. Um certo método M (notificação por email) que precisa de um certo recurso X (rotina de envio de emails) irá acessar uma classe abstrata A (TEnviaEmail) sem acoplar seu próprio código a um componente específico. Uma certa classe B (TIndyEnviaEmail), que descende de A, implementa o envio de emails através do framework Indy.

O enfraquecimento do acoplamento de implementação aumentou o uso de classes que precisam descender daquelas classes reconhecidas na outra camada. No caso acima, a classe B sempre descende da classe A. E passou a ocorrer um acoplamento entre uma hierarquia de classes.

E nascia então a interface. E a classe B não precisa mais descender da classe A, ela pode não descender de ninguém ou pode descender de outras classes que o método M não conhece. A classe B precisa apenas implementar métodos que o método M precisa chamar. Ou seja, a classe B precisa apenas implementar os métodos da interface I, e esta sim é conhecida por M.

E morria o acoplamento.

2 thoughts on “do jmp às Interfaces – A história do acoplamento”

  1. Olá João,

    A maneira como você conta uma história, ou fala sobre uma tecnologia, enfim, transmite para o leitor um aprendizado impar.
    Eu sempre venho aqui no Blog reler suas postagens, e em cada visita aprendo duas coisas importantes — a teoria e a prática.

    Você além de ser um exemplo de ser humano, é um grande ícone da história da programação, em especial com Pascal; e não só aqui no Brasil.

    Sucesso em tua vida Brother, e obrigado por compartilhar tantas informações importantes; forte abraço,

    Silvio Clécio.

  2. Este é um caso raro em blogs, sem ctrl+c ctrl+v de outros, exemplos simples idéias bem explicadas, parabéns pelo blog de modo geral, Muito bom!

Comments are closed.