Aula 3: Desacoplamento 2ª. Parte

Transcrição

1 Aula 3: Desacoplamento 2ª. Parte Na última aula, nós falamos a respeito da importância das dependências entre as partes do programa em um projeto de software. Uma boa linguagem de programação permite a você expressar as dependências entre as partes, além de controlá-las prevenindo o surgimento de dependências não planejadas. Nesta aula, nós vamos demonstrar os aspectos do Java que podem ser utilizados para expressar e controlar dependências. Vamos estudar também uma variedade de soluções para um problema simples de programação, ilustrando com ênfase o papel das interfaces. 3.1 Revisão: Diagrama de Dependências Modular Vamos começar com uma breve revisão do diagrama de dependência modular (MDD) da última aula. Um MDD mostra dois tipos de partes de programas: partes de implementação (classes em Java) exibidas como retângulos com uma única faixa no topo, e as partes de especificação exibidas como retângulos com faixas tanto no topo quanto na parte de baixo. A organização das partes em agrupamentos (tal como packages 1, ou pacotes, em Java) pode ser expressa no MDD através de contornos englobando as partes do programa. Assim como definido pelo estilo de diagrama denominado Venn-diagramstyle. UmaflechaplanacomapontaabertaconectaumapartedeimplementaçãoA com uma parte de especificação S, e expressa que o significado de A depende do significado de S. Isto, pois a especificação S não pode, por si só, ter um significado dependente de outras partes, o que garante que o significado de uma parte pode ser determinado a partir da própria parte e da especificação da qual ela depende, não sendo necessário quaisquer outras informações. Uma flecha pontilhada de A para S significa uma dependência fraca; ela expressa que A depende apenas da existência de uma parte que satisfaça à especificação S, mas que, na verdade, não possui dependência de nenhum detalhe de S. Uma flecha com a ponta fechada de uma parte de implementação A para uma parte de especificação S expressa que A satisfaz S; seu significado está em conformidade com o significado de S. Graças ao fato de que as especificações são tão essenciais, nós iremos sempre assumir que elas estão presentes. Na maioria das vezes, nós não iremos desenhar partes de especificação explicitamente, portanto, uma flecha de dependência entre duas partes A e B deve ser interpretada como uma dependência de A para a especificação de B, e como uma flecha de conformidade de B para sua especificação. Nós iremos demonstrar as interfaces do Java como partes de especificação explicitamente. 1 O termo package será utilizado como sinônimo de pacote com a intenção de se criar familiaridade com os termos da linguagem Java. 30

2 3.2 Java Namespace Como qualquer grande trabalho escrito, um programa se beneficia de uma organização estrutural hierárquica. Quando se tenta compreender uma grande estrutura, é sempre útil observá-la de baixo para cima, iniciando-se com os níveis mais grosseiros da estrutura e procedendo-se para níveis mais e mais detalhados. O sistema de nomes do Java suporta esta estrutura hierárquica. E promove também um outro importante benefício. Componentes diferentes podem usar os mesmos nomes para seus subcomponentes, com distintos significados locais. No contexto do sistema como um todo, os subcomponentes terão nomes que são determinados pelos componentes dos quais eles pertencem, evitando confusões. Isto é vital, pois permite aos desenvolvedores trabalharem independentemente sem se preocupar com conflitos de nomes. Agora apresentaremos como o sistema de nomes do Java funciona. Os componentes principais são as classes e as interfaces, que possuem designações de nomes de métodos e de nomes de campos. Variáveis locais (dentro de métodos) e argumentos de métodos também são designados. Cada nome em um programa Java possui um escopo, ou abrangência: uma porção do texto do programa dentro da qual aquele nome é válido e atado àquele componente. Argumentos de métodos, por exemplo, têm o escopo do método; campos têm o escopo da classe, e às vezes um escopo ainda maior. O mesmo nome pode ser usado para referenciar coisas diferentes quando não há ambigüidade. Por exemplo, é possível utilizar-se o mesmo nome para um campo, um método e uma classe; consulte a especificação (spec) da linguagem Java para obter exemplos. Um programa Java é organizado em packages, ou pacotes. Cada classe ou interface possui seu próprio arquivo (desconsiderando-se inner classes, ou classes internas, que não serão discutidas). Os packages refletem a estrutura de diretórios. Da mesma forma que diretórios, packages podem ser aninhados em estruturas de profundidades arbitrárias. Para organizar seu código em packages, você deve fazer duas coisas: primeiro, você indica no topo de cada arquivo a quais packages esta classe ou interface pertence e, segundo, você organiza os arquivos fisicamente em uma estrutura de diretórios de forma que eles estejam de acordo com a estrutura dos packages. Por exemplo, a classe dnj.browser.protocol seria um arquivo chamado Protocol.java no diretório dnj/browser. Pode-se demonstrar esta estrutura no nosso diagrama de dependências. As classes e interfaces formam as partes entre as quais as dependências são esquematizadas. Packages são mostrados como contornos englobando estas classes e interfaces. Às vezes é conveniente esconder as dependências exatas entre as partes de diferentes packages e apenas mostrar um arco de dependência no nível dos packages. Uma dependência de um package significa que alguma classe ou interface (podem ser várias) daquele package possui uma dependência; uma dependência sobre um package significa 31

3 uma dependência de uma classe ou interface (podem ser várias também) que pertence àquele package. 3.3 Controle de Acesso Os controles de acesso do Java permitem que se controlem as dependências. No texto de uma classe, é possível indicar quais outras classes podem ter dependências sobre ela, desta forma, é possível, até certo grau, controlar a natureza das dependências. Uma classe declarada como public pode ser referenciada por quaisquer outras classes; do contrário, ela só pode ser referenciada por classes dentro do mesmo package. Portanto, através deste modificador podemos evitar dependências de qualquer outra classe que pertença a outro package. Membros de uma classe isto é, seus campos e métodos podem ser marcados como public, private ou protected. Um membro public pode ser acessado de qualquer lugar. Um membro private só pode ser acessado de dentro da classe onde é declarado. Um membro protected pode ser acessado de dentro do package, ou de fora do package por uma subclasse 2 da classe onde o membro é declarado criando, portanto, um efeito há muito conhecido de que um membro protected émais acessível, ao invés de menos acessível, como a idéia de proteção presume. Recorde-se que uma dependência de A sobre B significa uma dependência de A sobre a especificação de B. O uso de métodos modificadores entre os membros de B nos permitem controlar a natureza das dependências ao alterar-se quais membros pertencem à especificação de B. O controle do acesso aos campos de B é uma ajuda para se alcançar independência de representação, mas nem sempre uma garantia (como veremos adiante no curso). 2 O termo subclasse, utilizado no decorrer do texto, refere-se à prática de derivação de classes da programação orientada a objetos. 32

4 3.4 Linguagens Seguras Uma propriedade chave de um programa é a de que uma parte só deveria depender de outra se o fizermos explicitamente referenciando a outra parte através de seu nome. Isto parece óbvio, mas, de fato, esta é uma característica válida apenas para as chamadas linguagens de programação seguras. Em linguagens não seguras, o texto em uma parte pode afetar o comportamento de outra sem que nomes sejam compartilhados. Isto nos leva aos chamados bugs traiçoeiros que são dificílimos de se detectar, e que podem ocasionar efeitos desastrosos e imprevisíveis. Veja como eles surgem. Considere um programa escrito em C no qual um módulo (em C é apenas um arquivo) faz a atualização de um array. Uma tentativa de se definir o valor de um elemento de um array além de seus limites às vezes irá falhar, pois causa uma violação de memória, atingindo uma área de memória além daquela definido para o processo. Mas, infelizmente, na maioria das vezes isso irá funcionar, e o resultado será a escrita de um pedaço arbitrário de memória arbitrário, pois o programador não sabe como o compilador alocou a memória do programa, e não pode predizer quais outras estruturas de dados foram afetadas. Como resultado, uma atualização do array a pode afetar o valor de uma estrutura de dados com o nome d, por exemplo, que é declarada em um módulo diferente e que nem mesmo possui um tipo em comum com a. Linguagens seguras controlam estes efeitos através de diversas técnicas combinadas. Checagem dinâmica de limites de arrays previnem o tipo de atualização que acabamos de mencionar; em Java uma exceção seria lançada. O gerenciamento automático de memória garante que a memória não seja liberada e em seguida, erroneamente, utilizada. Ambas as técnicas baseiam-se na idéia fundamental de tipagem forte, que garante que um acesso declarado como sendo um valor de um tipo t no programa texto será sempre um acesso a uma valor do tipo t em tempo de execução. Não há risco de que código projetado para ser utilizado sobre arrays seja aplicado a uma string ou a um inteiro. Linguagens seguras surgiram em Algumas famosas linguagens seguras incluem Algol-60, Pascal, Modula, LISP, CLU, Ada, ML, e agora Java. É interessante notar que por muitos anos a indústria reclamou que os custos da segurança destas linguagens eram muito altos, e que era inviável migrar de linguagens não seguras (como C++) para linguagens seguras (como Java). Java se beneficiou de muita publicidade a respeito de applets, e agora que a linguagem é largamente utilizada, muitas bibliotecas estão disponíveis e existem muitos programadores que conhecem Java, muitas companhias deram o braço a torcer e estão reconhecendo os benefícios de uma linguagem segura. Algumas linguagens seguras garantem a correção de tipagem em tempo de compilação através de tipagem estática. Outras, como Scheme e LISP, realizam sua checagem de tipo em tempo de execução, sendo que seus sistemas de tipagem apenas distinguem os tipos primitivos. Veremos rapidamente como um sistema de tipagem mais expressivo também pode ajudar no 33

5 controle das dependências. Se a confiabilidade é importante, é sábio utilizar uma linguagem segura. Na aula 1 eu contei uma estória sobre o uso de linguagens não seguras em um sistema de raios-x. 3.5 Interfaces Em linguagens com tipagem estática, podem-se controlar dependências através da escolha de tipos. Pode-se dizer que uma classe que menciona apenas objetos do tipo T não pode ter uma dependência de uma classe que possui objetos de um tipo T diferente. Em outras palavras, pode-se deduzir, a partir dos tipos de uma classe, de quais outras classes esta classe depende. No entanto, em linguagens com subtipos (tipos derivados), uma coisa interessante é possível. Suponha que a classe A mencione apenas a classe B. Isto não significa que apenas métodos criados a partir da classe B possam ser chamados. Em Java, os objetos instanciados a partir de uma subclasse C de B são tidos como tendo também o tipo B, assim, mesmo que A não possa criar objetos da classe C diretamente, ela pode acessá-los por intermédio de outra classe. O tipo C édito serumsubtipodotipob, pois um objeto C pode ser utilizado quando um objeto B é aguardado. Isto é chamado substituibilidade, ou seja, a possibilidade de substituir. Na verdade, a prática de se criar subclasses funde dois princípios distintos. Um é a subtipagem: que define que objetos de uma classe C são tidos como tendo tipo compatível com B, por exemplo. O outro é a herança: que define que o código da classe C pode reutilizar o código de B. Mais adiante neste curso iremos discutir algumas das conseqüências infortúnias de se fundir estes dois princípios, e veremos como a substituibilidade nem sempre funciona, como é de se esperar. Por enquanto, iremos focar no mecanismo de subtipagem apenas, pois é o que importa na nossa discussão. O Java provê uma noção de interfaces que proporciona mais flexibilidade na prática da subtipagem do que o uso de subclasses. Uma interface Java é, na nossa terminologia, uma parte de especificação pura. Ela não contém código executável, é utilizada apenas para se alcançar desacoplamento. Veja como funciona. Ao invés de se ter uma classe A dependente de uma classe B, introduz-se uma classe I. Agora, A menciona I ao invés de B, eb deve satisfazer a especificação de I. É claro que o compilador Java não trabalha com especificações comportamentais: ele apenas checa se os tipos dos métodos de B são compatíveis com os tipos declarados em I. Em tempo de execução, toda vez que A estiver aguardando um objeto do tipo I, umobjetodotipob também é aceito. Por exemplo, na biblioteca Java, há uma classe chamada java.util.linkedlist que implementa listas encadeadas. Se você estiver escrevendo código que exige apenas que um objeto seja uma lista, e não necessariamente que seja uma lista encadeada, deve-se utilizar o tipo java.util.list no seu código, o que é uma interface implementada por java.util.linkedlist. Existem outras classes como ArrayList e Vector que implementam esta interface. Desde que seu código refira-se apenas à interface, ele irá funcionar com qualquer uma destas classes de implementação. 34

6 Várias classes podem implementar a mesma interface, e uma classe pode implementar várias interfaces. Pelo contrário, uma classe pode herdar no máximo uma classe. Por causa disso, algumas pessoas utilizam o termo herança de múltipla especificação para descrever a funcionalidade das interfaces do Java, ao contrário da verdadeira herança múltipla na qual pode-se reutilizar código de múltiplas superclasses. Inicialmente, as interfaces trazem dois benefícios. Primeiro, elas permitem que se expressem partes de pura especificação no código, de forma que seja possível garantir que o uso da classe B por uma classe A envolve apenas uma dependência de A para a especificação S, e não em outros detalhes de B. Segundo, as interfaces permitem criar várias partes de implementação que estejam em conformidade com uma única especificação, sendo que a seleção de qual parte de implementação será usada ocorrerá em tempo de execução. 3.6 Exemplo: Instrumentação de um Programa No restante da aula, iremos estudar alguns mecanismos de desacoplamento no contexto de um exemplo que é pequeno, mas que é representativo de uma importante classe de problemas. Suponha que se queiram reportar os passos incrementais de um programa no decorrer de sua execução, exibindo seu progresso linha por linha. Por exemplo, em um compilador com suas diversas etapas, pode-se desejar exibir uma mensagem quando cada etapa começa e termina. Em um cliente de , podemos exibir cada um dos passos envolvidos na tarefa de se fazer o download dos s a partir de um servidor. Este tipo de mecanismo de acompanhamento da execução é útil quando os passos individuais podem levar um longo tempo de execução ou quando são propensos à falha (de forma que o usuário possa cancelar o comando que originou a execução). Barras de progresso são muitas vezes utilizadas neste contexto, mas elas introduzem complicações adicionais com as quais não iremos nos preocupar. Como um exemplo concreto, considere um cliente de que possua um package principal (core) contendo uma classe Session com código projetado para estabelecer uma sessão de comunicação com um servidor e para fazer o download de mensagens, uma classe Folder para os objetos que modelam pastas e seu conteúdo, e uma classe Compactor que contém o código para compactar a representação das pastas no disco. Assuma que há chamadas de Session para Folder e de Folder para Compactor, assuma ainda que as intensas atividades de recursos computacionais que queremos instrumentar ocorrem apenas em Session e Compactor, enãoemfolder. O módulo diagrama de dependência mostra que Session depende de Folder, que possui uma dependência mútua de Compactor. 35

7 Iremos analisar uma variedade de meios para implementar nosso mecanismo de instrumentação, e iremos estudar as vantagens e desvantagens de cada. Começando pelo mais simples, mais ingênuo projeto possível, podemos distribuir sentenças como System.out.println ( Iniciando download ); ao longo do programa Abstração por parametrização O problema com este esquema é óbvio. Quando rodamos o programa em modo batch, podemos redirecionar a saída de dados padrão do programa para um arquivo. Percebemos, então, que isto seria útil para gerar mensagens acrescidas da informação do momento quando elas ocorreram, de maneira que poderíamos mais tarde, quando lermos o arquivo de mensagens, saber quanto tempo durou cada um dos vários passos executados. Desejamos que nossas sentenças sejam da forma System.out.println ( Iniciando download em: + new Date ()); O que deveria ser fácil, mas não é. Temos que procurar todas as sentenças presentes em nosso código (e distinguí-las de outras chamadas a System.out.println destinadas a outros propósitos), e alterar cada uma delas separadamente. É claro, o que deveríamos ter feito é definir um procedimento para encapsular esta funcionalidade. Em Java, seria feito através de um método estático: public class StandardOutReporter { public static void report (String msg) { System.out.println (msg); Agora, a alteração pode ser realizada em um único local no código. Apenas modificamos o 36

8 procedimento para public class StandardOutReporter { public static void report (String msg) { System.out.println (msg + at: + new Date ()); Matthias Felleisen chama isso de princípio do ponto de controle individual. O mecanismo neste caso é um com o qual você deve estar familiar: o curso 6001 o chama de abstração por parametrização, pois cada chamada ao procedimento, tal como StandardOutReporter.report ( Iniciando download ); é uma instância da descrição genérica, com o parametrizador msg atado a um valor particular. Podemos ilustrar o ponto de controle individual em um diagrama de dependência modular. Introduzimos uma única classe da qual as classes que utilizam o mecanismo de instrumentação dependem: StandardOutReporter. Perceba que não há dependência de Folder para StandardOutReporter, pois o código de Folder não faz chamadas para esta outra classe Desacoplamento com Interfaces No entanto, este esquema está bem longe da perfeição. Automatizar a funcionalidade em uma única classe foi uma boa idéia, mas o código ainda possui uma dependência na noção de escrita para a saída de dados padrão. Se quiséssemos criar uma nova versão do nosso sistema com uma interface gráfica de usuário (GUI), precisaríamos substituir esta classe com uma outra contendo o código apropriado para a GUI. Isto significaria alterar todas as referências no package core para uma classe diferente, ou alterar o código da própria classe, e ter que manipular duas versões incompatíveis da 37

9 classe com o mesmo nome. Nenhuma das duas é uma boa opção. De fato, o problema é pior do que isso. Em um programa que utiliza GUI, escreve-se para a GUI através de uma chamada a um método de um objeto que representa parte da interface gráfica: um painel de texto, ou um campo de mensagem. Em Swing, o toolkit de interfaces de usuário do Java, as subclasses de JTextComponent possuem um método settext. Dado um componente JTextComponent representado pela variável outputarea, por exemplo, a sentença de exibição poderia ser: outputarea.settext (msg) Como vamos passar a referência para o componente na posição de chamada (na nova classe StandardOutReporter)? E como vamos fazê-lo sem introduzir código específico do Swing na classe responsável por reportar os progressos da execução do programa? As interfaces Java provêm a solução. Criamos uma interface com um único método para reportar os progressos de execução que será chamado para exibição dos resultados. public interface Reporter { void report (String msg); Agora, acrescentamos a cada método do nosso sistema um argumento deste tipo. A classe Session, por exemplo, pode ter um método download: void download (Reporter r, ) { r.report ( Iniciando download ); Agora definimos uma classe que irá implementar o comportamento do método report. Iremos utilizar a saída de dados padrão como nosso exemplo, por razões de simplicidade: public class StandardOutReporter implements Reporter { public void report (String msg) { System.out.println (msg + at: + new Date ()); 38

10 Esta classe não é a mesma classe que a anterior, e que possuía o mesmo nome. O método não é mais estático, de maneira que podemos instanciar um objeto da classe e chamar o método a partir dele. Além do mais, indicamos que esta classe é uma implementação da interface Reporter. Éclaro, para a saída de dados padrão esta solução não parece ser muito boa, e a criação do objeto implica em um custo computacional. Mas, para o caso da GUI, iremos fazer algo mais elaborado e criar um objeto que esteja atado ao mecanismo JTextComponent em particular. public class JTextComponentReporter implements Reporter { JTextComponent comp; public JTextComponentReporter (JTextComponent c) {comp = c; public void report (String msg) { comp.settext (msg + at: + new Date ()); No topo do programa, iremos criar um objeto e passá-lo: s.download (new StandardOutReporter (), ); Onde s representa uma instância da parte (ou classe) Session. Agora, alcançamos algo interessante. A chamada ao método report executa, em tempo de execução, código que invoca System.out. Mas métodos como o download da classe Session dependem apenas da interface Reporter, que não faz referência a nenhum mecanismo de saída de dados específico. Conseguimos, com sucesso, desacoplar o mecanismo de saída de dados e o programa, quebrando a dependência do núcleo do programa de seus dispositivos de saída de dados (seu I/O). Observe o diagrama de dependência modular. Recorde-se que uma flecha com a cabeça fechada de A para B é lida como A satisfaz B. B pode ser uma classe ou uma interface; o relacionamento em Java pode ser de implementação ou de extensão. Aqui, a classe StandardOutReporter satisfaz a interface Reporter. A propriedade chave do esquema é que não há mais uma dependência de nenhuma classe do package núcleo (core) sobre uma classe do package gui. Todas as dependências apontam (pelo menos logicamente!) de gui para core. Para alterar a saída de dados do programa para um mecanismo GUI, ao invés da saída de dados padrão, teríamos apenas que substituir a classe StandardOutReporter pela classe JTextComponentReporter, e modificar o código da classe principal do package GUI para chamar seu construtor nas classes que contém código de I/O concreto. Este idioma, esta maneira de se fazer as coisas, talvez seja o uso mais popular das 39

11 interfaces, sendo muito valioso seu aprendizado e domínio. Lembre-se que as flechas pontilhadas são dependências fracas. Uma dependência fraca de A para B significa que A referencia os nomes de B, mas não referencia o nome de nenhum de seus membros. Em outras palavras, A sabe que a classe ou interface B existe, e refere-se a variáveis daquele tipo, mas não faz chamadas a nenhum método de B, e nem acessa qualquer campo de B. A dependência fraca de Main sobre Reporter simplesmente indica que a classe Main pode incluir código que manipula um objeto do tipo Reporter genérico; não se trata de um problema. A dependência fraca de Folder sobre Reporter, no entanto, é um problema: o objeto do tipo Reporter deve ser passado através de métodos de Folder para métodos de Compactor. Todo método da cadeia de chamadas que alcança um método instrumentado deve receber um Reporter como argumento. O que é um incomodo, e que pode tornar doloroso um processo posterior de aperfeiçoamento deste esquema Interfaces vs. Classes Abstratas Você deve estar se perguntando se poderíamos ter utilizado uma classe abstrata ao invés de uma interface. Uma classe abstrata é uma classe que não está completamente implementada; ela não pode ser instanciada, ela deve ser estendida através de uma subclasse que a completa. Classes abstratas são úteis quando se deseja produzir código comum a várias classes. Suponha que quiséssemos exibir uma mensagem dizendo quanto tempo cada passo da execução levou. Nós 40

12 podemos implementar uma classe Reporter cujos objetos mantém o estado no qual estavam quando da última chamada ao método report, calculando, então, a diferença de tempo entre a chamada corrente e a última chamada. Ao tornar esta classe abstrata, poderíamos reutilizar o código em cada uma das subclasses concretas StandardOutReporter, JTextComponentReporter, etc. Por que não fazer com que o argumento do método download da classe Session tenha esta classe abstrata como seu tipo, ao invés de uma interface? Há duas razões. A primeira é que desejamos que a dependência sobre o código de Reporter seja a mais fraca possível. A interface não possui código nenhum; ela expressa a especificação mínima do que é necessário. A segunda razão é que não há herança múltipla em Java: uma classe pode estender no máximo uma única outra classe. Portanto, quando você estiver projetando o núcleo do programa, você não quer utilizar sua única oportunidade de utilizar o recurso de subclasses prematuramente. Uma classe pode implementar qualquer número de interfaces, ou seja, ao escolher uma interface, você deixa por conta do projetista das classes Reporter a questão de como elas serão implementadas Campos Estáticos A desvantagem clara do esquema discutido na seção é que o objeto Reporter deve ser inserido por todo o núcleo do programa. Se toda a saída de dados for exibida em um único componente de texto, parece ser não muito bom ter que passar uma referência a este objeto pra lá e pra cá dentro do código. Em termos de dependência, todo método possui, no mínimo, uma dependência fraca sobre a interface Reporter Variáveis globais, ou campos estáticos em Java, provêm uma solução para este problema. Para eliminar muitas destas dependências, nós podemos manter o objeto do tipo Reporter como um campo estático de uma classe: public class StaticReporter { static Reporter r; static void setreporter (Reporter r) { this.r = r; static void report (String msg) { r.report (msg); Agora, tudo que precisamos fazer é definir o objeto Reporter estático no início: 41

13 StaticReporter.setReporter (new StandardOutReporter ()); E podemos fazer chamadas para ele sem a necessidade de uma referência para um objeto: void download ( ) { StaticReporter.report ( Iniciando download ); No diagrama de dependência modular, o efeito desta alteração é que agora apenas as classes que realmente utilizam o objeto do tipo Reporter são dependentes dela: Perceba agora que a dependência fraca de Folder não existe mais. Nós já vimos este conceito antes, é claro, no nosso segundo esquema no qual a classe StandardOutReporter possuía um método estático. Este esquema combina o aspecto estático com o desacoplamento que as interfaces providenciam. As referências globais são cômodas, pois lhe permitem alterar o comportamento de métodos em níveis bem baixos da hierarquia de chamadas sem a necessidade de alteração do código que os envoca. Mas as variáveis globais são perigosas. Elas podem tornar o código extremamente difícil de ser compreendido. Para se determinar o efeito de uma chamada a StaticReporter.report, por exemplo, é necessário saber como o campo estático r está definido. Pode haver uma chamada ao método setreporter em qualquer lugar no código, e para se definir qual efeito ela tem, é necessário traçar o fluxo da execução para se determinar quando o método é executado em relação ao código de interesse. 42

14 Outro problema com relação às variáveis globais é que elas apenas funcionam bem quando realmente há um objeto que possui significado persistente. A saída padrão de dados é um destes casos. Mas componentes de texto em uma GUI não são. Nós podemos, muito bem, desejar que diferentes partes de nosso programa reportem seu progresso a diferentes painéis da nossa GUI. No esquema em que os objetos do tipo Reporter são passados de uma parte para outra do código, nós podemos criar diferentes objetos e passá-los a diferentes partes do código. Na versão estática, teremos que criar métodos diferentes, o que começa a degenerar a elegância do código. Concorrências também ocasionam dúvidas na idéia de se usar um único objeto. Suponha que façamos o upgrade de nosso cliente de para que seja capaz de fazer o download das mensagens a partir de diversos servidores de forma concorrente, isto é, ao mesmo tempo. Nós não gostaríamos que as mensagens de progresso de todas as sessões de download fossem intercaladas em uma única saída de dados. Uma boa prática é ser cuidadoso com variáveis globais. Pergunte a você mesmo se é possível utilizar um mesmo objeto. Normalmente, você irá encontrar amplas razões para ter mais do que um objeto no decorrer de seu programa. Este esquema é denominado Singleton na literatura, pois a classe possui um único objeto. 43