Core y Utils en un sistema <Variant>

H

hell await

Lanero Reconocido
29 Mar 2003
457
Hola a todos nuevamente.
Bueno la pregunta es sencilla, todo sistema mediano tiene un módulo Core <Corazón> o otro Utils <utilidades> que le permite trabajar adecuadamente, pero tengo una duda con respecto a estos módulos y lo que puedo y debo poner en cada uno.

ambos son transversales a todo el sistema, el core tiene trabajo critico mientras ke el utils solo utilidades varias para los demás módulos, pero tons aca surge mi pregunta, una clase Variant (tipo indefinido de una variable, ke puede ser casi cualkier cosa <---lo que uno permita) debe estar en el Core o en Utils? esta clase será utilizada x el resto del sistema (todos los módulos), pero solo es una representación de un tipo de dato, no lleva mayor trabajo o realiza alguna tarea critica.

Yo estaba pensando en ponerla en Utils pero aún no estoy seguro :S, igual tengo esto:
********************************************************
Utils:
-------
- Degree
- Matrix34
- Vector234
- Quaternion
- Radian
- Ray
- StringConverter
- StringUtil
- StringVector
- Console
- Log
- LogManager
- Singleton (*)
- String

Core:
-------
- ConfigFile
- DynamicLibraries
- DynamicLibrariesManager
- Module
- ModuleManager
- Platform
- Plugin
- System

Y tengo duda en "Singleton", no se si deba moverlo de módulo. Bueno espero comentarios al respecto, ideas. Como lo hacen ustedes? que recomiendan? que ven raro?.

Nos vemos luego.
 
Bueno, que lastima no encontrar respuestas :S, ni modo. Consulté con un par de amigos y definitivamente el Variant debe ir en Utils (bueno eso fue lo que concluimos) ya que es solo una definicion de un nuevo tipo de dato mas no es algo critico del sistema para ir en el Core. Los demás nos parece que están bien.

Gracias
 
Es una muy buena pregunta lo que planteas y se me hace extraño que nadie responda a preguntas tan sensatas. Definitivamente ese tipo básico de dato debería ir en el módulo Core de tu aplicativo.

El "Singleton" no me queda claro su propósito, si depronto es una clase de apoyo para implementar el patrón singleton o algo así, quedaría bien en útils.

Finalmente, no sé que lenguaje estás empleando, pero debe ser muy limitado para que estés construyendo librerías tan básicas que generalmente ya vienen incluidas en librerías estándades asociadas.
 
jejejeje gracias Rachmaninov por tu respuesta, el Lenguaje que estoy usando es C++, es cierto que ya hay libs que traen todo esto fabricado, pero la mayoría dan una lidia con las licencias para otras plataformas distintas de Linux como Windows y es una plataforma de trabajo, así que como te imaginaras, uno debe trabajar en lo que el cliente usa (Windows en este caso) y por ejemplo Qt que sería mi primera opción tiene el lio de la licencia para desarrollos comerciales en windows (aunque igual me estoy basando bastante en ella para implementar mi sistema). Resto a Singleton, si es un template (de c++) para implementar Manejadores con ese patrón y tienes razón, debe ir en Utils :D.

Para completar respeto a las libs, la única opción que veo como buena es Boost (para mi lenguaje), pero es que para compilar en VS Express a mi me ha dado mucha lidia :S y DETESTO las cosas que son tan complejas, cuando uno está trabajando en un ambiente de producción y es para una empresa (mundo real) no se puede dar el lujo de tomarse 1 semana instalando mil cosas y averiguando como instalar algo (sería como poner Slackware en lugar de Fedora en una empresa hasta para las secretarias, cosa que es totalmente estupida cuando hablas de empresa y velocidad de producción). Tons por eso me resulta mas sencillo hacer pequeñas implementaciones que sean sencillas. Cuando Boost sea el siguiente estandar de C++ (siguiente stl) seguramente miraré como empalmarla o tal vez, en un rato cuando tenga un poco mas de tiempo.

Y si me sorprende que no respondieran a mi pregunta :'( pero bueno.
 
hell await dijo:
jejejeje gracias Rachmaninov por tu respuesta, el Lenguaje que estoy usando es C++, es cierto que ya hay libs que traen todo esto fabricado, pero la mayoría dan una lidia con las licencias para otras plataformas distintas de Linux como Windows y es una plataforma de trabajo, así que como te imaginaras, uno debe trabajar en lo que el cliente usa (Windows en este caso) y por ejemplo Qt que sería mi primera opción tiene el lio de la licencia para desarrollos comerciales en windows (aunque igual me estoy basando bastante en ella para implementar mi sistema). Resto a Singleton, si es un template (de c++) para implementar Manejadores con ese patrón y tienes razón, debe ir en Utils :D.

Para completar respeto a las libs, la única opción que veo como buena es Boost (para mi lenguaje), pero es que para compilar en VS Express a mi me ha dado mucha lidia :S y DETESTO las cosas que son tan complejas, cuando uno está trabajando en un ambiente de producción y es para una empresa (mundo real) no se puede dar el lujo de tomarse 1 semana instalando mil cosas y averiguando como instalar algo (sería como poner Slackware en lugar de Fedora en una empresa hasta para las secretarias, cosa que es totalmente estupida cuando hablas de empresa y velocidad de producción). Tons por eso me resulta mas sencillo hacer pequeñas implementaciones que sean sencillas. Cuando Boost sea el siguiente estandar de C++ (siguiente stl) seguramente miraré como empalmarla o tal vez, en un rato cuando tenga un poco mas de tiempo.

Y si me sorprende que no respondieran a mi pregunta :'( pero bueno.
Haz clic para expandir...

Existen muchas opciones para multiplataforma, sin conflicto de licencias, por ejemplo Gtk. Qt permite, pero tienes que adquirir una versión comercial, si el negocio lo amerita puedes adquirir una, no son costosas la verdad en comparación con las soluciones C++ de Microsoft. Las librerías básicas, básicas: manejo de strings, estructuras y demases que noto estás reimplementando están escritas en las librerías estándares de C++ y esas si que no tienen dueño, y hay muchas implementaciones disponibles con licencias bien flexibles que puedes desde luego emplear en cualquier plataforma.

Si detestas lo complejo deberías considerar con más razón no reimplementar estas herramientas, por otro lado C++ es un lenguaje complejo, a mi me encanta por lo eficiente y poderoso, el control que te ofrece, pero es sin duda un lenguaje complejo y para programadores avanzados.

A mi modo de ver, reimplementar estas librerías es un lujo en un ambiente real del que hablas, es respetable, pero la recomendación es que tengas razones muy válidas para hacerlo, de otro modo estás marcando un bajón bastante notable en la curva de desarrollo del software, mientras si sigues indagando al respecto de qué librerías emplear, podrías aumentar tu curva sustancialmente.

Finalmente, las librerías Boost son una buena opción, el hecho que no hayas sido hasta el momento capaz de construir (en el IDE que sea) tu proyecto, obedece depronto a falta de experiencia en el lenguaje, en síntesis lo importante es que sepas como vincular las librerías (dinámica o estáticamente) al proceso de construcción del software para así lograr ejecutarlo. No es simple, como te menciono anteriormente C++ no es un lenguaje fácil, es un lenguaje complejo, si encuentras muy complicado construir tus proyectos deberías considerar otro lenguaje y/o plataforma de desarrollo de más alto nivel.

Hasta otra ocasión.
 
Hola, jejejeje mmm bueno se algo de C++, no soy un usuario experto pero lo manejo de hace varios años ya :p. Respecto a lo ke mensionas de Boost, tienes razón, cuando lo intenté hace un par de años no tenia la experiencia necesaria, aunque lo que no pude hacer fue compilarlas desde cero (las que se compilan, x ke la mayoria son templates en headers :D) en mi compilador de entonces :p, ya las instale este domingo y fue sencillo :D. Respecto a reimplementar lo que hay en las stl, no es así, ke no te engañen los nombres jejeje, la mayoría son simple azucar sintactico: templates y typedefs que hacen mayor relacion a mi proyecto que los nombres originales <-- typedefs, y la vida mas simple <--- templates.

Respecto a las otras opciones multiplataforma, Qt tiene el problema de la licencia y no tenemos dinero jejeje, Gtk es para C, y Gtkmm es un wrapper en el cual no confío, yo utilicé por mucho tiempo Gtk, incluso me gustaba x encima de Qt (hace como 3 años por ahi :p, cuando Qt no era lo que es ahora) y cuando intenté usarlo en C++ fue un complique y los wrappers que encontré no me gustaban :S. Las de Windows, tampoco las uso, generalmente trato de estar dentro del estandar, ya que mi plataforma debe compilar en Windows y Linux como mínimo según requerimientos.

Respecto a la complejidad del lenguaje, a mi modo de ver es un lenguaje sencillo y fácil de usar (incluso C puro), como te digo, lo uso de hace varios años ya y desde el principio me pareció una buena opción x rápidez y sencillez, aunque no estoy casado con él, tambien uso scripting cuando la situación lo amerita :d y ahora toy viendo lenguaje D.

Gracias por tus respuestas jejeje :p, nos vemos
 
Ah eso es diferente, la verdad me confundí porque tu exposición daba a entender otra cosa. Los typedefs si son válidos, de hecho a mí personalmente los nombres de las clases y demás elementos de las librerías estándares de C++ no me gustan del todo, sobretodo por su totalidad en minúsculas.

Gtk está escrito en C, cierto, pero eso no supone ningún problema si aplicas una buena arquitectura, pero en esto no sé que tantos conocimientos tengas. Una sugerencia por mi experiencia sería la de envolver (wrapper que llaman) en clases el acceso a los elementos gráficos de la aplicación, el acceso a los componentes gráficos los dejas con llamadas a las funciones básicas C, pero tu aplicación siempre interactua contra clases, ejemplo:

Código: 
class CapturaLogin;

// ...

int main(...) {

// ...

const char* nomUsuario = capturaLogin->getNomUsuario();

// Hacer lo que se tenga que hacer con el nombre de usuario

}

Aquí explotas la características de encapsulación de la POO, en la implementación del método estaría el acceso al widget.

De cualquier manera tu middleware quedaría en puro C++, que es a la final la capa más importante del aplicativo.

El asunto del complique con Gtk / C es un elemento de experiencia, eso es sumamente fácil si conoces bien el lenguaje. Después se vuelve consultas a la documentación para interactuar con los elementos gráficos, además tiene un diseñador Glade muy cómodo para las GUIs.

Personalmente prefiero Qt, porque me parece una API mejor documentada, mejor estructurada, pero mi recomendación por Gtk está afectada por las condiciones de tu desarrollo.

Las sugerencias son de caracter objetivo, pero si te vas por la subjetividad: esto me gusta, esto no, simplemente por un asunto de gustos, entonces es muy complicado el asunto, ya sería que tu encontraras personal e invidualmente lo que más se adapte a tu gusto, y no necesariamente lo que mejor se adapte a tu proyecto.

C/C++ es un lenguaje avanzado y una de las razones que lo hace tener esta complejidad encima, es porque el programador es el responsable de manejar la asignación de memoria a muchos elementos del lenguaje, por lo tanto no es fácil, ni sencillo de manejar, hay que tener conceptos bien claros y bastante habilidad para desarrollar con él. Ahora, si eres un programador avanzado, has desarrollado aplicaciones grandes o de considerable complejidad, y eres por lo tanto un conocedor de este lenguaje, no quiere decir que lo haga fácil, lo hace adecuado y simplemente sabes desarrollar con él, hasta tenido además la experiencia suficiente. Un lenguaje fácil y sencillo sería Ruby por ejemplo.
 

Los últimos mensajes

Los últimos temas

Arriba Pie
Atrás