Orientação a Objetos: Java versus Common Lisp

Segundo Alan Kay, o paradigma de orientação a objetos foi inspirado pela antiga linguagem Simula, que realizava certas operações (definidas por procedimentos) sobre estruturas de dados. Kay via Simula como algo que parecia querer chegar a algo, mas ainda não sabia descrever o que era.

O conceito de orientação a objetos, como originalmente concebido, tinha como base uma organização hierárquica originalmente vista na biologia. Poderia-se compreender que organismos, em especial células, comportavam-se como estruturas com comportamento interno complexo, porém opaco ao resto do sistema; o contato da célula com o mundo exterior a ela e vice-versa era feito através de um canal, que poderia ser compreendido como uma membrana externa, que filtra certas mensagens e decide como as responde, e se responde-as.

Ainda tomando este modelo de estrutura opaca com um canal de comunicação externo por mensagens, percebeu-se que, quando aplicado um contexto matemático a esta ideia, poderia surgir uma álgebra própria onde estas estruturas poderiam ser manipuladas, de forma que esta troca de mensagens poderia ser descrita.

Às estruturas opacas, Alan Kay deu o nome de objetos, e estes foram os pilares que o fizeram começar a trabalhar na linguagem Smalltalk. Para Kay, este conceito de objetos não significaria apenas estruturas em uma linguagem, mas também formas de representar estruturas reais e criar meios de comunicação abstrata (por exemplo, entre computadores em uma rede). A influência de Smalltalk chegou à comunidade de (Common) Lisp e, eventualmente, surgiu o CLOS (Common Lisp Object System).

Estes conceitos influenciaram na criação da linguagem C++ e de outras linguagens que, por sua vez, possibilitaram a implementação da orientação a objetos na indústria de hoje, o que incluiu o advento da linguagem Java. Nestas linguagens, o principal foco está na organização de objetos como uma evolução de estruturas de dados, contendo, internamente, campos de dados e métodos que este objeto poderia executar, seja alterando seu próprio estado interno, seja comunicando-se com outros objetos do contexto.

A orientação a objetos estabelecida na indústria e ensinada nas universidades normalmente lembra a forma como classifica-se em C++ e Java, e acabou tornando-se um assunto controverso entre os puristas e estudiosos do assunto.

Neste post, pretendo mostrar implementações em Java e Common Lisp, respectivamente, como representantes de dois modos de pensar a respeito de orientação a objetos: Java como sendo uma vertente mais associada a C++, e Common Lisp como uma vertente mais associada a Smalltalk. Tentaremos resolver o seguinte problema, que é extremamente simples:

Temos um certo conjunto de formas. Estas formas podem ser círculos, quadrados ou pentágonos, todos sendo formas regulares. Cada uma das formas têm suas peculiaridades necessárias para a sua construção, como raio ou tamanho do lado. Gere um conjunto arbitrário de formas, e mostre as somas de seus perímetros, as somas de suas áreas, e as somas do quadrado da medida do lado de cada forma, caso seja possível.

Um programa Java é inicializado com a declaração do pacote que conterá as estruturas a serem utilizadas. Logo em seguida, importamos outros pacotes (ou classes específicas em certos pacotes) que auxiliarão na implementação do nosso programa.

package OOPTest;

import java.util.ArrayList;
import java.lang.UnsupportedOperationException;
import java.lang.Math;

Implementamos uma interface chamada IShape, que descreve valores básicos, que podem ser obtidos proceduralmente para uma forma qualquer: perímetro, área e quadrado do lado.

interface IShape {
    float perimeter();
    float area();
    float squaredSide();
}

Uma vez declarada a interface a ser implementada por cada forma, podemos declarar as classes para as formas em si.

A geração de uma quantidade arbitrária de formas e o cálculo das operações (soma dos perímetros, soma das áreas, soma dos quadrados dos lados) são encapsulados como métodos estáticos de uma classe Utility, para melhor compartimentalização. A implementação destas operações é bem evidente, com exceção da implementação da soma dos quadrados dos lados.

As formas em questão são armazenadas em um ArrayList, que será então repassado aos métodos de cálculo em questão.

Outra informação relevante é que, pelo fato de estes métodos serem estáticos, não é necessário instanciarmos esta classe para utilizá-los. Uma chamada conveniente a Utility.nomeDoMetodo(...) é o suficiente para seus usos.

class Utility {
    public static ArrayList<IShape> makeShapes(int numShapes) {
        ArrayList<IShape> arr = new ArrayList<IShape>();
        for(int i = 1; i <= (int)(numShapes / 3); i++) {
            arr.add(new Circle(i));
            arr.add(new Square(i));
            arr.add(new Pentagon(i));
        }
        return arr;
    }

    public static float sumOfPerimeters(ArrayList<IShape> arr) {
        float sum = 0.0f;
        for(IShape s : arr) {
            sum += s.perimeter();
        }
        return sum;
    }

    public static float sumOfAreas(ArrayList<IShape> arr) {
        float sum = 0.0f;
        for(IShape s : arr) {
            sum += s.area();
        }
        return sum;
    }

    public static float sumOfSquaredSides(ArrayList<IShape> arr) {
        float sum = 0.0f;
        for(IShape s : arr) {
            try {
                sum += s.squaredSide();
            } catch(UnsupportedOperationException e) {
                /* ... */
            }
        }
        return sum;
    }
}

Para a operação da soma dos quadrados dos lados, iteramos sobre o nosso contêiner de formas. Porém, se a forma atual em questão for um círculo, sabemos que este levantará uma exceção de UnsupportedOperationException. Para evitar que isto signifique a interrupção do nosso programa, encapsulamos a tentativa de contabilização do quadrado do lado da forma atual em um bloco try-catch. Este bloco trata a exceção, executando o bloco catch caso ela seja levantada.

Neste exemplo, caso a exceção em questão seja levantada, a contabilização do quadrado do lado para a forma atual será apenas ignorada.

Enfim, podemos executar nosso programa. Para tanto, precisamos de mais uma classe, que aqui chamamos Program, com um método estático chamado main. Aqui, criamos dez formas, e então imprimimos cada uma das operações, baseadas no conjunto de dez formas que criamos arbitrariamente.

class Program {
    public static void main(String[] args) {
        ArrayList<IShape> shapes = Utility.makeShapes(10);
        System.out.println("Sum of Perimeters: "
                + Utility.sumOfPerimeters(shapes));
        System.out.println("Sum of Areas: " + Utility.sumOfAreas(shapes));
        System.out.println("Sum of Squared Sides: "
                + Utility.sumOfSquaredSides(shapes));
    }
}

Primeiramente, vamos iniciar nosso projeto através da criação de um pacote em Common Lisp. Aqui estarei utilizando, também, o system iterate, que substitui o uso do macro loop na linguagem⁶.

(ql:quickload :iterate)

(defpackage :oop-test
  (:use #:cl #:iterate))

Common Lisp exige que exportemos certos símbolos, caso precisemos utilizá-los em outros pacotes. O environment de Common Lisp é inicializado no "pacote" cl-user (ou common-lisp-user). Como este é apenas um teste de propósito geral, podemos adentrar o pacote e definir símbolos logo dentro dele.

(in-package :oop-test)

Baseado no que foi dito na introdução, precisamos de um vocabulário inicial de mensagens que podemos passar para alguns objetos, como uma espécie de lista de comandos gerais.

(defgeneric perimeter (shape)
  (:documentation "Calculates perimeter of a shape."))

(defgeneric area (shape)
  (:documentation "Calculates area of a shape."))

(defgeneric squared-side (shape)
  (:documentation "Squares the side value of a regular shape."))

Aproveitamos, também, para utilizar o suporte da linguagem a docstrings para criar documentação mínima para nossas operações genéricas. Isto poderia ser útil, caso esquecêssemos do que cada uma destas mensagens poderia requisitar.

Perceba que o uso do átomo shape como aparente argumento destas operações genéricas é completamente arbitrário, apesar de possuir carga semântica para o programador. Em outras palavras, Common Lisp não possui exigência sobre a natureza dos símbolos utilizados em argumentos de generics; eles só estão lá para "marcar lugares" de argumentos em métodos – isto será entendido logo mais.

Em CLOS, classes são definidas a partir de duas coisas: uma lista de superclasses das quais derivam, e uma lista de slots, cada qual com suas propriedades. Aqui não teremos nenhuma superclasse para derivar, mas temos três classes, cada qual com um slot relevante.

(defclass circle ()
  ((%radius :initarg :radius
            :reader radius)))

(defclass square ()
  ((%side :initarg :side
          :reader side)))

(defclass pentagon ()
  ((%side :initarg :side
          :reader side)))

A classe circle define nosso círculo. Temos um slot chamado %radius, que armazenará o raio do nosso círculo.

O mesmo vale para o slot %side de square e pentagon, que representa o tamanho do lado destas formas.

Veja que definimos duas propriedades extras para cada slot. A primeira é o initarg; a segunda, um reader. O initarg representa o átomo que simboliza a chave para definir o valor para aquele slot, durante o instanciamento da classe⁷.

Já o reader é a definição rápida de uma forma de realizar a leitura daquele slot, em outros cantos do código. Ele será necessário para que possamos, efetivamente, recuperar os dados da instância. No caso de circle, o raio de um círculo poderá ser recuperado de uma instância com (radius instancia). Situações similares ocorrerão para os lados de square e pentagon⁸.

Métodos, em Common Lisp, nada mais são que especificações das operações genéricas.⁹ Ao definirmos o método, normalmente teremos um ou mais parâmetros na lista de parâmetros que determinam a forma como a operação será despachada, de acordo com o objeto passado por parâmetro.

Por exemplo, um argumento de assinatura (variavel nome-da-classe) implica que aquele método possui implementação para a classe nome-da-classe e, portanto, variavel terá uma mensagem a retornar mediante a invocação do método em questão¹⁰.

Realizaremos a implementação dos métodos por mensagem, ao invés de implementarmos todos os métodos para cada classe, por vez.

Da mesma forma como fizemos no "jeito" anterior, definiremos alguns procedimentos como utilitários, tanto para gerar nosso contêiner de instâncias como para gerar nossas operações.

As instâncias, seja lá quais forem, serão armazenadas em uma lista. O form collect, no macro iter, garante que cada uma das instâncias geradas sejam incorporadas ao fim da lista. Enquanto isso, make-instance demonstra como podemos instanciar uma classe qualquer (veja a utilização das chaves previamente definidas nos :initarg dos slots de cada classe).

(defun make-shapes (num-shapes)
  (iter (for x from 1 to (/ num-shapes 3))
        (collect (make-instance 'circle   :radius x))
        (collect (make-instance 'square   :side x))
        (collect (make-instance 'pentagon :side x))))

(defun sum-of-perimeters (list)
  (iter (for elt in list)
        (sum (perimeter elt))))

(defun sum-of-areas (list)
  (iter (for elt in list)
        (sum (area elt))))

Definamos uma função qualquer, incumbida de gerar nossa sequência de dez formas, e então imprimir os resultados das operações na tela. O uso do nome main aqui é arbitrário, podendo ser substituído por qualquer outra coisa.

(defun main ()
  (let ((shapes (make-shapes 10)))
    (format t "Sum of Perimeters: ~a~%"
            (sum-of-perimeters shapes))
    (format t "Sum of Areas: ~a~%" (sum-of-areas shapes))
    (format t "Sum of Squared Sides: ~a~%"
            (sum-of-squared-sides shapes))))

Podemos montar um pequeno quadro, destacando as partes mais relevantes das implementações e estabelecendo um paralelo entre elas.

Neste momento, peço que pause e pondere a respeito do que apresentei neste artigo. Veja se meu paralelo parece fazer sentido, se você notou mais alguma diferença (ou se não notou diferença alguma).

Independente do conceito visto como melhor por você, leitor, lembre-se de que situações específicas exigem ferramentas específicas.

Como este artigo foi escrito no Emacs, em org-mode, você poderá obter o código do mesmo a seguir. Os arquivos das linguagens Java e Common Lisp, contendo o código-fonte em si, poderão ser obtidos ao colocar-se o cursor sobre o bloco de código a seguir, e utilizando o atalho C-c C-c:

(org-babel-tangle)

Todo e qualquer código descrito aqui é disponibilizado sob a licença BSD 2-Clause. Para mais informação, veja este link.

Copyright (c) 2019, Lucas Vieira.