Interface Vs Clase, Diseño De Librerias

[_Grey]

 Tengo algunas dudas sobre el diseño de mi mini librería personal, que quisiera compartir;

Tengo la clase Image que no es mas que eso, un objeto que representa una imagen y tiene las adecuadas funciones para tratar con ella, pero como podrían existir varias referencias a esta clase y nadie quiere que los objetos mueran y quedarse con su puntero, he creado una clase que Image usa de clase base que se dedica a contar las referencias que hay y eliminar el objeto cuando estas se agotan, y he puesto el destructor como private, la verdad muy feo, solo se puede crear dinámicamente, y eliminar con la función que decrementa la cuenta de referencias si esta es 0, esto os parece aceptable?! juraría que no, y que seria mejor usar una interface en lugar de un objeto con... ¡comportamiento de interface!, pero quisiera conocer mas opiniones.

Si bien la primera cuestión, parece obvia, me plantea una segunda. Debería dejar solo interfaces!? ( de cara al programador, claro, todos sabemos que detrás de estas habrá objetos reales ), o es comprensible el uso de interfaces y objetos!? ya e explicado que la clase Image puede estar referenciada con punteros desde otros sitios y el valor de contar las referencias,pero otros objetos no lo necesitan y seria mas fácil trabajar con un objeto, que se destruye por cuenta propia al final de la función y no necesita de llamadas especiales..... pero uso objetos e interfaces de forma que no se si es la mejor,
por ejemplo;

Tengo objetos de Keyboard, GamePad y Mouse.... y todos heredan la interfaz IGamePadControl, con lo que use lo que use el usuario, siempre te podrás comunicas con esa interfaz. Me parece un punto positivo, pero, no se podría decir que uso clases e interfaces de forma arbitrarea!??!

Con lo que me planteo otra vez ... seria mejor dejarlo todo como interfaces, me parece mas difícil de usar la librería con todo como interfaces, pero no se si en realidad complico la vida al programador usando objetos por un lado e interfaces por otra.

Mi idea es dejarlo como esta, pero pasando a interface el objeto Image y el Sprite, y el de Animation, y el Actor(que trabajaría con Animation) dejarlo como clase. Se ve ??? Dejar interfaces para recursos(que cuentan referencias) y para abstraer hardware(como IGamePadControl, sin contar referencias), y Objetos para cosas fisicas que no son recursos(El objeto Keyboard para el teclado, o incluso el Window para las ventanas del sistema).

Lamento la parrafada, tengo decidido esto ultimo que he dicho casi al 100%, pero quisiera conocer otras opiniones, usáis solo interfaces de cara al programador que use la librería??, interfaces y clases!??! solo clases y que vigile el programador si tiene punteros a ellos cuando elimina objetos!??! como lo hacen otras librerías!? he estado viendo la web de PTK, todos los objetos se crean de forma dinámica, son todo interfaces!?y otras librerías!?

Saludos y gracias.

[Shaitan]

 Hola,
Por lo que veo tienes 2 problemas distintos, uno es el control de objetos y otro es tener una forma unificada para acceder a distintos dispositivos, etc. Para el Segundo, creo que la aproximación que utilizas de hacer una clase interfaz es la correcta, ya que de esta forma es muy fácil utilizar cualquier tipo de dispositivo sin saber mucho acerca de él. Lo único que tienes que tener en cuenta es las diferencias que hay entre estos.
El tema de control de objetos es otra cosa. Yo te recomiendo que utilices un patrón de tipo Singleton o mejor un object factory, si bien este último es  algo más complicado. Estos patrones no son mas que clases que sirven como interfaz y que se aseguran que solo hay un objeto de esta clase (El que sea Singleton o la factoria) en la aplicación, facilitando la gestión de objetos, etc.
Aqui te dejo un link:
Patrones de diseño
(esto lo he escrito Yo y algunas cosas son opiniones mias que pueden no ser correctas, pero hay algun link q puede interesarte)

J.

[Pogacha]

 La verdad es que pensé bastante en esto, y creo que lo unico que puedes hacer es hacer la parte tipo "UML" y ver como queda, luego simular su uso y encontrar fallos, en definitiva iterar hasta encontrár lo que mas te convenza.

[_Grey]

 UML... y yo que detestaba hacer organigramas (diagramas de flujo).... :P

Gracias por el link Shaitan, y por las referencias que incluye!!

Ya veo que no existe "una solucion", intentare crear la mia con algo mas de cabeza con estos datos.

gracias, saludos.