none
ayuda con el uso de Interfaces RRS feed

  • Pregunta

  • Hola a todos necesito un consejo, He estado leyendo sobre UML y los componentes en C# o dlls

    en algun lugar lei que toda dll debe tener su Interface o mejor dicho deben ser dos dlls una con la implementacion y otra con el contrato para desacoplar los componentes. eso me queda claro.

    pero me queda una duda, un componentes si lo pensamos como que un componente es la suma de las dos dlls la de contratos y la de implementacion. si lo vemos asi, el componente esta decidiendo que va a exponer y como lo requiere. y eso no se si sea correcto.

    yo había leído en otro lugar que las interfaces las define la dll que va a requerir la implementacion, por ejemplo

    si yo tengo una dll de contratos de formas de pago, y una dll de implementaciones, pensando solo en formas de pago pues yo sabría que exponer en el contrato para que sea usado ahora también tengo una dll de punto de venta. que usa la interface de formas de pago. hay estoy condicionando a que el punto de venta utilice lo que la interface de formas de pago tenga definido. parece correcto por que esta desacoplado solo se comunica por medio de la interface. pero el punto de venta no tiene libertad de pedir lo que desee de formas de pago, solo lo que formas de pago le quiera dar, y hay esta mi problemática con este desarrollo. yo pienso que si la entidad es el punto de venta por su identidad y continuidad, y formas de pago es solo un objeto valor, que no tiene identidad ni continuidad, a que me refiero con esto, a que las formas de pago necesitan un punto de venta no viven sin el punto de venta, entonces la interface de lo que debe hacer formas de pago debe estar en el punto de venta y la implementacion debe estar en la dll de formas de pago, pero el punto de venta lo define.  

    espero  a verme explicado bien y conocer su percepcion de esta pregunta. de antemano muchas gracias

    viernes, 16 de enero de 2015 21:36

Respuestas

  • >>Porque los creadores del modulo de formas de pago deciden que exponer en la interface. eso es en lo que no estoy deacuerdo.

    los creadores de ese modulo solos no pueden decidir que exponer

    como comente la funcionalidad la definen los casos de uso, un requimiento define que funcionalidad implementar

    si el cliente define con el analista que los pagos se pueden realizar con tarjeta es un requerimiento quien modelara la funcionalidad para aceptar ese medio de pago, que imagino despues ventas tendra que invocar

    de forma aislada no se puede desarrollar software, hay que ponerse de acuerdo, por eso la interfaz es un contrato entre partes, si quieres puedes verlo de forma literal

    >>El modulo Ventas deberia crear interface de formas de pago

    el modulo de ventas puede "requirir" cierta funcionalidad y ponerse de acuerdo con pagos para que la implemente

    pero de ahi a crearla no lo creo

    >>pensando en objetos ya que hasta los componentes o modulos son objetos tambien

    ehh en realidad no, podrian ser objetos del diagrama UML, pero objetos como instancia si lo pensamo desde la perspectiva de programacion como lengueje no lo son

    un componente puede ser algo fisico que agrupa funcionalidad y eso no se instancia

    >>desde mi punto de vista el punto de venta es como un tronco de un arbol que puede vivir sin sus hojas, y formas de pago es una hoja que no puede vivir sin el tronco.

    ok eso marca una dependendencia, pero no quiere decir nada

    a ver un auto puede ser el tronco, pero sin las ruedas no va a ningun lado

    ventas puedes ser el tronco pero sino aceptas medios de pago, como podrias concretar la transaccion? digo le regalas el producto al cliente porque no tienes como aceptar un pago

    saludos


    Leandro Tuttini

    Blog
    MVP Profile
    Buenos Aires
    Argentina

    sábado, 17 de enero de 2015 0:42

Todas las respuestas

  • hola

    >>un componentes si lo pensamos como que un componente es la suma de las dos dlls la de contratos y la de implementacion. si lo vemos asi, el componente esta decidiendo que va a exponer y como lo requiere. y eso no se si sea correcto.

    recuerda que en UML hay diseños logicos y fisicos

    un componentes si lo piensas como dll es algo fisico, que compila y genera algo concreto

    pero podrias tener un diseño logico que explique como estos componentes interactuan, lo cual no quiere decir que esto luego sera una dll o dos, etc

    que compiles un proyecto .net en una dll podrias verlo como un componentes fisico, la interrelacion entre tu dll de controlato y tu dll de implementacion podrias verlo en un diagrama de interaccion, pero son componentes fisicos separados

    saludos


    Leandro Tuttini

    Blog
    MVP Profile
    Buenos Aires
    Argentina

    viernes, 16 de enero de 2015 23:29
  • >>pero el punto de venta no tiene libertad de pedir lo que desee de formas de pago, solo lo que formas de pago le quiera dar, y hay esta mi problemática con este desarrollo.

    bueno aqui depende mucho de como armes tu architectura y que tanta flexibilidad quieras brindar

    si pensamos que los componentes de venta y pago estan en la capa de negocio podrian comunicarse de forma directa, venta instancia el componente y usa sus metodos publicos, ya sea que lo exponga en la interfaz o no

    esto tiene consecuancias, generas dependencias entre componentes y hara dificil testear el codigo, pero bueno es una decision

    ahora si quieres inyectar la instancia de pago en el componente de venta vas a tener que ingresar por la interfaz, si venta requiere algo de pago que no expone vas a tener que modificar el componente de pagos para brindar ese servcio

    >>yo pienso que si la entidad es el punto de venta por su identidad y continuidad, y formas de pago es solo un objeto valor, que no tiene identidad ni continuidad, a que me refiero con esto, a que las formas de pago necesitan un punto de venta no viven sin el punto de venta, entonces la interface de lo que debe hacer formas de pago debe estar en el punto de venta y la implementacion debe estar en la dll de formas de pago, pero el punto de venta lo define. 

    pero aqui hablas de entidades, o de funcionalidad?

    porque aqui estas mezclando las cosas, una cosa es brindar servicio por una interfaz y otra distinta que sea una entidad que persiste y tiene un id y propiedades

    si se trata de entidades podrias aplicar la idea que plantea DDD cuando define los Bounded Context

     Strategic Domain Driven Design with Context Mapping

    basicamente lo que plantea es que definas un contexto principal para tu entidad (en este caso podriamos decir que seria tu componente de pago) y trabajes alli la entidad

    pero si lo requieres en otro contexto tambien lo defines alli, solo que lo haces con lo minimo y necesario, basicamente duplicas la entidad en los componentes (imaginemos que son contextos) solo que uno realizara las operaciones CRUD del mismo y otro quizas solo read pero de algunas propiedades nada mas

    no se si me explico bien, estos se ve mas claro cuando defines contectos de entity framework

    saludos


    Leandro Tuttini

    Blog
    MVP Profile
    Buenos Aires
    Argentina

    viernes, 16 de enero de 2015 23:43
  • okey queda claro, pero la verdadera duda esta en 

    si un componente debe exponer sus propios metodos desde una interface, o el componente que lo consumira debe exponerle una interface para que el componente lo implemente. pondre los dos ejemplos

    cuando uno expone las interfaces en un servicio, es el servicio quien decide que exponer.

    cuando creamos una interface desde la logica del negocio para que la capa de datos implemente las busquedas. 

    he hay los dos casos. 

    aqui mi detalle es que hay un punto de venta, que utiliza modulos o componentes, ventas usa a formas de pago, pero es formas de pago quien decide que exponer, como si fuera un servicio y yo no estoy deacuerdo con eso. yo pienso que el punto de venta tiene que tener un contrato de formas de pago, para que el punto de venta decida que necesita. y el modulo de formas de pago lo implemente. si el punto de venta requiere un cambio. solo agrega el cambio a la interface, y el modulo de formas de pago tendra que implementarlo. si el modulo de formas de pago cambia la implemtentacion a el modulo de ventas no le afecta.

    estas son las dos opciones

    1.- Formas de pago expone sus metodos por medio de una interface.

    2.- Punto de venta expone una interface para formas de pago lo implemente.

    cual seria mas correcta.

    viernes, 16 de enero de 2015 23:43
  • >>las formas de pago necesitan un punto de venta no viven sin el punto de venta, entonces la interface de lo que debe hacer formas de pago debe estar en el punto de venta y la implementacion debe estar en la dll de formas de pago

    ojo con esto que mencionas porque depende de como definas la forma de pago, por lo que comentas parece ser solo un enum

    pero si tienes una tabla entonces si requiere un identificador y estariamos hablando de asociacion entre entidades y estas puedes de ser agregacion o composicion

    Agregación Vs Composición en diagramas de clases. UML

    una asociacion es una relacion entre entidades, que se defina con el rombo vacio o lleno indicara si una entidad puede existir o no sin la relacion, pero solo es algo visual despues llevarlo a la practica requiere que lo codifiques

    saludos


    Leandro Tuttini

    Blog
    MVP Profile
    Buenos Aires
    Argentina

    viernes, 16 de enero de 2015 23:47
  • >>si un componente debe exponer sus propios metodos desde una interface, o el componente que lo consumira debe exponerle una interface para que el componente lo implemente.

    no entendi

    una interfaz define el contrato, y un componente lo implemente, eso es todo, el que lo consume no hace nada, solo obtiene o crea una instancia he invoca al metodo definido en la interfaz

    >>cuando uno expone las interfaces en un servicio, es el servicio quien decide que exponer.

    depende, se supone que el servicio expone funcionalidad que alguien requiere, el servicio no decide nada, son los requierimientos quienes modelan lo que el servicio expone para que la UI o cliente consuma y pueda llevar a cambo el caso de uso

    >>yo pienso que el punto de venta tiene que tener un contrato de formas de pago, para que el punto de venta decida que necesita. y el modulo de formas de pago lo implemente. si el punto de venta requiere un cambio. solo agrega el cambio a la interface, y el modulo de formas de pago tendra que implementarlo. si el modulo de formas de pago cambia la implemtentacion a el modulo de ventas no le afecta.

    ok lo que planteas es correcto

    quizas confunde un poco la perspectiva de quien define la interfaz, pero se entiende a donde vas y es correcto

    >>1.- Formas de pago expone sus metodos por medio de una interface. 2.- Punto de venta expone una interface para formas de pago lo implemente.

    los dos dicen lo mismo solo que lo ves desde el cliente y desde la implementacion

    la interfaz es solo una, pagos la implementa, ventas la consume, asi de simple

    saludos


    Leandro Tuttini

    Blog
    MVP Profile
    Buenos Aires
    Argentina

    sábado, 17 de enero de 2015 0:05
  • okey creo entender, 

    es que el tema que tengo aqui de discucion, Imaginate que esta aplicacion esta separada en modulos. Modulo de Formas de Pago, Modulo de Ventas, Modulo de Perifericos, Modulo de Misscelaneos etc.

    Cada modulo por ejemplo el de Formas de Pago que es en el que estoy yo Crea una Interface de los metodos que va a exponer. y tambien crea Una clase que implementa esa interface en el mismo modulo. 

    después el modulo de ventas usa la interface que creo el modulo de formas de pago. para usar los métodos de formas de pago. y yo digo Porque los creadores del modulo de formas de pago deciden que exponer en la interface. eso es en lo que no estoy deacuerdo.

    yo pienso que El modulo Ventas deberia crear interface de formas de pago, el modulo de formas de pago debe usar como herencia esa interface y implementar el codigo. pero lo define ventas. esa es mi propuesta.

    pensando en objetos ya que hasta los componentes o modulos son objetos tambien. siguiendo esa logica yo justifico mi pensar basandoce en entidad y objeto valor, desde mi punto de vista el punto de venta es como un tronco de un arbol que puede vivir sin sus hojas, y formas de pago es una hoja que no puede vivir sin el tronco.

    al igual que todos los demás modulos. todos viven de la venta. siguiendo esa logica pigo yo la venta les debe decir que hacer a los demas modulos.

    sábado, 17 de enero de 2015 0:28
  • >>Porque los creadores del modulo de formas de pago deciden que exponer en la interface. eso es en lo que no estoy deacuerdo.

    los creadores de ese modulo solos no pueden decidir que exponer

    como comente la funcionalidad la definen los casos de uso, un requimiento define que funcionalidad implementar

    si el cliente define con el analista que los pagos se pueden realizar con tarjeta es un requerimiento quien modelara la funcionalidad para aceptar ese medio de pago, que imagino despues ventas tendra que invocar

    de forma aislada no se puede desarrollar software, hay que ponerse de acuerdo, por eso la interfaz es un contrato entre partes, si quieres puedes verlo de forma literal

    >>El modulo Ventas deberia crear interface de formas de pago

    el modulo de ventas puede "requirir" cierta funcionalidad y ponerse de acuerdo con pagos para que la implemente

    pero de ahi a crearla no lo creo

    >>pensando en objetos ya que hasta los componentes o modulos son objetos tambien

    ehh en realidad no, podrian ser objetos del diagrama UML, pero objetos como instancia si lo pensamo desde la perspectiva de programacion como lengueje no lo son

    un componente puede ser algo fisico que agrupa funcionalidad y eso no se instancia

    >>desde mi punto de vista el punto de venta es como un tronco de un arbol que puede vivir sin sus hojas, y formas de pago es una hoja que no puede vivir sin el tronco.

    ok eso marca una dependendencia, pero no quiere decir nada

    a ver un auto puede ser el tronco, pero sin las ruedas no va a ningun lado

    ventas puedes ser el tronco pero sino aceptas medios de pago, como podrias concretar la transaccion? digo le regalas el producto al cliente porque no tienes como aceptar un pago

    saludos


    Leandro Tuttini

    Blog
    MVP Profile
    Buenos Aires
    Argentina

    sábado, 17 de enero de 2015 0:42