Um Estudo sobre Padrões de Projeto Aplicados a Garbage Collection

Um Estudo sobre Padrões de Projeto Aplicados a Garbage Collection Cássio Frederico Moreira Druziani 1, Ailton Sergio Bonifácio 1, Yandre Maldonado e Gomes da Costa 1, Alberto Ângelo Fabris 2 1 Instituto de Informática Universidade Federal do Rio Grande do Sul (UFRGS) Caixa Postal 15.064 91.501-970 Porto Alegre RS Brazil 2 Faculdade de Ciências Sociais Aplicadas de Cascavel (UNIVEL) Av. Titto Muffato, 2317, Bairro Santa Cruz 85806-080 Cascavel PR Brazil druziani@inf.ufrgs.br, ailton@uel.br, yandre@mar.sol.com.br, alberto@unioeste.br Abstract. This paper objective to show the project standards concepts, being emphasize out its great importance and applicability in the software area. A case study it is carried through on four different applied project standards to the Garbage Collector. This paper is divided of the following form: in section 1, the basic concepts on Patterns and Design Patterns with emphasis in the solutions of project for software are introduced; in section 2 the Garbage Collector is described, in whose solution the use of standards can be applied; in section 3 the four standards used in the solution are described on the proposal solution: adapter, facade, iterator and proxy and; in the fourth and last section is described an a proposal of standards application on the solution of the described problem in section 2. Resumo. Este artigo tem como objetivo conceituar padrões de projetos, ressaltando sua grande importância e aplicabilidade na área de software. É realizado, também, um estudo de caso sobre quatro diferentes padrões de projeto aplicados ao Garbage Collector. O trabalho está dividido da seguinte forma: na seção 1, são introduzidos os conceitos básicos sobre Patterns e Design Patterns com ênfase nas soluções de projeto para software; na seção 2 é descrito o Garbage Collector, em cuja solução pode-se aplicar o uso de padrões; na seção 3 são descritos os quatro padrões utilizados na solução proposta: adapter, facade, iterator e proxy e; na quarta e última seção é descrita uma proposta de aplicação de padrões na solução do problema descrito na seção 2. 1. Introdução O uso atual do termo padrão é derivado das escritas do arquiteto Christopher Alexander que escreveu vários livros com tópicos relacionados à construção, planejamento e arquitetura urbana. Em qualquer ciência ou engenharia é fundamental o uso de um vocabulário comum para expressar seus conceitos, e uma linguagem para relacioná-los. O objetivo do uso de padrões dentro da comunidade de software é criar um conjunto de literatura para ajudar o desenvolvedor de software a solucionar problemas encontrados

periodicamente ao longo de todo o desenvolvimento do software. Os padrões ajudam a criar uma linguagem compartilhada para comunicar experiências sobre estes problemas e suas soluções. A classificação formal destas soluções e suas relações nos permitem capturar o conjunto de conhecimentos que define nossa compreensão das melhores arquiteturas que satisfazem as necessidades dos usuários. O enfoque primário dos padrões não está tanto na tecnologia e sim em criar uma cultura para documentar e apoiar engenharia de arquiteturas e projetos. Cada pattern descreve em uma forma literária um problema que ocorre várias vezes no nosso ambiente e então descreve o núcleo da solução deste problema, de tal forma que podemos utilizar esta solução inúmeras vezes, gerando resultados diferentes a cada vez [Alexander 1977]. Tal linguagem de patterns permite a qualidade, que não pode ser fabricada, mas apenas gerada, indiretamente, pelas ações das pessoas. James Coplien [Coplien 1996] descreveu as seguintes considerações sobre a definição de pattern, referindo-se várias vezes às definições originais de Alexander [Alexander et.al. 1979, p.247]: Um pattern é uma peça de literatura que descreve um problema de desenho e uma solução geral para o problema em um contexto particular. Alexander define: cada pattern é uma regra com três partes, que expressam a relação entre um certo contexto, um problema e uma solução [Alexander 1979]. Um pattern, em resumo, é ao mesmo tempo uma coisa, que acontece no mundo, e a regra que nos diz como criar esta coisa, e quando devemos cria-la. Ele é tanto o processo como a coisa; tanto a descrição de uma coisa que está viva, e a descrição do processo que gera esta coisa. Em [Appleton 1999] Dirk Riehle e Heinz Zullighoven dão uma definição do termo pattern que é amplamente utilizada: Um pattern é a abstração de uma forma concreta que continua ocorrendo periodicamente em contextos não abstratos específicos. Ainda em [Appleton 1999] Richard Gabriel define de forma clara e concisa o termo pattern: Cada pattern é uma regra de três partes que expressa uma relação entre um certo contexto, um certo sistema de forças que acontecem repetidamente naquele contexto, e uma certa configuração de software que permite solucionálos. O uso de patterns permite o reuso de software que em geral tem sido um objetivo primordial em engenharia de software. A própria utilização do termo reuso (ou reutilização) é uma demonstração do quanto reuso é essencial e também do quanto ele não está sendo atingido. Para atingir este objetivo, uma engenharia utiliza conhecimentos científicos sobre domínios tecnológicos que estão codificados de uma forma que seja diretamente útil para um engenheiro. Deste modo este conhecimento codificado provê respostas para questões que ocorrem comumente na prática. Ou seja, este conhecimento deve ser reutilizado para a geração de soluções.

1.1 Design Patterns O termo Projeto de Padrões ou Design Patterns, é um mecanismo novo para expressar estruturas de projeto. Preservam informações de projeto abstraindo o que há por trás de um projeto. Eles identificam classes, instâncias, os papéis dos projetos, colaborações e a distribuição de responsabilidades. Design Patterns têm muita utilidade no processo de desenvolvimento de projetos orientados a objeto [Appleton 1999]: provêem um vocabulário comum para projetistas se comunicarem, documentarem, e explorarem alternativas de projeto. Eles reduzem complexidade de sistema nomeando e definindo abstrações que estão sobre classes e instâncias. Um bom conjunto de Design Patterns, com certeza eleva o nível de qualquer programa; constituem uma base reutilizável de experiência para construção de software reutilizável. Eles dispõem de meios para usar o conhecimento adquirido por projetistas mais experientes, agem como pequenos blocos de projeto que juntos constróem projetos mais complexos; eles são micro-arquiteturas que contribuem para a construção de uma arquitetura de sistema global; ajudam a reduzir o tempo de aprendizagem para uma biblioteca de classe. Uma vez que se tenha aprendido sobre um Design Pattern em uma biblioteca, o projetista pode reusar esta experiência quando aprender sobre uma nova classe; ajudam o projetista inexperiente a desenvolver como um projetista experiente; provêem um objetivo para a reorganização ou remanufatura de hierarquias de classe. 1.1 Categoria de Design Patterns Design Patterns variam na sua granularidade e no seu nível de abstração. Eles são numerosos e têm propriedades comuns. Existem muitos padrões de projeto, por isso precisamos de um modo para organizá-los. Na tabela 1 abaixo é demonstrado um sistema de classificação para padrões de projeto. Tabela 1. Organização dos Padrões de Projeto Escopo Criação Estrutura Comportamento Classe Factory Method Adapter (classe) Interpreter Template Method Objeto Fonte: [Gamma 1994] Abstract Factory Builder Prototype Singleton Adapter (objeto) Bridge Composite Decorator Facade Flyweight Proxy Chain of Responsibility Command Iterator Mediator Memento Observer State Strategy Visitor 2. Estudo de Caso Garbage Collection é a recuperação automática de recursos, normalmente na memória principal, usando o nível de linguagem. Garbage Collectors (Coletores de Lixo) são escritos tradicionalmente em assembler, tornando-os difíceis de otimizar, difíceis de

portar ou reusar entre sistemas operacionais ou outras linguagens. O problema é como reusar Garbage Collectors e seus diferentes algoritmos. Vários algoritmos foram desenvolvidos desde os anos 70. Muitos dos quais, algoritmos de localização; isto é, eles localizam ponteiros entre objetos na pilha a fim de encontrar os que não mais são utilizados pela aplicação. Uma alternativa para a implementação disto, é assegurar o uso de Design Patterns para a família de algoritmos dos Garbage Collectors. O algoritmo Mark-and-Sweep (Varredura) é o algoritmo original de localização. Algoritmos incrementais dividem a coleta através de muitos incrementos pequenos, a fim de evitar uma pausa longa, o suficiente para os usuários notarem. Algoritmos de compactação movem objetos na memória para desfragmentá-los. Coletores Semi-Space e Geradores dividem objetos por idade, permitindo o enfoque para os objetos mais novos [Wilson 1992]. Alguns Coletores foram examinados como um passo na aquisição de domínio de conhecimento. Este artigo consiste em utilizar Design Patterns [Gamma 1994] como ferramenta para capturar este domínio de conhecimento pertinente. Os padrões utilizados para tal tarefa são o Adapter, Facade, Iterator e o Proxy; cada qual com sua utilização específica em Garbage Collectors. 3. Design Patterns Abordados O objetivo deste padrão é permitir que interfaces incompatíveis se comuniquem. Este padrão também é conhecido como Wrapper e, convertendo a interface de uma classe, pode torná-la reutilizável fazendo com que esta corresponda à interface requerida por uma aplicação. 3.1 Padrão Adapter - Estrutural de classes e de objetos O uso do Adapter é recomendado quando se deseja usar uma classe já pronta, cuja interface não é a desejada. Quando desejado usar várias subclasses cujas interfaces não correspondem a desejada, neste caso pode-se aplicá-lo para adaptar a interface da classe mãe ou ainda para se criar uma classe reutilizável que coopera com classes cujas interfaces podem não ser compatíveis. 3.2 Padrão Facade - Estrutural de objetos O Facade torna o uso de um subsistema mais fácil, oferecendo uma interface unificada, de nível mais alto, para o conjunto de interfaces do mesmo. Uma das possíveis alternativas a se seguir quando se deseja reduzir a complexidade de um sistema é estruturá-lo em subsistemas. O padrão Facade é utilizado exatamente para tornar menor a comunicação e a dependência entre sistemas, que é um dos objetivos de um projeto. Pode-se identificar algumas situações nas quais o uso do padrão Facade se torna interessante. Uma delas é quando se deseja obter uma visão simples de um subsistema complexo. A complexidade tende a aparecer nos subsistemas à medida que os mesmos evoluem. Entretanto, é comum que muitos detalhes envolvidos nesta complexidade não interessem a muitos clientes do sistema. Neste sentido, o uso de uma fachada (Facade)

pode omitir detalhes (que podem ser vistos pelos clientes que necessitem de uma maior customização) fornecendo uma visão simples do sistema. Outra aplicação interessante do Facade é sua utilização entre camadas de subsistemas definindo o ponto de entrada dos níveis. Se os subsistemas forem independentes, pode-se estabelecer esta comunicação através de fachadas. Pode-se lembrar ainda uma outra situação na qual o uso de fachada (Facade) seria recomendável. Este padrão pode ser usado para favorecer a independência e a portabilidade entre sistemas quando for preciso desacoplar o subsistema dos clientes e dos outros subsistemas, nos casos em que houver muita dependência entre clientes e classes de implementação de uma abstração. Em relação às colaborações, é importante lembrar que a fachada fica entre o subsistema e o cliente, de forma que as solicitações advindas do cliente passam pela fachada que as repassa para os objetos do sistema. Assim, os objetos do subsistema não são acessados diretamente pelos clientes, e freqüentemente a fachada tem o papel de traduzir a interface destes objetos para as interfaces de subsistemas. 3.3 Iterator Pattern - Comportamental de objetos Também chamado de cursor, este padrão procura possibilitar uma forma de acesso seqüencial aos elementos de um objeto sem expor sua representação interna. O padrão Iterator permite percorrer um objeto agregado, como uma lista, de diferentes formas sem que seja necessário acrescentar à interface da lista as operações pertinentes a cada percurso diferente. Um objeto Iterator permite transferir a responsabilidade de acesso e percurso do objeto lista chamando-a para si. Ao percorrer uma lista, pode-se deixar a cargo de um objeto Iterator o controle de quais elementos já foram percorridos, isto é, identificar em que ponto da lista encontra-se o acesso. 3.4 Proxy Pattern - Estrutural de Objetos Este padrão também é conhecido como surrogate. Ele fornece um marcador de localização para controlar o acesso a um objeto. A criação e inicialização de um ou vários objetos num determinado momento pode custar um tempo significativo. Assim, visando não comprometer o desempenho geral da aplicação pode-se adiar o custo integral de criação e inicialização de um objeto até o instante em que isto seja imprescindível. Desta forma, a idéia é criar objetos caros sob demanda, quando realmente necessitamos usá-los. Para isto, utiliza-se um Proxy que funciona como um substituto temporário do objeto real. O Proxy assume a instanciação do objeto real quando for necessário. O padrão Proxy aplica-se quando se faz necessária uma referência a um objeto mais versátil, ou sofisticada, do que um simples apontador. Algumas situações onde se pode aplicá-lo são: quando um Virtual Proxy cria objetos caros sob demanda; quando um representante local para um objeto é fornecido por um Remote Proxy num espaço de endereçamento diferente; quando um Protection Proxy controla o acesso para o objeto original.

4. Aplicação dos Padrões: Adapters e Facades Adapters e Facades são comuns em Garbage Collection, e em muitas situações a distinção entre eles não é clara. Funcionalmente, Adapters e Facades provêem tipos de flexibilidade no mesmo ponto, a interface entre a aplicação e o Garbage Collector. Adapters permitem aos subsistemas mudarem a sintaxe de suas interfaces independentemente, enquanto Facades permitem aos subsistemas mudarem as suas decomposições internas independentemente. A diferença chave entre um Facade e um Adapter é que o Facade provê uma única interface integrada, pela qual um subsistema inteiro ou grupos de objetos podem ser acessados, enquanto um Adapter provê uma interface alterada para um único objeto para habilitá-lo a executar em um contexto para qual não foi originalmente projetado. 4.1 Adapters Adapters são comuns em gerenciamento de memória. Através de um Adapter, alguns coletores originalmente escritos em linguagem C, podem ser habilitados para serem usados em C++. A maioria dos sistemas operacionais provê um único método de alocar memória empilhada, enquanto linguagens como C provêem uma grande quantidade de chamadas em bibliotecas que alocam memória, cada uma com uma semântica ligeiramente diferente, o que faz os Adapters serem muito úteis. Linguagens como C++, Oberon e Java têm um operador New, com sintaxe divergente, que aloca memória para um objeto. Usando um Adapter um único Garbage Collector pode ser adaptado para aceitar cada linguagem. Intenção: Adaptar a interface entre o Garbage Collector e os componentes de sistemas externos. Motivação: Diferentes linguagens de implementação exigem interfaces ligeiramente diferentes para serviços fornecidos por Garbage Collectors. Solução: Colocar um objeto Adapter entre o coletor e o sistema externo para mediar as suas interações. Aplicabilidade: Seja onde for, o Garbage Collector pode ser usado com várias versões de um sistema, ou vários sistemas, ao qual vão precisar de pequenas diferenças na interface. Estrutura: Aplicação new() Adapter Collector malloc( ) Figura 1. Estrutura do Adapter e Collector Participantes: Aplicação - usa os serviços de Collector; a sintaxe das interações com Collector pode variar. Collector - oferece serviços de gerenciamento de memória para Aplicação. Pode ser usado com um variedade de Aplicações, ou várias

versões da mesma Aplicação, cada qual com uma diferente interação de sintaxe. Adapter - faz a mediação de todas as interações entre um Collector e uma Aplicação. Colaborações: o seguinte diagrama de interação mostra um Adapter que faz a mediação entre uma aplicação em C++ e um Collector em C. Aplicação Adapter Collector new(blarg malloc (sizeof(blarg) ) Figura 2. Diagrama de interação entre Adapter e Collector Conseqüências: como todas as interações entre o Garbage Collector e o sistema externo é mediado pelo adaptador, a sintaxe de Garbage Collector ou sistema pode mudar com uma mudança externa, que é limitada ao adaptador. Implementação: geralmente o Adapter é implementado como uma capa ao redor do Garbage Collector. 4.2 Facade Facades são usados para capturar a interface de um sistema (ou subsistema), simplificar a visão exterior do sistema e ocultar mudanças internas do sistema de seus usuários. Além disso, Facades protegem os subsistemas internos de consultas e manipulações indesejadas feitas pelos usuários. Esta combinação lhes permite proporcionar encapsulamento ao nível de pacote, semelhante ao que é fornecido ao nível de objeto pela maioria das linguagens de programação orientada a objetos. Em Garbage Collector, Facade é usado, principalmente, entre o subsistema do Garbage Collector e a aplicação do cliente para encapsulamento, conservando o namespace e favorecendo a queda de Garbage Collectors em projetos de sistemas que utilizarão gerenciamento de memórias tradicionais. Intenção: Fornecer uma interface integrada entre o Garbage Collector e componentes externos do sistema.

Motivação: Componentes externos do sistema requerem uma interface estável, imutável e claramente definida, para uma complexa evolução do sistema. Solução: Converter a especificação da interface do Garbage Collector; esconder completamente os detalhes da linguagem do Garbage Collector, e vice-versa. Aplicabilidade: Garbage Collectors que normalmente mudam sua estrutura interna ou sua organização durante sua vida e links externos para objetos dentro desta estrutura, imporiam limitações inaceitáveis na liberdade do projeto. Estrutura: Limites do Subsistema Garbage Collector Aplicação Facade new() sizeof() Algoritmo new() Proxy sizeof() Participantes: Figura 3. Limites do subsistema Garbage Collector Aplicação - utiliza os serviços do Garbage Collector; exige uma interface limpa e simples para o complexo subsistema do Garbage Collector; interage com o Facade como se o subsistema do Garbage Collector fosse um único objeto. Facade - fornece uma interface limpa e simples para o complexo subsistema do Garbage Collector; está ciente de alguns ou de todos os objetos internos dentro do subsistema Garbage Collector; encaminha chamadas a métodos da Aplicação para os objetos internos dentro do subsistema Garbage Collector. Algoritmo e Proxy - objetos dentro do subsistema Garbage Collector. Colaborações: o seguinte diagrama de interação mostra duas chamadas de método a um Facade que está sendo enviado a outros objetos. O primeira chamada do método, sizeof(), é despachado ao Proxy apropriado, baseado no argumento Object. A segunda chamada de método, new(), é despachado sempre ao mesmo objeto, Algoritmo. Conseqüências: A interface do Garbage Collector é reduzida a um único objeto. Implementação: Como sugerida em [Gamma 1994], a aplicação pode ser, mais adiante, desacoplada do coletor, fazendo do Facade uma classe abstrata.

Aplicação Facade Algoritmo Proxy sizeof(object) sizeof() new(size) new(size) Figura 4. Diagrama de interação do método Facade 4.3 Padrão Iterator Iterators são objetos que permitem iteração sobre um objeto agregado (um recipiente) sem expor sua estrutura interna. A ação primária de toda a não referência que possui os Garbage Collectors é executada por uma repetição sobre a pilha. Iterators estão no coração do Garbage Collector e um ciclo do Garbage Collector pode ser visto como uma iteração sobre cada objeto na pilha. Dentre os tipos principais de iterações em Garbage Collector, tem-se: iterações sobre origens o conjunto de ponteiros dentro da pilha externa. Normalmente envolve todos os ponteiros encontrados nas estruturas de dados global e no "runtime stacks" e pode ser difícil de incrementar. Isto acontece uma vez ao começo de cada ciclo do Garbage Collector. iterações sobre ponteiros dentro de um objeto (scanning) - estes são usados para encontrar a quais objetos, um objeto particular se refere. Isto acontece uma vez por objeto alcançável na pilha por ciclo do Garbage Collector e a menos que sejam entradas em ação especiais, isto resulta na geração de números vastos de Iterators. Felizmente, o escopo destes Iterators temporários é muito limitado e seu tempo de vida previsível, eles podem ser reinicializados e reusados. Isto elimina toda a necessidade para criar novos Iterators durante um ciclo do Garbage Collector. Intenção: iteração abstrata, iteração sobre origens, objetos pilha ou referências com um objeto. Motivação: há várias implementações possíveis para pilhas de estruturas de dados, cada uma com suas vantagens e desvantagens, sendo que para tirar vantagem

disto, são exigidas interfaces standards, que podem ser trocadas uma por outra. O Garbage Collector deve possuir uma interface padrão para estas estruturas de dados. Solução: separar a ordem de passagem, mecanismo e estado do resto do sistema, usando um objeto Iterator que contém o estado da iteração, e por qual são executadas todas as ações na iteração. Aplicabilidade: Onde quer que uma estrutura de dados esteja apta a ser cruzada em múltiplas direções, ou quando a implementação da estrutura de dados pode mudar. Estrutura: Iterator hasmoreitems() nextitem() Aggregate Aggregate() Iterator() additem() removeitem() Participantes: Figura 5. Estrutura do Interator Aggregate - um recipiente ou objeto gerador; responsável pela criação, ou redirecionamento de Iterators. Iterator - mantém uma referência ao Aggregate; devido ao grande número de iterações executadas durante a coleta de lixo, pode ser reusado, em lugar de destruí-lo e recriá-lo novamente. Conseqüências: o objeto Iterator extra aumenta overhead, que poderá possuir muitos métodos para trabalharem na otimização. Implementação: em função do alto número de iterações executadas durante o curso da coleta de lixo, a intenção do Garbage Collector é de não usar objetos temporários (desde que o Garbage Collector seja, provavelmente, invocado quando há pouca ou nenhuma memória para a criação deles) e reusar objetos Iterator. Permitindo ser redirecionados para iterar sobre um outro objeto. Um único Iterator por cliente pode ser usado. 4.4 Padrão Proxy Proxies são usados em Garbage Collectors de três maneiras: (i) Para controlar acesso ao objeto que eles guardam. Eles são usados para implementar read-and-write-barriers (barreiras de leitura e escrita) na ausência de memória virtual; (ii) Para ocultar o movimento, a verdadeira localização, ou mudanças no conteúdo ou localização do objeto que eles guardam. Eles podem ser usados para ocultar da aplicação, movimentos da pilha de objetos provocados pelo Garbage Collector; (iii) Para conter a informação do objeto sobre o estado do objeto que eles guardam. Eles podem ser usados em Garbage Collection para armazenar o tipo do objeto. Existem implementações alternativas para cada um deles [Goldberg 1991], mas a informação é comumente armazenada dentro de um Proxy.

Em Garbage Collection, Proxies são implementados de duas maneiras. A primeira, armazenando os Proxies separadamente do objeto em uma área separada de memória (tais particionamentos de memória podem conduzir aos tamanhos máximos das pilhas que são impostas, mas pode aumentar a área de referência no coletor e pode melhorar o caching). A segunda maneira, armazenando o Proxy com o objeto. Esta segunda técnica é usada por gerenciadores tradicionais de memória para linguagens como C e C++, que comumente armazenam alguns bytes de dados imediatamente antes dos objetos cederem à aplicação [Wilson et al. 1995]. Intenção: Fornece um repositório para o estado e funcionalidade do objeto no Garbage Collection. Motivação : O Garbage Collector necessita: uma área para armazenar dados de objeto; um mecanismo de execução para ler ou escrever barreiras; em um Garbage Collector móvel, um mecanismo para ocultar o movimento do objeto. Solução: usar um objeto Proxy para cada objeto de aplicação. A aplicação invoca métodos do objeto Proxy como se ele fosse o objeto atual, e chamada ao método passada no objeto atual. Estrutura: a seguir é apresentado uma estrutura para o Proxy num Garbage Collector: MemoryObject Aplicação Workspace instance( ) memory( ) getreferences( ) _id _tag _type Collector malloc( ) MutatorNode getleft( ) getright( ) setleft( ) setright( ) Participantes: Figura 6. Estrutura do Proxy para um Garbage Collector Workspace - mantém um vetor de MemoryObjects; mantém uma lista de entradas livres do vetor MemoryObject - classe base para todos os objetos alocados da pilha; repositório para dados de objeto (tipo de dados); mantém um índice (_id) em Workspace. Memory indica qual elemento contém a referência para este objeto.

MutatorNode - exemplo de objetos na pilha; duas instâncias acessadas; métodos contendo chamadas ao Collector.writeBarrier(). Collector - representa o restante do coletor; implementa writebarrier, que usa, entre outras coisas, os campos em MutatorNode herdados de MemoryObject. Aplicabilidade: todos Garbage Collectors incrementais e os não incrementais que armazenam dados do objeto. Implementação: tradicionalmente, Proxies são implementados em pacotes de gerenciamento de memória colocando um objeto de alguns bytes entre cada objeto normal da pilha. Estes pequenos objetos são de um tamanho conhecido, e contém dados sobre o objeto seguinte, e poderia ser obtido um ponteiro para estes dados, subtraindose um número fixo de um ponteiro para qualquer objeto da pilha. 5. Conclusão O objetivo do uso de padrões dentro da comunidade de software é criar um conjunto de literatura para ajudar o desenvolvedor de software a solucionar problemas encontrados periodicamente ao longo de todo o desenvolvimento do software. Os padrões ajudam a criar uma linguagem compartilhada para comunicar experiências sobre estes problemas e suas soluções. A classificação formal destas soluções e suas relações nos permitem capturar o conjunto de conhecimentos que define nossa compreensão das melhores arquiteturas que satisfazem as necessidades dos usuários. Cada pattern descreve em uma forma literária um problema que ocorre várias vezes no nosso ambiente e então descreve o núcleo da solução deste problema, de tal forma que podemos utilizar esta solução inúmeras vezes, gerando resultados diferentes a cada vez. Tal linguagem de patterns permite a qualidade, que não pode ser fabricada, mas apenas gerada, indiretamente, pelas ações das pessoas. O uso de patterns permite o reuso de software que em geral tem sido um objetivo primordial em engenharia de software. Os patterns propiciam reuso de soluções bem sucedidas para problemas que se repetem. Isto significa um aumento na produtividade na fase de design. Para projetos que tenham o tipo de estrutura muito complexo, o uso de patterns é uma solução que simplifica a análise provendo uma representação genérica de hierarquias que solucionam problemas da mesma natureza. Empresas que utilizam a filosofia de Design Patterns para projetar software reduzem a distância existente entre projetistas iniciantes e experientes. A criação e utilização de patterns permite perpetuar as experiências de sucesso, bem como reduzir o tempo e o esforço necessários para criar uma cultura para documentar e apoiar engenharia de arquiteturas e projetos. Em grande parte dos Garbage Collectors encontram-se Design Patterns, sendo que em sua maioria eles são similares. Neste artigo foram demonstrados quatro deles. Fica evidenciado, assim, que Garbage Collector é um bom exemplo da importância da utilização dos Design Patterns no auxílio a projetos orientados a objeto.

6. Referências Bibliográficas Alexander, C. (1979) The Timeless Way of Building, Oxford University. Alexander, C. et al. (1977) A Pattern Language, Oxford University. Appleton, Brad. (1999), Patterns and Software: Essential Concepts and Terminology. In: http://www.enteract.com/~bradapp/docs/patterns-intro.htm Coplien, J. O. Software Patterns, SIGS Books, 1996. Gamma, E., Helm, R., Johnson, R. and Vlissides, J. (1994) Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley. Goldberg, B. (1991). Tag-Free Garbage Collection for Strongly Typed Programming Languages. Pages 165-176 of: Proceedings of ACM SIGPLAN '91 Conference on Programming Language Design and Implementation. Wilson, P. R. (1992). Uniprocessor Garbage Collection Techniques. Pages 1-42 of: Bekkers, Y., & Cohen, J. (eds), Proceedings of the 1992 International Workshop of Memory Management. Lecture Notes in Computer Science, no. 637. Springer. Wilson, P., Johnstone, M., Neely, M., & Boles, D. (1995). Dynamic Storage Allocation: ASurvey and Critical Review. In: (Baker, 1995).