La implementación de objetos de negocio

La implementacion de objetos de negocio

La implementacion de objetos de negocio : Multi-millones de consejos para hacer su vida mas facil.

las Clases que encapsulan las reglas de negocio de sentar las bases de una verdadera aplicacion orientada a objetos.
la Implementacion de Objetos de Negocio
Este articulo es el primero de una serie en la que vamos a explorar las muchas facetas de la implementacion de una verdadera aplicacion orientada a objetos. A lo largo del camino vamos a tomar en casi todos los aspectos de diseño de la aplicacion y cuestionar algunas de las maneras aceptadas de la escritura de una aplicacion Delphi. El concepto fundamental detras de este enfoque es el encapsulamiento: el diseño de un conjunto de clases con interfaces bien definidas (metodos) que operan sobre las propiedades. Estos conceptos se impregnan toda la aplicacion y afectara la forma en que se almacenan los datos y se presentan. Yo la recomiendo a los lectores a estudiar Francisco Glassborow la columna C aunque el Delphi modelo de objetos carece de la integridad (y la complejidad) de C , los conceptos de buena clase de diseño son independientes del lenguaje.
la Mayoria de las tipicas aplicaciones de Delphi. escrito de hoy no son orientados a objetos. Solo porque el lenguaje tiene un modelo de objetos y muchos nuevos y existentes de clases, esto no significa que la aplicacion puede ser considerado como verdaderamente OO. La reutilizacion de codigo se ha terminado con la caida componentes de terceros en los formularios, y las interdependencias entre las formas y las unidades proliferan rapidamente. Las oportunidades de futuro para cambiar la aplicacion de los fundamentos (tales como el cambio de la base de datos o en movimiento a partir de 2-nivel 3-nivel de aplicacion) son muy limitados o muy caro para contemplar. La redaccion de la aplicacion en un verdadero OO moda facilitaria, en lugar de restringir, estas oportunidades. Sin embargo, la escritura requiere de un cambio de mentalidad, acompañado por una primera falta de productividad, que la mayoria de los equipos de desarrollo son reacios o incapaces de tener en cuenta. En el transcurso de estos articulos, los espero para demostrar algunos de los fundamentos que ayudara a los desarrolladores a dar el paso a la implementacion de mejores aplicaciones. La resultante de sistemas siempre sera mas fiable, facil de mantener, coherente, flexible, reutilizable y, en general, funciona mejor que una aplicacion escrita en la forma estandar. En particular, los beneficios de la claridad del codigo son tales que para aplicaciones de gran tamaño, uno escrito en una verdadera OO de la moda puede requerir un numero significativamente menor de los recursos de mantenimiento de la misma solicitud por escrito de la manera tradicional. Tal vez deberia justificar estos beneficios de una OO aplicacion mas alla: creo que pocos defiende con algo para vender (en este caso la vision de una mejor aplicaciones) debe alejarse indiscutible!
La mayor fiabilidad de la OO aplicaciones proviene del hecho de que los datos y las operaciones son encapsulados en zonas bien definidas las clases. El propio compilador va a contribuir a la correcta clase, metodo y uso de la propiedad a traves de una fuerte comprobacion de tipos, y con unico lugar de codigo duplicado significa que los futuros cambios en una sola rutina son un fenomeno generalizado en toda la aplicacion. Una consecuencia de la utilizacion correcta de las clases es que las relaciones entre ellos son evidentes y una proporcion mucho mayor de la que el codigo escrito es en realidad la implementacion de la 'carne' de la aplicacion, en lugar de preocuparse por detalles tales como la forma de datos se almacena de forma persistente. Esto hace que la aplicacion mucho mas facil de mantener, un factor mas simplificado, por una mayor coherencia en todo. Como veremos, el uso de la herencia de clases extensivamente tanto aumenta la productividad y fiabilidad, sino tambien impone la coherencia. Esta consistencia es evidente en la manera en que el codigo que se presenta y como las clases de comportarse, pero tambien en la medida de como se almacenan los datos y como la interfaz de usuario se presenta. Como gran parte de la funcionalidad es proporcionada en las clases base, es posible cambiar rapidamente su comportamiento que afectan fundamentalmente a la aplicacion (tales como el cambio de la interfaz se basa en html, en lugar de formulario). Estas clases base puede ser diseñado para ser independiente de la aplicacion, por lo que la segunda solicitud escrita de esta manera las ganancias de un inmediato aumento de la productividad. Un buen conjunto de clases base puede proporcionar hasta un 50% del codigo en un mediano aplicacion, que es un beneficio obvio de un tiempo, el coste y la fiabilidad de pie. Es razonable resaltar que el interruptor a la posicion 'real' OO de desarrollo no es un proceso trivial y debe ser llevado a cabo unicamente por primera vez con la experiencia de la asistencia, o para un proyecto de tamaño pequeño sin plazos perentorios. Tambien se debe destacar que una OO solucion no se dictan otras clases que se debe (o no debe) ser utilizado dentro de la aplicacion. Si una empresa ha desarrollado sus propios componentes visuales, utiliza los de un tercero, o se ha estandarizado en una determinada plataforma de base de datos, entonces no hay razon por la que estas no pueden ser usadas (con una notable excepcion). El desarrollo de un OO aplicacion es acerca de la aplicacion de un conjunto coherente de patrones de diseño en lugar de decirles que componentes debe ser utilizado.
se Centro clases
El primer paso en el diseño de cualquier objeto-orientado a la aplicacion es el pensamiento acerca de las clases que van a ser necesarios. Este es un paso fundamental, como con cualquier otra tecnica de desarrollo, como equivocarse en una primera etapa va a ser caro para corregir. En el diseño de nuestras clases, nos deben, generalmente, se esfuerzan por un bajo acoplamiento y alta cohesion - las clases deben ser tan independientes como sea posible a partir de otras clases, pero deberia ser posible para ser combinados en formas poderosas. Una forma de lograr esto es, para clasificar a los conjuntos de clases de acuerdo a las funciones que van a tener dentro de la aplicacion. Acertada seleccion de estas funciones se traducira en un conjunto coherente de clases.
Hay una regla fundamental que se repite a lo largo de la funcion de clase de diseño: el fuerte de la separacion de las clases responsable de la presentacion, aplicacion y persistencia. La presentacion puede ser generalmente eran como la interfaz de usuario, y la persistencia como cualquier cosa que almacena los datos (normalmente en una base de datos). Aunque esta es la misma separacion como la que existe para los 3 niveles de desarrollo, cabe señalar que este es un diseño conceptual de la separacion que se puede implementar de muchas maneras: como una sola aplicacion monolitica de todo el camino a traves de un completamente distribuido de varios niveles del sistema. El conjunto de clases que constituyen la logica de la aplicacion son los que realmente hacen el trabajo duro de responder al usuario de estimulos para manipular y procesar datos. Un subconjunto de clases dentro de esta capa se identifica como la representacion de las entidades del mundo real que se puede modelar por el sistema. Estos son muy a menudo etiquetados como 'negocio' o 'dominio del problema' de las clases. Constituyen una parte vital de cualquier OO del sistema, como la mayoria de las clases seran de apoyo en ellos de una manera o de otra, y que constituyen el foco de toda la participacion del desarrollador.
la Identificacion de los objetos de negocio para una aplicacion dada, generalmente, se vuelve instintivo con la experiencia, aunque existe toda una ciencia (o es arte?) detras del proceso. La belleza de la OO en comparacion con las tecnicas tradicionales, tales como SSADM es que los procesos de analisis y diseño que han evolucionado a mantener las mismas entidades de todo: es posible ver una representacion de cada objeto de negocio a lo largo OOA (analisis), INUNDACIONES (diseño) y, finalmente, la aplicacion en si misma (OOP). Vamos a explorar algunas de las tecnicas para identificar el objeto de negocio en futuras columnas. Por el momento, vamos a suponer que estos procesos se han realizado.
La comunicacion entre las clases que existen en las diferentes capas (presentacion, aplicacion, persistencia) esta bien definido y se debe respetar absolutamente. Esto se muestra en la Figura 1, y las flechas indican que una clase en una capa puede realizar llamadas de metodo en otra clase. Este diagrama muestra que la capa de presentacion (interfaz de usuario) puede manipular la capa de aplicacion o de otras clases dentro de la interfaz de usuario, y que la capa de aplicacion (business objects) puede manipular y hacer llamadas a la capa de persistencia, que solo puede responder a las peticiones de la capa de aplicacion.
objetos de Negocio

Para demostrar como los objetos de negocio puede ser implementado, vamos a seguir un ejemplo realizado con un pequeño conjunto de clases de exponer el clasico de Stock, atencion al Cliente y entidades de Orden (una compañia que ofrece una serie de articulos en stock para la venta, que puede ser comprado (ordenados) por parte de los clientes). Nuestro (trivial) analisis ha confirmado que inicialmente vamos a exigir a tres objetos de negocio para representar a cada una de estas entidades. En nuestra aplicacion Delphi tendremos tres clases: TStockItem, TCustomer y TOrder. Listado 1 muestra un resumen de interfaz publica para estas clases. Cabe señalar que todos los atributos de la clase se exponen como propiedades: este es simplemente un buen diseño de clases y facilita el control sobre el acceso a las propiedades (si es necesario). Tambien se debe señalar que las propiedades estan expuestos en la publicacion de la seccion de la clase (por las razones que vamos a discutir en el futuro), y que se completa con los valores predeterminados cuando proceda. Aunque esta propiedad calificador es ostensiblemente utiliza la transmision por secuencias de componentes, sirve a un proposito util para indicar el valor inicial de cada propiedad y ayuda a que el codigo para ser auto-descriptiva.
Algo que es fundamental para los negocios (dominio del problema) de los objetos es que ellos no tienen conocimiento de como se almacenan de forma persistente. Ellos no saben como se almacenan en tablas de base de datos, en realidad se puede hacer absolutamente ninguna hipotesis sobre el tipo de almacenamiento. Un objeto de negocio es una muy centrado clase que solo expone propiedades adecuadas y los metodos necesarios para manipularlos. A la hora de diseñar la interfaz publica de la clase ninguna concesion debe hacerse en cuanto a los tipos de las propiedades para la persistencia de datos (base de datos) de almacenamiento. Siempre se debe seleccionar el tipo mas adecuado para el inmueble de que se trate, independientemente de que sea o no la intencion de la base de datos admite de forma nativa. Un buen ejemplo es una propiedad del conjunto: algunas bases de datos de apoyo establece directamente, pero si esta es una forma natural de exponer una propiedad de un objeto de negocio, a continuacion, debe ser elegido con preferencia a otra representacion (posiblemente un numero de Booleanos). Otro ejemplo es exponer algo como una direccion como un TStringList. No es el papel de la empresa objeto de los prejuicios es la interfaz a favor de almacenamiento de base de datos: esta es la tarea de la capa de persistencia.
Nuestro primer marco
se han identificado e implementado tres objetos de negocio como la base inicial para nuestra aplicacion. Estos tres objetos comparten una funcion comun: representar entidades del mundo real de alguna manera. Por lo tanto, esperamos que ellos tienen propiedades similares y, por tanto, una jerarquia de clases es la adecuada. Vamos a darle a cada uno de estos objetos de un ancestro comun, llamado TPDObject (para el Problema objeto de Dominio). Este TPDObject clase se extendera a lo largo del tiempo a medida que introducimos comun de metodos y propiedades para nuestras clases. Cabe señalar que TPDObject no contiene (y nunca sera) cualquier aplicacion especifica de los elementos. Como una aplicacion independiente de la construccion debe ser colocado en una unidad separada y constituye la base de un marco: un conjunto de clases que pueden ser re-utilizados en muchas aplicaciones. A lo largo del tiempo nuestro marco ampliara en gran medida a proporcionar muchas clases base que proporcionan importantes independiente de la aplicacion de la funcionalidad, listo para ser especializados para sistemas especificos. Nuestro TStockItem, TCustomer y TOrder clases son ejemplos de versiones especializadas de nuestros genericos TPDObject. Un examen mas detallado de Listado 1 muestra que, de hecho, nuestros tres clases del dominio del problema son cada uno de los descendientes de otra clase, TMyAppPDObject, en si mismo un descendiente de TPDObject. Aunque la implementacion de TMyAppPDObject esta vacia, es otro ejemplo de un buen diseño de clases, de modo que si queremos proporcionar a cualquier aplicacion especifica de los elementos a todos nuestros objetos del dominio del problema hay una clase apropiada en nuestra jerarquia.
Listado 2 muestra nuestra embrionario Marco de la unidad. En el momento en que el TPDObject clase proporciona solo una propiedad de solo lectura denominado ID, que es de tipo TObjectID. Esta propiedad se utiliza para dar a cada clase el concepto de identidad: vamos a definir dos casos que representan el mismo objeto, si son del mismo tipo y tienen el mismo valor de ID. Este ha sido deliberadamente definido como su propio tipo, de modo que no es directamente la asignacion compatible con otros tipos escalares. La eleccion del tipo de los TObjectID es arbitraria: he elegido en este caso para hacer un tipo Entero, pero no es un caso para hacer su propia clase. Aunque una forma mas 'pura', he decidido en contra de esto sobre la base de que nuestro dominio del problema, los objetos se construyen (y destruido) muchos miles de veces durante la aplicacion y podemos evitar la sobrecarga de la construccion y la destruccion de la extra TObjectID de clase (mi purista argumento para esta implementacion eleccion es que en distintos TObjectID clase ha sido subsumida en la TPDObject clase como un objeto compuesto). Hay un par de metodos adicionales en esta unidad a convertir nuestro objeto tipo de identidad a una representacion de cadena de caracteres, y una constante para la inicial 'no tiene identidad' valor.
Hay una serie de escuelas de pensamiento sobre la identidad del objeto se dice que todos los objetos de negocio debe ser asignado a una identidad cuando se construye y que la identidad debe ser unico dentro de una aplicacion (o incluso a nivel mundial como en un GUID). En la practica, solo es importante ser capaz de distinguir entre dos objetos en un determinado contexto, y teniendo este sencillo, tiene, obviamente, el rendimiento y el almacenamiento de los beneficios, aunque ciertamente no me encuentra argumentando en contra de una opcion para un tipo mas complejo en las circunstancias apropiadas.
Una cuestion de etica
En fin de poner de relieve algunos de los problemas de diseño e implementacion de las decisiones tomadas a la hora de diseñar un marco que ocasionalmente se plantean preguntas e invitar a los lectores a considerar la logica detras de ellos. Al principio de la columna a la que me referi a una importante excepcion a la afirmacion de que una verdadera OO diseño no proscribir el uso de clases particulares. ¿Cual es la excepcion a esta afirmacion (pista: la respuesta se encuentra dentro de la Figura 1).
& nbsp ((( Listado 1 - Una aplicacion especifica del Dominio del Problema de la unidad (abreviada) )))
unidad de ProblemDomain
interfaz
usos
& nbsp & nbsp Marco
tipo
& nbsp & nbsp TMyAppPDObject = clase (TPDObject)
& nbsp & nbsp final
& nbsp & nbsp TStockItem = clase (TMyAppPDObject)
& nbsp & nbsp publicado
& nbsp & nbsp & nbsp & nbsp Nombre de la propiedad: String
& nbsp & nbsp & nbsp & nbsp propiedad QuantityInStock: el Cardenal predeterminado 0
& nbsp & nbsp & nbsp & nbsp propiedad TradePrice: Moneda
& nbsp & nbsp & nbsp & nbsp propiedad RetailPrice: Moneda
& nbsp & nbsp final
& nbsp & nbsp TCustomer = clase (TMyAppPDObject) ...
& nbsp & nbsp TOrder = clase (TMyAppPDObject) ...
aplicacion
final.
((( Fin del Listado 1 )))
((( Listado 2 - Una aplicacion independiente del Marco de la unidad )))
Marco de unidad
interfaz
const
& nbsp & nbsp NotAssigned = 0
tipo
& nbsp & nbsp TObjectID = tipo Integer
& nbsp & nbsp TPDObject = clase
& nbsp & nbsp privada
& nbsp & nbsp & nbsp & nbsp FID: TObjectID
& nbsp & nbsp publica
& nbsp & nbsp & nbsp & nbsp ID de la propiedad: TObjectID leer FID defecto NotAssigned
& nbsp & nbsp final
funcion StrToID (Valor: String): TObjectID
funcion IDToStr (Valor: TObjectID): String
aplicacion
...
final.
((( Fin del Listado 2 )))
((( Figura 1 - interaccion en la Clase overview )))
((( Final Figura 1 )))
el Siguiente en la serie