Na empresa onde trabalho, estamos criando uma nova arquitetura de sistemas foi me solicitado que criasse um pequeno exemplo usando essa arquitetura, com as classes Cidade, Estado, etc.

A princípio, o design mais comum seria o de criar uma superclasse comum (ex. "Região") e a partir dela herdar cada uma.

No entanto, IMHO, não é uma resposa tão óbvia, já que uma Cidade "é um" Região mas também "é um" divisão política.

Talvez, nesse caso, fosse mais interessante usar Interface.

Alguns links para estudo:

http://guj.com.br/posts/list/87814.java

http://blog.caelum.com.br/2006/10/14/como-nao-aprender-orientacao-a-objetos-heranca/

http://www.datasuldirect.com.br/flash/JAVA_SC/Or_Obj.pdf

UPDATE (11/08)

Mais um post interessante sobre o mesmo assunto:No, inheritance is not the way to achieve code reuse!

Semana passada passei para alguns  o link http://blog.fragmental.com.br/2008/07/25/uh-eme-ele/ onde o Schoes (um programador bastante conhecido na comunidade JAVA brasileira) fala sobre alguns problemas com a UML.

Por coincidência em outro blog, este internacional, um cara postou um artigo chamado 13 Reasons For UML Descent Into Darkness.

Somado a outros artigos que já li, percebo que a UML não é mais considerada no meio como sendo a Panacéia que resolverá todos nossos problemas.

Alguns fatos que pinço dos textos:

----

"Acontece que ao passar do diagrama (e diagramas aceitam qualquer besteira) para o código (onde o compilador e testes unitários são muito exigentes – fora os usuários) o tal do pseudo-modelo criado pelo “analista” no Rational Rose (porque a empresa não percebeu que o Rose foi descontinuado há anos) é completamente diferente do modelo implementado. As classes até têm o mesmo nome mas a mecânica interna é bem diferente. E por quê? Porque UML não vai te oferecer tudo o necessário para modelar. O mínimo que se espera de um modelo de um sistema é que ele seja verificável para saber se cumpre seus requisitos. Como é que eu vou saber isso com UML? Como eu testo UML?"

"

---------

10. Lack of solutions for real software design issues

While the specifications are huge there are no good solutions for problems common in software systems. Quick examples are:

• No solution for multi-tasking and communication between tasks
• No dependency between use cases"

--------

5. Concept bloat

Trying to bridge UML to reality made it incorporate concepts from all the languages in fashion during the last 10-15 years. Anybody knows how to represent a Java anonymous inner class?

-------- 

Claro que não estou propondo abolirmos a UML. Apenas trouxe esse tema para reflexão pois acredito que não podemos levar a ferro e fogo a idéia de que nossos diagramas UML tenham que representar todos os nossos projetos e que existem ferramentas auxiliares muito importantes para o entendimento/manutenção de uma necessidade (como por exemplo, descritivos textuais, testes unitários, documentação de código fonte, etc).