Essa é uma compilação dos 10 melhores comentários de código mais engraçados. Vale a pena conferir.

Top funny source code comments

Frequentemente escuto alunos e colegas de profissão usar como sinôminos esses dois termos relacionados à UML. Mas existe diferença entre propriedade e atributo?

Segundo [Fowler, 2005], propriedade é uma “característica estrutural de uma classe”. Mas o que exatamente é uma característica estrutural, visto que uma classe é uma representação estática de parte de um sistema? Não seria tudo que é representado nela uma característica estrutural? Bem, o que Fowler tenta diferenciar são dois tipos de características que uma classe possui: propriedades e operações. As propriedades de uma classe são elementos que determinam o que uma classe é – por isso são ditas características estruturais – enquanto as operações deteminam o que uma classe pode fazer – portanto são características comportamentais.

Colocando de maneira mais objetiva, a propriedade refere-se a qualquer atributo ou associação que uma classe possui. Embora os conceitos de atributo e associação sejam semelhantes, elem implicam níveis de abstração diferentes de uma característica estrutural. Mas, de uma forma geral, podemos usar tanto atributo quanto uma associação para representar o mesmo conceito. A decisão sobre qual usar cabe ao engenheiro de software, dependendo no nível de destaque que ele deseja dar ao tipo que a propriedade possui.

Atributo

De forma grosseira, podemos entender o atributo como um campo de uma classe: um elemento de informação básico que identifica uma característica fortemente relacionada com aquela classe que o contém. Por exemplo, numa classe Cliente, seria comum representar a propriedade nome como um atributo, não como uma associação (embora nada impeça essa última forma), como na figura 1.

Figura 1 – Classe Cliente com propriedade representada como atributo

Associação

Da mesma forma que o atributo, uma associação representa uma propriedade de uma classe, só que representada por meio gráfico – uma linha ligando as classes – combinada com notações textuais (multiplicidades e nome do atributo de associação). A diferença fundamental da representação por meio de associação reside no destaque que é dado ao tipo de dado (classe) ao qual o elemento de informação está relacionado. Esse destaque procura dar ao leitor do modelo melhor compreensão sobre um elemento de informação que, provavelmente, é compreendido dentro do contexto de domínio da aplicação, mas não necessariamente fora dele. Por exemplo, se na classe Cliente eu desejo representar a propriedade que ele pode ter um Cartão, provavelmente representarei esse conceito por meio de associação, uma vez que o conceito Cartão depende muito do contexto onde ele se aplica (cartão de crédito, num sistema bancário; um cartão de visitas, num sistema de contatos, etc.). Ou seja, é importante destacar o tipo da classe à qual a propriedade pertence, até mesmo porque a classe Cartão, por sua vez, pode necessitar representar outras propriedades não óbvias para o leitor: número do cartão, tipo de bandeira (visa, mastercard, etc.), tipo de pagamento (à crédito ou à vista), etc. Veja a figura 2.

Figura 2 – Propriedade cartão representada como associação

Por outro lado, no caso do atributo nome da classe Cliente, qual seria a relevância de explicitar que tal propriedade é do tipo String? Ou ainda, não seria simplificar demais nosso modelo, incorrendo em imprecisão, representar a propriedade cartão como um atributo? Veja o mesmo modelo da figura 2, invertendo as representações, na figura 3. Qual deles é mais elucidativo?

Figura 3 – Propriedades representadas de forma invertidada

Conclusão

Uma propriedade pode ser representada tanto como atributo quanto como associação. A escolha por representar de uma ou outra forma depende do destaque que o engenheiro deseja dar ao tipo da propriedade. Se ele for dependente do domínio de aplicação sendo desenvolvido, é sempre conveniente representá-lo como associação. As demais propriedades, cujo tipo são de uso geral (String, int, Date,etc.), são melhor representadas como atributos.

Referências

[Fowler, 2005] Fowler, F. UML Essencial. 3ª edição. 2005. Editora Bookman.