DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
What's in store for DevOps in 2023? Hear from the experts in our "DZone 2023 Preview: DevOps Edition" on Fri, Jan 27!
Save your seat
  1. DZone
  2. Data Engineering
  3. Data
  4. Local Microservices: Object Orientation Behavior Coupling Problem

Local Microservices: Object Orientation Behavior Coupling Problem

We look into Object Orientation, how it relates to microservces development, and the pros and cons inherent in the approach.

Daniel Sagenschneider user avatar by
Daniel Sagenschneider
CORE ·
Jun. 03, 19 · Analysis
Like (11)
Save
Tweet
Share
9.78K Views

Join the DZone community and get the full member experience.

Join For Free

This is the first in a three part series on looking at creating "local" microservices.

What I mean by local microservices is pass by reference microservices running in the same process. Right now, I see microservices similar to the original EJB 1.0 specification. All calls between the EJBs were remote, just like microservices are now. Due to remote call overheads, the EJB 2.0 specification brought in session (local, pass by reference) EJBs running in the same process.

Now, before getting to local microservices, we need to look at identifying the Object Orientation behavior coupling problem. This, to me, identifies a big problem that microservices resolve. It is also the reason for enabling local microservices.

Part One: Object Orientation Behavior Coupling Problem

Structurally, Object Orientation joins objects together in a very nice graph. These typically look something like the following:

Object Orientation

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 numbers, and various other objects containing information.

However, I can't call an object reference. I use the object reference to access a method on the object.  Behavior of your application actually follows the method calls. In other words, program controls follow method calls on the thread stack. Yes, the object references make methods accessible to be called, however, the methods calling each other is how the behavior of your application is achieved.

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.
  • a varying number of parameters with differing types.
  • a varying number of exceptions with differing types.
  • a thread to execute them.

Drawing a simple line between objects to represent behavioral relationships (program control flow) does not respect the method 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 call is a different shape. In terms of object structural connectors, the shape of the object reference is the object type and memory address. This is consistent across all object references. However, for methods the call (connectors) are different shapes due to the above five aspects. In other words, one method may haveone  parameter, while another has three and throws two exceptions. The shape of each method call connector varies significantly.

Drawing the behavior diagram of object method calls is more akin to the following:

Behavior diagram of object method calls

Each call (connector) between the methods is a different shape, just like a jigsaw puzzle.

We piece objects together into a jigsaw puzzle to achieve the behavior of the application. This is why refactoring your application is so difficult. It's like trying to move pieces of a jigsaw puzzle 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 behavioral 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 standardize jigsaw pieces and finding generic pictures that represent the majority of systems. However, I'm hoping you can join me in seeing that much of the Object Orientation behavior coupling 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 problems.

Object (computer science) microservice

Published at DZone with permission of Daniel Sagenschneider. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Architecture and Code Design, Pt. 2: Polyglot Persistence Insights To Use Today and in the Upcoming Years
  • Efficiently Computing Permissions at Scale: Our Engineering Approach
  • Handling Virtual Threads
  • Debugging Streams and Collections

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: