Cita:
Iniciado por SidP 
POO implica entre muchas otras cosas aprender a identificar las clases presentes en tu problema así como las relaciones que se establecen entre ellas...muy util ademas es ir recogiendo toda esa información en un diagrama(diagrama de clases) bien organizado el cual te servirá como guía para utilizar con efectividad las clases....ahora estas pueden tener diferentes tipos de responsabilidades de ahi que existan diferentes variedades de clases atendiendo a su funcionalidad
ejemplo : entidad, controladora, interfaz,auxiliares
entre todas ellas existen las relaciones(
es-un,
tiene-un)
de aqui es donde surge las formas de representar estas relaciones con su multiplicidad
tiene-un(agregación,composición)
ejemplo: Almacen y Piezas
Almacen
tiene-un Piezas o Piezas
es-parte-de Almacen
cuando la relacion es de composicion o agregacion y su multiplicidad es de 1 a muchos la clase Almacen va a contener un arreglo de Piezas, al contrario cuando la relacion va de 1 a 1 Almacen solo contendra un objeto Piezas
el otro tipo de relacion
es-un y aqui es donde entra a jugar su papel la
Herencia con todo lo que lleva consigo la misma(clases Padre-Hijas) donde las hijas heredan todos los atributos y metodos de la clase Padre etc, etc, etc
ejem: Perro
es-un Animal
Circulo
es-una Figura
espero que esto te haya dado al menos una vaga idea para tu ejemplo
Salu2
Disculpa, pero no estoy de acuerdo del todo con eso que dices. POO es programacion orientada a objetos, y la unidad mas importante es el objeto, no la clase. Sino se llamaría programación orientada a las clases :P.
La clase es solo un mecanismo para crear objetos. Hay otros mecanismos como es el prototipado (que sin ir mas lejos utiliza javascript). Es más, en lenguajes "puristas" las clases son objetos como cualquier otro, donde su clase es una "metaclase" (que tambien es un objeto :P)...
Concuerdo en lo de las relaciones, pero tengo para acotar un par de cosas:
1) las relaciones son entre objetos, no entre clases.
2) esas relaciones pueden modelarse en diagramas de clases o de colaboración(donde se ven objetos, no clases), pero no es algo necesario. Los diagramas son una forma de comunicar ideas, expresar un modelo o diseño...
3) la relación de herencia debe tomarse con pinzas en diseños complejos porque podria no calzar bien en todas las situaciones, aunque en programadores/desarrolladores con poca experiencia puede que sea lo más natural e intuitivo.