This is the first in a three part series on how I see microservices are helping in relieving the Object Orientation behaviour coupling problems. In looking at this problem, it identifies the ability for “local” microservices.
The three part series will look at the following:
- Identifying the Object Orientation behaviour coupling problem
- How microservices are reducing this coupling problem
- How local microservices can avoid unnecessary heavy weight overheads
What I mean by local microservices is pass by reference microservices. Right now I see microservices similar to the EJB 1.0 specification. All calls between the EJBs were remote, just like microservices are now. Due to remote call overheads, EJB 2.0 brought in session (local, pass by reference) EJBs.
Now we may argue that infrastructure and networks have improved significantly over the last 20 years. This improvement in networks may be to the point that arguing about technical overheads may not hold. However, hosting each microservice individually within the cloud can have real dollar implications too. Being able to have local microserivces running in the same container may actually be the financial overhead driver for going local.
There are also other reasons for local microservices, such as refactoring efforts of remote microservices. Plus we examine the question of deploying independently when they are all local in the same deployed container. However, we will cover these in the later parts of this series. For part one, we are going to look at identifying the Object Orientation behaviour coupling problem.
Part One: Object Orientation Behaviour Coupling Problem
Structurally Object Orientation joins objects together in a very nice graph. These typically look something like the following:
These graphs represent the object relationships in your application. Each line is a field reference to another object. This, for example, allows modelling your personal details to have addresses, phone number and various other objects containing information.
However, this structure does not represent the behaviour of the application. It only indicates the structural relationship between objects. I can’t call an object reference. I use the object reference to access a method on the object. Behaviour of your application actually follows the method calls, not the above structural graph lines. In other words, program control does not follow heap memory object references. Program control follows method calls on the thread stack.
So, we can just draw the above graph with the methods calls, right? No, the method coupling is a lot more complicated than just an object reference that varies at most by type (see Inversion of Coupling Control). Methods have:
- a particular return type
- a name
- varying number of parameters with differing types
- varying number of exceptions with differing types
- thread to execute them
Drawing a simple line between objects to represent behavioural relationships does not respect the behavioural coupling complexity. In the object structural graph, changing a line is simply changing the reference (memory address) to another object. Yes, restrictions apply based on the type of object referenced, but it is a single address value that couples the two objects into a structural relationship. This is not the case with methods.
Each method behaviour connector is a different shape. In terms of object structural connectors the shape of the object reference is object type and memory address. This is consistent across all object references. However, for methods the connectors are different shapes due to the above 5 aspects. In other words, one method may have 1 parameter, while another has 3 and throws 2 exceptions. The shape of each method call connector varies significantly.
Drawing the behaviour diagram of objects is more akin to the following:
Each connector between the methods is a different shape, just like a jigsaw.
We piece objects together into a jigsaw to achieve the behaviour of the application. This is why refactoring your application is so difficult. It’s like trying to move pieces of a jigsaw around to make a new picture. We end up having to change the pieces significantly just so they even attempt to fit into the new picture.
It is also the reason, I believe, why object orientation never provided that ideal class re-use. Re-using objects is like trying to re-use jigsaw pieces of one puzzle to complete another puzzle. Now if the puzzles are somewhat alike, you can kinda jam them together. However, more often than not you have to change the piece (object) to fit into the other jigsaw (application) losing re-use.
Hence, the method coupling problem creates a significant behavioural coupling problem in monolithic Object Oriented systems. Refactoring is an expensive exercise, as its not redrawing lines between nice round objects. Refactoring is reshaping pieces to fit into a new jigsaw picture.
Now I can continue the analogy further with much of API development attempting to standardise jigsaw pieces and finding generic pictures that represent majority of systems. However, I’m hoping you can join me in seeing that much of Object Orientation behaviour problem is not with the objects but rather the use of methods.
And yes, for Object Orientation purists, Object Orientation is more about loosely coupled message passing. In other words, languages such as Erlang may be more closer to what the intention of Object Orientation really was supposed to be. However, my focus here is the “mainstream” understanding of Object Orientation being objects and methods.
Stay tuned for my next part on how microservices are helping with relieving the Object Orientation method coupling problem.
Published on Java Code Geeks with permission by Daniel Sagenschneider, partner at our JCG program. See the original article here: Local Microservices: Object Orientation Behaviour Coupling Problem Opinions expressed by Java Code Geeks contributors are their own. |
i did not get the message of this article. What is the problem?
Methods. They are the real shape of the object. In original intentions of OO, it was supposed to be message passing. However, “mainstream” OO direction went with methods. Methods are not simple messages being passed. They create a significant coupling to caller. I require a new parameter (or even remove a parameter), all client calls need to change. I throw a new Exception and now all my client calls need to change. I change anything about the method signature and I’m “refactoring” all my client calls. This is significant coupling problem. So much so, “mainstream” OO is more like a… Read more »