Apesar do desenvolvimento de sorftware ser uma ciência exata, muitos desenvolvedores consideram algumas dessas soluções como mágicas devido a sua complexidade. Primeiramente gostaria de salientar que não existe mágica, e sim o emprego metódico de técnicas e princípios para o projeto de software que boa parte dessa “mágica” pode ser atribuído ao polimorfismo.

O que é Polimorfismo?

“Um conceito em teoria de tipo, no qual um nome (como uma declaração de variável) pode denotar objetos de muitas subclasses diferentes que são relacionadas por alguma superclasse comum, assim, qualquer objeto denotado por esse nome tem a capacidade de responder a algum conjunto comum de operações de modos diferentes” (Booch, 2000).
Em outras palavras, possibilita que referências de tipos de classes mais abstratas representem o comportamento das classes concretas que as referenciam, esse comportamento também é conhecido como Generalização-Especialização.

Polimorfismo é uma solução para um problema comum em ciência da computação: “Variação condicional“.
Quando um programa é projetado com lógica condicional de estrutura if-else ou instrução case, quando surgir uma nova variação, ela exigirá uma modificação da lógica desses comandos, freqüentemente em vários lugares. Causando o aumento da complexidade ciclomática e manutenibilidade no sistema e diminuição do reuso de componentes.

Problema: Como tratar alternativas (variações condicionais) com base no tipo? Como criar componentes de software interconectáveis?

Solução: Quando alternativas ou comportamentos relacionados variam segundo o tipo (classe), atribua a responsabilidade pelo comportamento aos tipos para os quais o comportamento varia, usando operações polimórficas.

Exemplificando

Como caso de estudo, vou criar um simples sistema de exame virtual, onde iram existir 2 tipos de questões, numéricas e textos (descritivas).
Abaixo temos o modelo de domínio de nossa aplicação.

namespace Poliformismo
{
    public abstract class Question
    {
        public string Description { get; set; }
        public string Answer { get; set; }
        public bool Correct { get; set; }
 
        public abstract void AssessingAnswer();
    }
 
 
    public class Numeric : Question
    {
        public int CorrectAnswer { get; set; }
 
        public override void AssessingAnswer()
        {
            int number;
 
            bool isNumeric = int.TryParse(Answer, out number);
 
            if (isNumeric)
            {
                Correct = Equals(CorrectAnswer, number);
            }
        }
    }
 
 
    public class Text : Question
    {
        public string CorrectAnswer { get; set; }
 
        public override void AssessingAnswer()
        {
            Correct = Equals(CorrectAnswer.ToUpper(), Answer.ToUpper());
        }
    }
}

Vamos pensar no seguinte problema, as regras de avaliações de respostas para perguntas em texto se diferem das numéricas.
Seguindo o princípio do polimorfismo, devemos atribuir a responsabilidade de quem deve conhecer as regras aos tipos (no nosso caso a classe Text e Numeric ) utilizando operações polimórficas.
Para isso criamos a classe abstrata Question (Questão) é conceito geral, que pode representa qualquer um dos tipos de suas implementações (numérica ou texto).

using System;
using System.Collections.Generic;
 
namespace Poliformismo
{
    public class Exam
    {
        public Exam()
        {
            Questions = new List<question>();
            Questions.Add(new Numeric {Description = "Com quantos anos Nostradamos morreu?", CorrectAnswer = 47});
            Questions.Add(new Text {Description = "Qual a cor do cavalo branco de Napoleão?", CorrectAnswer = "Branco"});
        }
 
        public List</question><question> Questions { get; set; }
        public string Name { get; set; }
        public int Result { get; set; }
 
        public void ShowQuestions()
        {
            foreach (Question question in Questions)
            {
                Console.WriteLine(question.Description);
                string answer = Console.ReadLine();
 
                question.Answer = answer;
                question.AssessingAnswer();
            }
        }
 
        public void ShowResult()
        {
            Console.WriteLine();
            Console.WriteLine();
 
            Console.WriteLine("Correções da avaliação.");
 
            foreach (Question question in Questions)
            {
                Console.WriteLine("A resposta {0} esta: {1}", question.Answer, (question.Correct ? "Certa" : "Errada"));
            }
 
            Console.WriteLine();
            Console.WriteLine();
        }
    }
}
</question>

Reparem que para a classe Exam a manipulação das questões é transparente, nesse nível de abstratação, não importa se é uma questão do tipo numérica ou textual.
No método ShowQuestions quando o usuário digita a resposta, a classe Exam delega a classe Question a responsabilidade de verificar se a mesma esta correta. Assim cada tipo da operação aplica suas regras para validar a pergunta.

namespace Poliformismo
{
    public class Program
    {
        public static void Main(string[] args)
        {
            Exam exam = new Exam {Name = "Carlos Fernando"};
            exam.ShowQuestions();
            exam.ShowResult();
        }
    }
}

Esse princípio traz diversas vantagens para a arquitetura da aplicação. Além de diminuir a complexidade ciclomática da aplicação porque não utilizamos instruções condicionais (if-else) para tratar as variações condicionais (“se for questão do tipo texto ou se for questão do tipo numérica”). Também auxilia na arquitetura, pois facilita a extensão de novas funcionalidades. Se caso em momento futuro surja a necessidade de criar questões de múltiplas escolhas, não teremos que alterar o exame (Exam), e sim implementar uma nova classe onde implemente a abstração de questão.
Nesse exemplo, tratamos alternativas com base no tipo, para soluções de componentes de software interconectáveis, será realizado em um próximo post.

Conclusão

Polimorfismo é um princípio fundamental no projeto e desenvolvimento de um sistema, diminui a complexidade ciclomática de uma aplicação e ainda permite que seja facilmente estendido para tratar novas variações.
Esse princípio deve ser muito bem compreendido por desenvolvedores, pois muitos design patterns utilizam seus conceitos para implementações de soluções.

Padrões relacionados:

• Variações protegidas
• Vários padrões de projetos GOF

Solução: Atribua a responsabilidade a uma classe que representa uma das seguintes escolhas:

• Representa o “sistema global”, um “objeto raiz”, um dispositivo dentro do qual o software está sendo processado, ou um subsistema importante – essas são todas variantes de um controlador fachada (facade controller)
• Representa um cenário de um caso de uso dentro do qual ocorre o evento do sistema, frequentemente denominado TratadoDo<nomedecasodeuso>, CoordenadorDe<nomedecasodeuso> ou SessaoDo<nomedecasodeuso>
  • Use a mesma classe controladora para todos os eventos do sistema do mesmo cenário do caso de uso.
  • Informalmente, uma sessão é uma instância de convenção com um ator. Sessões podem ser de qualquer tamanho, mas frequentemente são organizadas em casos de uso.

Um controlador é o primeiro objeto além da camada de UI que é responsável por receber ou tratar uma mensagem de operação do sistema. Esse é um padrão de delegação, de acordo com a premissa que a camada de UI não deve conter a lógica da aplicação, os objetos da camada de UI precisam delegar essa solicitação a outra camada.

Quando e como utilizar!
Os Controladores Fachada são adequados quando não exitem “demasiados” eventos de sistema.
Nesse caso pode-se optar por Controladores de Caso de Uso para evitar tonar os controladores fachada sobrecarregado com excesso de responsabilidade, evitando a baixa coesão e alto acoplamento.

Em 1967 Ivar Jacobson desenvolve uma metodologia onde existem os conceitos (opcionais) de classes de fronteira, classes de controle e classes de entidade. Os objetos de fronteiras, são abstrações das interfaces. Os objetos de entidade são objetos do domínio. E os objetos de controles são tratadores de caso de uso.

Conceito X Tecnologia
O Princípio Controlador apresentado difere de controladores de tecnologias como ASP.NET MVC, ASP.NET WebForms, Struts (JAVA) entre outras.
O code behind do WebForms ou são tratadores de eventos do navegador, já os controllers (Action) do MVC são controladores de interação e fluxo de página. Estes deveram obter uma referência para objetos controladores do domínio a fim de obter uma Separação Modelo-Visão.

Vantagens

• Aumento da possibilidade de reutilização e de interfaces “plugáveis” – essa vantagem garante que logica de aplicação não seja tratada na interface.
• Melhora a forma de gerenciamento de sobre o estado do caso de uso – permite garantir que uma determinada chamada (método) não irá ocorrer até que outra tenha sido executada.

Padrões Relacionados

• Commando
• Fachada
• Camadas
• Invenção Pura

Problema: Como manter os objetos bem focados, inteligíveis, gerenciavéis e como efeito colateral apoiar o baixo acoplamento?
Solução: Atribuir uma responsabilidade de forma que a coesão permaneça alta.

Em outras palavras, são classes de difícil entendimento e manutenção consequentemente de difícil reutilização, executam atividades que deveriam ser delegadas para outros objetos, ou apresentam um nível de abstração alto.

Para exemplificar vou apresentar uma situação fictícia, de um sistema de atendimento de chamados, e esses atendimentos podem esta relacionados a vários clientes.

Considere a seguinte situação, o usuário adiciona um cliente ao atendimento. O ControladorAtendimento recebe a mensagem, seguindo o princípio criador, ela detêm os dados iniciais de Cliente e se torna uma boa candidata para criar a instância c do Cliente.
Depois a instância ControladorAtendimento envia uma mensagem AdicionarCliente passando a instância c Cliente para o Atendimento.

Nesse caso de forma isolado, não há problemas de coesão, porem se o Controlador continuar a ser responsável pela maioria dos serviços executados pelo gerenciamento de um atendimento ele irá se sobrecarregar de tarefas e perderá sua coesão.

O digrama abaixo apresenta a solução para o problema citado:

O ControladorAtendimento delega para o objeto Atendimento a função de criar a instancia de Cliente.
Dessa forma tornamos a classe Atendimento mais coesa, pois suas atividades estão mais encapsuladas.
Se analisarmos melhor, o princípio criador esta sendo mais bem aplicado nesse caso, pois Atendimento “contém” uma lista Cliente e Atendimento usa Cliente de maneira muito próxima, ou seja, são duas condições que a tonam uma candidata a criação instância Cliente muito melhor que ControladorAtendimento.
Outro princípio que podemos identificar que foi aplicado nessa solução foi a diminuição do acoplamento da classe ControladorAtendimento, pois ela não precisa mais ter conhecimento (ou referência) para do objeto Cliente.

Segundo Grandy Booch, coesão alta existe quando os elementos de um componente “trabalham juntos para fornecer algum comportamento bem delimitado”.

Craig Larman define uma classe com coesão alta da como, “tem um número relativamente pequeno de métodos, com funcionalidade altamente relacionada, e não executa muito trabalho. Se a tarefa for grande, irá colaborar com outros objetos para dividir o esforço”.

Graus de Coesão

1. Coesão Muito Baixa – Uma classe é a única responsável por muitas coisas em áreas funcionais muito diferentes.
2. Coesão Baixa – Uma classe é a única responsável por uma tarefa complexa em uma área funcional.
3. Coesão Alta – Uma classe que tem responsabilidades moderadas em uma área funcional e colabora com outras classes para realizar a tarefa.
4. Coesão Moderada – Uma classe tem peso leve e responsabilidade exclusivas em algumas áreas logicamente relacionadas ao conceito da classe, mas não umas com as outras.

Conclusão

Assim como o Baixo Acoplamento, Coesão Alta é um princípio que devemos ter em mente durante todo o desenvolvimento/projeto de um sistema, pois auxilia a avaliação de alternativas e de tomada de decisão sobre os objetos de software.

Problema: Como apoiar dependência baixa, baixo impacto de modificação e aumentar o reúso?

Solução: Atribuir responsabilidade de modo que o acoplamento permaneça baixo.

Abaixo segue alguns efeitos na arquitetura que uma classes com acoplamento alto (ou forte) pode causar:

• Rigidez: Alteração em uma classe, obriga a alteração em diversas classes relacionadas, gerando uma cadeia de manutenção, conhecidas como “efeito dominó”.
• Fragilidade: Dificuldade de manutenção em um determinado ponto do sistema, pois gera problemas em outro ponto não relacionado, conhecido como “efeito borboleta-maremoto”, nomenclatura extraída da Teoria do Caos. Esta teoria defende que o simples bater de asas de uma borboleta em um extremo do mundo, pode causar um tornado no outro extremo.
• Imobilidade: Dificuldade de reutilização por excesso de dependência entre
  classes, conhecido como “efeito banana-gorila”, pois a dependência é tão grande que solicitar uma banana e é obtido um gorila junto com ela.

Formas comum de acoplamento entre classes:

• Objeto A tem um atributo do que se refere a instância de um objeto B.
• Objeto A chama um serviço de um objeto B.
• Objeto A tem um método que referencia uma instância de um objeto B (seja por parâmetro, variável local ou retorno da mensagem).
• Objeto A é uma subclasse do objeto B.
• Objeto B é uma interface implementada pelo objeto A.

Dica: O nível de acoplamento em si não deve ser considerado isolado de outros princípios tais como Especialista de Informação e Coesão Alta.

Contra-Indicações
Acoplamento forte a objetos estáveis não é um problema. Exemplo: Pode-se acoplar com segurança a biblioteca Java (java.util, etc) ou .Net (System.Collections, etc) pois são estáveis e amplamente disseminadas.

O acoplamento alto não é um problema, mas passa a ser um problema em classes que estão sujeitas a modificações ou entre objetos de pacotes e/ou camadas diferentes. A idéia principal é minimizar os efeitos de dependência excessivo entre objetos a fim de reduzir os impactos de modificações e permitir o reuso de objetos.
Devemos sempre avaliar o grau de acoplamento entre objetos e quais as conseqüências teremos em nosso sistema ao aumenta-lo.
Objetos genéricos devem sempre ter um nível de acoplamento muito baixo possibilitar reutiliza-lo em diversas partes do sistemas sem grandes impactos de dependência.
Por outro lado, objetos com ausência de acoplamento também não são bem vistos no sistema, pois contradiz a metáfora central da tecnologia de objetos: “um sistema é composto por objetos conectados que se comunicam por mensagens”.

Vantagens:

• Não é afetado por mudanças em outros computadores.
• Simples de entender isoladamente.
• É conveniente para reutilização.

Padrões Relacionados

• Variação Protegida

Enjoy

Problema: Qual é um princípio geral de atribuição de responsabilidade a objetos?

Solução: Atribua responsabilidade a classe que tem a informação necessária para satisfazer a responsabilidade.

Dica: Pergunte se realmente aquela responsabilidade é relevante ao objeto, enuncie claramente a responsabilidade do objeto. Que objeto é responsável por conhecer/fazer [coloque a responsabilidade do objeto aqui]? Esse questionamento irá auxilia-lo a definir melhor os atributos e métodos de seus objetos.

O Especialista de Informação é um princípio básico usado continuamente no projeto de objetos, ele expressa a “intuição” comum de que objetos fazem coisas relacionadas a informação que têm.
Geralmente fazem operações de coisas inanimadas que representa no mundo real. Por exemplo, uma venda não informa o seu total, ela é algo inanimado. Alguém calcula o total da venda. Craig Larman denomina isso como princípio da “animação” no projeto de objetos.

Vantagens:

• Mantém o encapsulamento pois utiliza informações próprias e apóia ao acoplamento baixo.
• Distribui o comportamento uniformemente entre as classes do sistema, aumentando a coesão das mesmas.

Contra-indicação:
Em algumas situações, a sugestão sugerida pelo especialista é indesejável, em geral por causa de problemas de acoplamento e de coesão.

Referência:

• Utilizando UML e Padrões – Larman, Craig
• UFCG – Departamento de Sistemas e Computação

Problema: Definir adequadamente aplicando o conceito de responsabilidade qual objeto é responsável pela criação de uma nova instância dentro da aplicação.

Solução: Atribua à classe B a resposnabilidade de criar a instância da classe A se uma das seguintes condições for verdadeira(quanto mais melhor):

1. B “contém” A ou agrega A de modo composto
2. B registra A
3. B usa A de maneira muito próxima
4. B tem os dados iniciais de A

O princípio criador auxilia na definição de qual objeto deve ser responsável por criar uma nova instância de classe. Essa atribuição bem definida da apoio para que o projeto apresente um baixo acoplamento, melhor encapsulamento e reutilização.
Repare que a escolha adequada desse princípio (criador) impacta no princípio de baixo acoplamento.
Outra forma de relacionamento também presente é de especialista de informação que é dado pela identificação de classes que possui os dados iniciais que serão passado como parâmetros durante a criação do objeto, mencionsado na condição 4.
A identificação de relacionamentos de objetos por composição ou agregação é uma boa diretriz para identificar os objetos que serão responsáveis por instânciar classes.

Contra-Indicações: Os processos onde é necessário instânciar classes de uma determinada família com base em um valor propriedades externa, é aconcelhável a delegar esse atividade a classes auxiliares chamadas de Fabrica Concreta ou Abstrata.

Composição ou Agregação?

Outro ponto onde programadores apresentam dúvidas é definir quando um relacionamento é dado por composição ou agregação.

Relacionamentos de composição, é dado pela dependência na qual o tempo de vida de um objeto é controlado por outro que o criou. Em outras palavras, o ciclo de vida do objeto depende do tempo de vida de quem o criou.

Relacionamentos de agregação, o tempo de vida dos objetos são independentes, ou seja, se o controlador for destruido, o objeto contido não será.

Podemos perceber que relacionamentos de composição quase sempre serão responsáveis por criarem objetos de seus relacionamentos, porem relacionamentos do tipo agregação normalmente não.

O conceito básico de orientação a objetos é a criação de objetos (instâncias) a partir de uma classe definida. A classe representa uma espécie de forma ou moldura de onde são instânciados objetos com as características. A classe portanto caracteriza os objetos criados, incorporando características (atributos) e ações (métodos).

Princípios de Orientação a Objetos norteiam o desenvolvimento orientado a objetos de forma a auxiliar para que sejam mais escalável e manutenível. Evitando que o conceito básico de orientação a objetos inflija heurísticas e métricas de desenvolvimento

Antes da apresentação dos princípios, gostaria de definir um ponto de vista.

Padrões ou Princípios?

A Definição de padrão é modelo, medida. Princípio é toda estrutura sobre a qual se constrói alguma coisa. Diferente dos padrões definidos pelo GoF, que reflete modelos de solução-problema, os princípios esta mais ligado a essência da programação, a forma de pensar e projetar um sistema.
Por esse motivo não vou tratar GRASP como padrão (pattern) e sim como princípio.
Pois os princípios devem ser incorporados pelo programador antes dos padrões.

Além dos 9 princípios GRASP que serão apresentados, há também outros princípios difundidos:

• Open-Close Principle (OCP)
• Liskov Substitution Principle (LSP)
• Single Responsability Principle (SRP)
• Don’t Repeat Yourself (DRY)
• Dependency Inversion Principle (DIP)
• Interface Segregation Principle (ISP)

Ao meu ver esses princípios são subprodutos do GRASP. Também vou apresenta-los mas após o GRASP para ficar mais explicito.

Relacionamento de princípios

Os patterns definem a solução para um determinado problema. Já os princípios são complementares e se relacionam para a aplicação de responsabilidade nos projetos de desenvolvimento de software e estão presentes em todos os níveis da aplicação.
Ao apresentar cada princípio em detalhes será possível perceber esse relacionamento e dependência entre os princípios.

Até mais

Recentemente participei do desenvolvimento de um projeto para implementar novas funcionalidades em um sistema de ERP criado em VB6. Sim, VB6 não é uma linguagem O.O., mas possui diversos recursos que se aproximam, como encapsulamento, herança entre outras. Apesar de ser um sistema com mais ou menos uns 10 anos, é um bom sistema. Sua arquitetura é dividida em camadas, possui estrutura de persistência de dados, apesar de estar anos luz de um NHibernate. Coisa que para a época de seu desenvolvimento é muito raro se encontrar hoje no mercado!

Uma única coisa me incomodou: os DESENVOLVEDORES. Apesar da arquitetura ser muito boa, muitos desenvolvedores que tiveram contato com a aplicação e não tinham conhecimentos de projeto de software guiado por responsabilidade. Se tivessem, com certeza manutenibilidade da aplicação seria bem melhor.

Esta não é uma visão isolada. A falta de comprometimento e conhecimento dos desenvolvedores é em maior instância a grande causadora de sistemas deficientes. Pensando nisso vou iniciar um série de diversos artigos apresentando e exemplificando a utilização dos Princípios de Orientação a Objetos e Padrões de Projetos. A ideia apresentar uma forma de raciocinar sobre como projetar objetos de software inserindo conceitos de responsabilidade, papéis e colaboração.

Projeto Guiado por Responsabilidade

A UML define uma responsabilidade como “um contrato ou obrigação de um classificador” [OMG03b]. A ideia de responsabilidade de um objeto (esse raciocínio pode ser aplicado a um escala maior de interação como um componente) é dado pelo seu papel e as obrigações que deve executar, ou seja, pelo seu fazer e conhecer.

As responsabilidades de fazer de um objeto incluem:

• Fazer algo propriamente dito, como criar um objeto ou executar um cálculo.
• Iniciar uma ação em outro objeto.
• Controlar ou coordenar atividade em outros objetos.

As responsabilidades de conhecer de um objeto incluem:

• Ter conhecimento de dados privados encapsulados.
• Conhecer objetos relacionados.
• Ter conhecimento sobre coisas que ele pode derivar ou calcular.

Responsabilidades não é a mesma coisa que um método – é uma abstração – porem métodos satisfazem às responsabilidades. Craig Larman – Utilizando UML e Padrões.

Design Patterns

Em engenharia de software, um padrão de projeto de software (ou o termo em inglês Design Pattern) é uma solução reutilizável para um problema comum em software. Design patterns não é uma solução final que pode ser transformada em código. Ele é uma descrição ou template para como resolver um problema e pode ser utilizado em diferentes situações e tipicamente mostram a relação e interação entre objeto.

GRASP – General Responsibility Assignment Software Patterns

Também conhecido como Princípios de Orientação a Objetos são padrões auxiliam na resolução de alguns problemas, e em quase todos os casos estes problemas são comuns para quase todos os projetos de desenvolvimento de software.
Os princípios de orientação a objetos define 9 padrões, que auxiliam no projeto e desenvolvimento de qualquer objeto na definição de suas responsabilidades, eles são:

• Creator (Criador)
• Information Expert (Especialista de Informação)
• Low Coupling (Baixo Acoplamento)
• High Cohesion (Alta Coesão)
• Controller (Controlador)
• Polymorphism (Poliformismo)
• Pure Fabrication (Invenção Pura)
• Indirection (Indireção)
• Protected Variations (Variações Protegidas)

Conclusão

Dominar o conhecimento e racionar sobre objetos guiado por responsabilidade e entender os princípios de orientação a objetos é é vital para o desenvolvimento de qualquer aplicação orientada a objetos. Não é a utilização de linguagem OO (como C# ou Java) que torna um aplicação orientada a objetos e sim o domínio dos conceitos acima.

Para isso podemos seguir algumas convenções (como em Java e C#.Net), ou criar um definições de estilo com apropria equipe em questão.

Vantagens ao usar estilo

Quando se esta desenvolvendo em equipe, o código deve ser compreendido por todos os membros. O estilo de programação tem como função auxiliar a equipe escrever código de modo único, assim é de fácil compreenção os códigos criados por outros menbros.

Complementação do estilo

Mais meu habito que propriamente do estilo, é ter um cuidado especial ao se definir nomes de objetos, métodos, atributos, variáveis, entre outros. A correta nomeação dos elementos no código ajuda a diminuir o hiato entre o código e mundo real, e assim como estilo de programação, também tornar mais fácil sua compreensão.

Exemplos do dia a dia

Recentemente estive envolvido em um projeto de uma aplicação antiga. Não havia na empresa mais nenhum desenvolvedor que criou a aplicação e precisávamos implementar algumas melhorias. Ao começar a implementar as melhorias, me deparei com algumas variáveis chamada X, Y, item. E perdi horas tentando compreender o que significa X, Y e item.

Conclusão

Para exemplificar esses conceitos, criei 2 aplicações iguais, ambas em Java, porem o primeiro está totalmento sem estilo e o segundo com um estilo que normalmente sigo. Compare e tire suas próprias conclusões:

Aplicação sem estilo

public class XyZ {
	public String no;
	public int id;
}

import java.util.ArrayList;
 
public class XyZs extends ArrayList{
	private static final long serialVersionUID = 1L;
}

import java.util.Iterator;
 
public class Application {
 
	public static void main(String[] args) {
 
		XyZs xxs = new XyZs();
 
		xxs.add(Cria("Sergio", 20));
		xxs.add(Cria("Rafael", 24));
		xxs.add(Cria("Frank", 22));
 
		ImprimeLista(xxs);
	}
 
	public static XyZ Cria(String n, int i) {
 
		XyZ x = new XyZ();
		x.no = n;
		x.id = i;
 
		return x;
	}
 
	public static void ImprimeLista(XyZs g){
		System.out.print("==== Lista de Amigos ==== \n");
 
		for (Iterator i = g.iterator(); i.hasNext();) {
			XyZ a = (XyZ) i.next();
			System.out.print("Nome: " + a.no + " idade: " + a.id + "\n");
		}
	}
 
}

Aplicação com estilo

public class Amigo {
	public String nome;
	public int idade;
}

import java.util.ArrayList;
 
public class Amigos extends ArrayList{
	private static final long serialVersionUID = 1L;
}

import java.util.Iterator;
 
public class Application {
 
	public static void main(String[] args) {
 
		// cria lista de amigos
		Amigos amigos = new Amigos();
 
		// adiciona amigo a lista
		amigos.add(CriaAmigo("Sergio", 20));
		amigos.add(CriaAmigo("Rafael", 24));
		amigos.add(CriaAmigo("Frank", 22));
 
		ImprimeLista(amigos);
	}
 
	public static Amigo CriaAmigo(String nome, int idade) {
 
		Amigo ret = new Amigo();
		ret.nome = nome;
		ret.idade = idade;
 
		return ret;
	}
 
	public static void ImprimeLista(Amigos amigos){
		System.out.print("==== Lista de Amigos ==== \n");
 
		for (Iterator i = amigos.iterator(); i.hasNext();) {
			Amigo amigo = (Amigo) i.next();
			System.out.print("Nome: " + amigo.nome + " idade: " + amigo.idade + "\n");
		}
	}
 
}

Perceptível a diferença, não?

Links Complementares:

• Convenções MS Capitalization Styles
• Orientações para nomeação MS
• CamelCase
• Notação Húngara

Não encontri nenhum artigo de estilo de Java, assim que eu encontrar eu posto aqui. Enquanto isso podemos ver a API do Java e tirar nossas conclusões de como escrever em Java com um estilo bem parecido.

Até mais…

Achei bem legal pois ele completa um pouco o post anterior.

Enjoy!