Redefinición completa del API

[Ñuño Martínez]

Ya sé que es un título un tanto enigmático, pero ahora me explico.

Algunos sabréis que en mi tiempo libre estoy trabajando en una librería para crear juegos llamada Mingro. Pues bien, cuando estaba planteándome el sacar la primera versión beta me he dado cuenta de que el API que definí no es tan bueno como pensaba. Total, que me he puesto a pensar en cómo mejorar el diseño y tras unas semanas dándole vueltas he dado con dos aproximaciones válidas: una seguirá la simple estructuración y la otra se estructurará siguiendo la filosofía de la orientación a objetos. Y aquí es donde empieza mi duda.

El objetivo de Mingro es ser una herramienta que facilite la creación de juegos a principiantes y aficionados. Si fuera por mí el nuevo API sería orientado a objetos pero, ¿sería fácil de entender por principiantes y aficionados? Pascal fue inventado para enseñar programación estructurada. ¿Servirá igual para aprender programación orientada a objetos? Y no me refiero simplemente a crear clases y objetos, si no a aplicarlos correctamente.

En fin, que no sé muy bien qué aproximación utilizar para la nueva (y espero que definitiva) API de Mingro, a ver si con su opinión puedo aclararme. Y no duden en hacerme preguntas.

[dec]

Hola,

A mí lo que se me viene a la cabeza es que la orientación a objetos está más cerca de quien desarrolla clases, componentes, etc., que no de quien utiliza estos recursos sin más. Puedes hacer todo un programa en Delphi sin tener mucha idea de orientación a objetos: puedes estar utilizando objetos sin saberlo siquiera.

Pero, la forma de trabajar con objetos, me parece bastante clara incluso para quien no conozca todos los intríngulis de lo que este paradigma de programación signifique: y vuelvo a lo de antes, Delphi es un buen ejemplo, ahí tienes al Inspector de objetos, de cuya utilidad puedes beneficiarte sin conocer qué ocurre debajo...

Claro que he dicho lo primero que se me ha venido a la cabeza... que conste en acta, por favor.

[[Crandel]]

Creo que todo dependerá de los que quieres hacer.

Si la idea es crear un Sprite que se dibuje en pantalla, puede ser un objeto al cual se le modifican sus atributos para que se mueva o cambie de forma.

Si la idea inicializar una pantalla no tiene xq ser un objeto.

Deberas analizar cada caso y ver como sera mejor usarlo.

pd: existe una libreria para juegos llamada Allegro escrita en C/C++, podrias observarla para sacar ideas o hacer una interfac para delphi

[Ñuño Martínez]

Empezado por Crandel

Creo que todo dependerá de los que quieres hacer.

Si la idea es crear un Sprite que se dibuje en pantalla, puede ser un objeto al cual se le modifican sus atributos para que se mueva o cambie de forma.

Si la idea inicializar una pantalla no tiene xq ser un objeto.

Sí, pero no. No soy partidario de mezclar la orientación a objetos con programación estructurada "de toda la vida". Mi experiencia me dice que es mejor utilizar sólo un método. Así, se tiene un objeto "Pantalla" que te sirve para inicializarla y controla qué se ve y cómo se ve.

Pero esa es mi opinión, y seguro que otros se sienten la mar de cómodos mezclando ambas metodologías de programación, según el caso.

Empezado por Crandel

pd: existe una libreria para juegos llamada Allegro escrita en C/C++, podrias observarla para sacar ideas o hacer una interfac para delphi

En esto estoy servido. Conozco Allegro desde su versión 3.1 y la uso con asiduidad. De echo empecé a diseñar Mingro porque quería programar juegos usando Pascal y no C. También conozco las librerías SDL, PTC, OpenLayer y alguna otra más.

Vamos, que el problema no es que no sé crear un API para juegos sino el decidirme por una arquitectura de paquetes y clases o por una arquitectura estructurada.