oop - sirve - Servicio-Orientación vs Objeto-Orientación: ¿pueden coexistir?

que es un objeto en programacion

Question

Ha habido un gran interés en la arquitectura orientada a servicios (SOA) en mi empresa recientemente. Cada vez que intento ver cómo podemos usarlo, siempre tropiezo con un bloqueo mental. En bruto:

• La orientación a objetos dice: "mantener juntos los datos y métodos que manipulan datos (procesos de negocios)";

• La orientación al servicio dice: "mantener el proceso comercial en el servicio y pasarle datos".

Los intentos previos de desarrollar SOA terminaron convirtiendo el código orientado a objetos en estructuras de datos y procedimientos separados (servicios) que los manipulaban, lo que parece un paso atrás.

Mi pregunta es: ¿qué patrones, arquitecturas, estrategias, etc. permiten que SOA y OO trabajen juntos?

Editar: Las respuestas que dicen "OO para interiores, SOA para límites de sistema" son geniales y útiles, pero esto no es exactamente lo que estaba tratando.

Supongamos que tiene un objeto Account que tiene una operación comercial llamada Merge que lo combina con otra cuenta. Un enfoque OO típico se vería así:

Account mainAccount = database.loadAccount(mainId);
Account lesserAccount = database.loadAccount(lesserId);
mainAccount.mergeWith(lesserAccount);
mainAccount.save();
lesserAccount.delete();

Mientras que el equivalente SOA que he visto se ve así:

Account mainAccount = accountService.loadAccount(mainId);
Account lesserAccount = accountService.loadAccount(lesserId);
accountService.merge(mainAccount, lesserAccount);
// save and delete handled by the service

En el caso OO, la lógica de negocios (y el conocimiento de la entidad gracias a un patrón ActiveRecord) se integran en la clase Account . En el caso SOA, el objeto Account es realmente solo una estructura, ya que todas las reglas comerciales están ocultas en el servicio.

¿Puedo tener clases funcionales y servicios reutilizables al mismo tiempo?

Answer 1

Creo que esto es un malentendido de la orientación del objeto. Incluso en Java, los métodos generalmente no son parte de los objetos sino de su clase (e incluso esta "membresía" no es necesaria para la orientación del objeto, pero ese es un tema diferente). Una clase es solo una descripción de un tipo, por lo que esto es realmente una parte del programa, no los datos.

SOA y OO no se contradicen entre sí. Un servicio puede aceptar datos, organizarlos en objetos internamente, trabajar en ellos y finalmente devolverlos en el formato que desee.

Answer 2

Escuché a James Gosling decir que uno podría implementar SOA en COBOL.

Si lees la propia descripción de Alan Kay sobre los orígenes de OOP, describe un grupo de pequeñas computadoras que interactúan para realizar algo útil.

Considera esta descripción:

Tu X debe estar compuesta por Ys. Cada Y debe ser responsable de un concepto único, y debe describirse por completo en términos de su interfaz. Una Y puede solicitar a otra Y que haga algo mediante un intercambio de mensajes (según sus interfaces especificadas).

En algunos casos, una X puede ser implementada por una Z, que administra según su interfaz. No X tiene permitido el acceso directo a la Z de otra X.

Creo que las siguientes sustituciones son posibles:

Term Programing Architecture
---- --------------- ------------
X Program System
Y Objects Services
Z Data structure Database
---- --------------- ------------
result OOP SOA

Si piensas principalmente en términos de encapsulación, ocultamiento de información, acoplamiento flexible e interfaces de caja negra, hay bastante similitud. Si te empantanas en polimorfismo, herencia, etc. estás pensando en programación / implementación en lugar de arquitectura, en mi humilde opinión.

Answer 3

Mi opinión es que SOA puede ser útil, a nivel macro, pero probablemente cada servicio será lo suficientemente grande como para necesitar varios componentes internos. Los componentes internos pueden beneficiarse de la arquitectura OO.

La API SOA debe definirse con más cuidado que las API internas, ya que es una API externa. Los tipos de datos pasados ​​en este nivel deben ser lo más simples posible, sin lógica interna. Si hay alguna lógica que pertenece al tipo de datos (por ejemplo, validación), preferiblemente debería haber un servicio a cargo de ejecutar la lógica en el tipo de datos.

Answer 4

Realmente creo que SOA solo es útil para interfaces externas (en general, para aquellos que están fuera de su empresa), e incluso entonces, solo en casos en los que el rendimiento realmente no importa, no necesita entrega ordenada de mensajes.

A la luz de eso, creo que pueden coexistir. Mantenga sus aplicaciones funcionando y comunicándose utilizando la filosofía OO, y solo cuando se necesiten interfaces externas (a terceros), expongalas a través de SOA (esto no es esencial, pero es de una sola manera).

Realmente siento que SOA se usa en exceso, o al menos las arquitecturas con SOA son propuestas con demasiada frecuencia. Realmente no conozco ningún gran sistema que use SOA internamente, y dudo que puedan hacerlo. Parece que hay más de una cosa que podrías usar para hacer mashups o simples solicitudes de tipo de pronóstico del clima, además de construir sistemas serios.

Answer 5

SOA es una buena arquitectura para comunicarse entre sistemas o aplicaciones.

Cada aplicación define una interfaz de "servicio" que consiste en las solicitudes que manejará y espera.

Los puntos clave aquí son servicios bien definidos, con una interfaz bien definida. Cómo se implementan realmente sus servicios es irrelevante en lo que respecta a SOA.

Así que usted es libre de implementar sus servicios usando los últimos y mejores teóricos de OO, o cualquier otra metodología que le resulte útil. (He visto casos extremos en los que el "servicio" está implicado por personas reales que ingresan datos en una pantalla, ¡pero todo seguía siendo un libro de texto SOA!).

Answer 6

Si permite que sus servicios recuerden el estado, entonces pueden ser considerados como objetos grandes con un tiempo de invocación posiblemente lento.

Si no se les permite conservar el estado, entonces son tal como lo dijo: operadores con datos.

Parece que puede estar dividiendo su sistema en demasiados servicios. ¿Ha escrito un criterio de mutuo acuerdo sobre cómo dividir?

Adoptar SOA no significa tirar todos tus objetos, sino dividir tu sistema en grandes trozos reutilizables.