Relación entre objetos

8

Durante algunas semanas he estado pensando en la relación entre los objetos, no especialmente en los objetos de OOP. Por ejemplo, en C ++ , estamos acostumbrados a representarlo mediante la creación de capas de punteros o un contenedor de punteros en la estructura que necesita un acceso al otro objeto. Si un objeto A necesita tener acceso a B , no es raro encontrar un B *pB en A .

Pero ya no soy un programador de C ++ , escribo programas utilizando lenguajes funcionales, y más especialmente en Haskell , que es un lenguaje funcional puro. Es posible usar punteros, referencias o ese tipo de cosas, pero me siento extraño con eso, como "hacerlo de una forma no-Haskell".

Luego pensé un poco más en todo lo relacionado con esa relación y llegué al punto:

  

"¿Por qué incluso representamos esa relación por capas?

Leí algunas personas que ya pensaron en eso ( aquí ). Desde mi punto de vista, representar relaciones a través de gráficas explícitas es mucho mejor, ya que nos permite enfocarnos en el núcleo de nuestro tipo y expresar relaciones más adelante mediante combinadores (un poco como SQL hace).

Por núcleo quiero decir que cuando definimos A , esperamos definir qué A está hecho de , no de lo que depende de . Por ejemplo, en un videojuego, si tenemos un tipo Character , es legítimo hablar de Trait , Skill o ese tipo de cosas, pero ¿es si hablamos de Weapon o Items ? Ya no estoy tan seguro. Entonces:

data Character = {
    chSkills :: [Skill]
  , chTraits :: [Traits]
  , chName   :: String
  , chWeapon :: IORef Weapon -- or STRef, or whatever
  , chItems  :: IORef [Item] -- ditto
  }

suena realmente mal en términos de diseño para mí. Prefiero algo como:

data Character = {
    chSkills :: [Skill]
  , chTraits :: [Traits]
  , chName   :: String
  }

-- link our character to a Weapon using a Graph Character Weapon
-- link our character to Items using a Graph Character [Item] or that kind of stuff

Además, cuando llega el día de agregar nuevas funciones, podemos crear nuevos tipos, nuevos gráficos y enlaces. En el primer diseño, tendríamos que romper el tipo Character , o usar algún tipo de trabajar alrededor para extenderlo.

¿Qué piensas de esa idea? ¿Qué crees que es mejor para lidiar con ese tipo de problemas en Haskell , un lenguaje puramente funcional?

    
pregunta phaazon 28.05.2014 - 14:44

1 respuesta

2

En realidad has respondido a tu propia pregunta, simplemente no la conoces todavía. La pregunta que está haciendo no es sobre Haskell sino sobre programación en general. De hecho, te estás haciendo muy buenas preguntas (kudos).

Mi enfoque del problema que tiene a mano se divide básicamente en dos aspectos principales: el diseño del modelo de dominio y las compensaciones.

Déjame explicarte.

Diseño del modelo de dominio : así es como decide organizar el modelo principal de su aplicación. Puedo ver que ya estás haciendo eso pensando en Personajes, Armas, etc. Además necesitas definir las relaciones entre ellos. Su enfoque de definir los objetos por lo que son en lugar de depender de ellos es totalmente válido. Sin embargo, tenga cuidado porque no es una bala de plata para cada decisión con respecto a su diseño.

Definitivamente estás haciendo lo correcto al pensar en esto de antemano, pero en algún momento debes dejar de pensar y comenzar a escribir algo de código. Verás entonces si tus primeras decisiones fueron las correctas o no. Lo más probable es que no, ya que aún no tiene pleno conocimiento de su aplicación. Entonces no tenga miedo de refactorizar cuando se dé cuenta de que ciertas decisiones se están convirtiendo en un problema, no en una solución. Es importante escribir código al pensar en esas decisiones para poder validarlas y evitar tener que reescribir todo.

Hay varios buenos principios que puede seguir, solo busque en Google "" principios de software " y encuentra un montón de ellos.

Compensaciones : todo es una compensación. Por un lado, tener demasiadas dependencias es malo, sin embargo, tendrá que lidiar con la complejidad adicional de administrar dependencias en otro lugar en lugar de en los objetos de su dominio. No hay una decisión correcta. Si tienes una corazonada, hazlo. Aprenderá mucho tomando ese camino y viendo el resultado.

Como dije, estás haciendo las preguntas correctas y eso es lo más importante. Personalmente estoy de acuerdo con su razonamiento, pero parece que ya ha dedicado demasiado tiempo a pensarlo. Deja de tener miedo de cometer un error y comete errores . Son realmente valiosos y siempre puede refactorizar su código cuando lo considere oportuno.

    
respondido por el Alex 02.07.2014 - 18:50

Lea otras preguntas en las etiquetas