Esse artigo faz parte da revista SQL Magazine edição 46. Clique aqui para ler todos os artigos desta edição

= o ns = "urn:schemas-microsoft-com:office:office" />

Podar uma árvore nunca foi tão simples

 

No artigo anterior, fizemos um overview sobre padrões de projetos, passando por anti-padrões e boas práticas de programação.

Apesar do título, esse artigo não tem uma abordagem ecológica. Na verdade, esse título faz referência a um Design Pattern, conhecido como Composite. Para entender melhor, recomendo que prossiga nessa leitura.

 

A composição

Vamos usar a criatividade. Imagine a interface de um sistema. A Figura 1 ilustra uma tela de cadastro de um sistema qualquer.

 

 

Figura 1. Tela de um sistema qualquer.

 

Observe que a Figura 1 ilustra uma janela contendo uma série de componentes, tais como: Labels, Radios, Panels, Tabs, TextFields, CheckBoxes, Menus, dentre outros. Não é difícil perceber que, alguns desses elementos estão contidos em outros, ou seja, formando uma estrutura de árvore. Por exemplo, o componente mais externo, a janela, contém todos os outros. A Tab Dados, contem dois Textfields e um Panel. Esse, por sua vez, contém dois Checkboxs, e assim sucessivamente. A Figura 2 esboça a estrutura de árvore, formada pela organização dos elementos de tela da Figura 1.

 

Figura 2. Estrutura hierárquica dos componentes.

 

Como existem elementos contidos em outros, e esses podem possuir suas próprias ramificações, dizemos que se trata de uma estrutura de dados, conhecida como árvore. Contudo, para que essas ramificações sejam possíveis, cada elemento deve possuir uma lista dos elementos que contem, ou seja, seus objetos filhos.

A Listagem 1 esboça uma primeira solução, codificando o método desenha() das classes Janela e Panel.

 

...

Quer ler esse conteúdo completo? Tenha acesso completo