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
Please enter at least three characters to search
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

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

Because the DevOps movement has redefined engineering responsibilities, SREs now have to become stewards of observability strategy.

Apache Cassandra combines the benefits of major NoSQL databases to support data management needs not covered by traditional RDBMS vendors.

The software you build is only as secure as the code that powers it. Learn how malicious code creeps into your software supply chain.

Generative AI has transformed nearly every industry. How can you leverage GenAI to improve your productivity and efficiency?

Related

  • Transitioning from Monolith to Microservices
  • MuleSoft: Do You Have an Extra Mule Under the Hood?
  • Introduction Garbage Collection Java
  • Monolithic First

Trending

  • GitHub Copilot's New AI Coding Agent Saves Developers Time – And Requires Their Oversight
  • The Future of Java and AI: Coding in 2025
  • Scaling Microservices With Docker and Kubernetes on Production
  • Rust, WASM, and Edge: Next-Level Performance
  1. DZone
  2. Software Design and Architecture
  3. Microservices
  4. Why Object-Oriented Code Accelerates Microservices Adoption

Why Object-Oriented Code Accelerates Microservices Adoption

Using OOP can be a great boon to your team's efforts to adopt microservices or refactor a monolithic application. Read on to find out why.

By 
Muntazir Fadhel user avatar
Muntazir Fadhel
·
Mar. 21, 19 · Analysis
Likes (4)
Comment
Save
Tweet
Share
9.0K Views

Join the DZone community and get the full member experience.

Join For Free

not all monoliths are created equal. even with the best solution architects, developers, and financial resources available, a legacy application’s microservices transformation journey will be a nightmare if the code is not object-oriented.

wanting to benefit from the scalability and cost-efficiency of cloud technologies, organizations are increasingly migrating their monolithic applications to microservices- and serverless-based architectures. due to the nature of typical monoliths, however, this migration is often a long and difficult process.

why, you ask? because the most time-consuming aspect of the migration journey involves decoupling the monolith into smaller, more refined services while ensuring that these new components have the desirable properties of a distributed system (autonomy, scalability, and so on).

and this decoupling process will be much more frustrating and tedious than necessary if the code does not have certain characteristics that make it easy to split up and re-compose into smaller and more focussed components. in this article, i’ll demonstrate how four key object-oriented programming principles accelerate this process.

by the end, i hope that you’ll seriously consider writing high-quality object-oriented code when starting your next greenfield project so that you can avoid many of the difficulties typically associated with microservices adoption down the road.

do one thing well

classes that take on many responsibilities or contain a lot of data, also known as god classes, are very difficult to read, maintain, and extend due to their enormous size. for this reason, classes in an object-oriented design should focus on doing one thing well, and behave as a logically single, atomic unit. if the complexity of an object exceeds a reasonable level, it should be refactored into two or more separate entities.

object-oriented programming

when we consider that each service in a microservices architecture should focus on a specific domain, this method of designing classes gives us a great deal of flexibility in determining how we want to decouple a monolithic application into such services.

as an example, consider a scenario where a code base consists of many god classes. clearly, your ability to decouple the application into services that focus on specific domains is severely limited because the basic building blocks of these services (i.e the objects themselves) are extremely broad and unfocused. in such scenarios, you’ll have to refactor those large classes into smaller components that have fewer responsibilities before you can compose them into microservices with the desired level of granularity.

message passing

perhaps the most misunderstood aspect of object-oriented systems is inter-object communication. in fact, a method call was not the way modules in an object-oriented system were intended to communicate, rather it was through messaging .

the difference between them is in the way we perceive method calls versus messages. calling a method essentially puts the person making the method call in control of running the process. the caller gets the callee to do something and prevents it from doing something that the caller does not want. message passing, on the other hand, revolves around negotiation, and this is the key in building object-oriented systems.

message-passing method calling vs. content negotiation via message passing

a major challenge in converting a monolith into microservices based architecture lies in re-designing its communication mechanism. microservices are ideally integrated using asynchronous communication to enforce microservice autonomy and to develop an architecture that is resilient when microservices fail or underperform.

the problem arises when code is written in a procedural and imperative way. breaking up a monolith that consists of such code into microservices will force architects to implicitly use synchronous communication patterns right from the onset when that might not be the most optimal solution.

synchronous vs. asynchronous communication

on the other hand, code that practices message passing facilitates the decoupling of a monolith into microservices that communicate using asynchronous patterns to a great degree. a module that practices message passing properly does not require any response from the client in other for it to continue doing its job. it does not control its clients and assumes that any client modules receiving its messages are smart enough to do whatever needs to be done next. the final result of composing such objects into microservices is an architecture that can be adapted to use asynchronous communication mechanisms with little effort.

coupling

coupling represents the degree to which a module or object is independent of others. a highly coupled module relies on and modifies the states and internals of other objects to do its job, whereas a loosely coupled module relies on a minimal set of interfaces belonging to other objects to do its job.

object-oriented systems generally avoid highly coupled modules since they are increasingly difficult to maintain and test as more components are introduced into the system. unsurprisingly, distributed cloud architectures also favor the design of services and components that do not rely on many other components to do its job. in this case, however, the motivating goal is to support component evolution.

coupling

that is to say, components in a distributed architecture should have the ability to be changed, upgraded, or replaced independently without affecting the functioning of other components. this requires microservices to be designed in a way that makes them primarily responsible for running their own show. in return, teams responsible for different services will have the autonomy to make decisions and act independently from each other.

with that said, you can only decouple your monolith into services that maintain their autonomy to the degree of autonomy the individual objects composing those services have, which comes down to coupling. therefore, loosely coupled code will lend itself to autonomous services, while highly coupled code will need a lot of refactoring before it can achieve this goal.

information hiding

'information hiding' refers to the process of writing modules in a way that keeps their details relating to core design decisions, especially those that are expected to change, hidden from other objects. as a result, callers of an object are effectively decoupled from its internal workings, which makes it possible for the ‘hidden’ parts to change without needing to change the way the object is called.

information hiding

this principle is also a desirable property for components in microservices/serverless-based architectures. a microservice, for example, should be designed as a black box in which its internal complexity and details are hidden from other services in the system. because of this, communication between services can now take place via well defined apis, which is a desirable trait of microservice architectures.

it should be easy to see now why the process of decoupling a monolith that practices information hiding into microservices that behave as black boxes is a straight forward task. simply put, each class that practices information hiding already behaves like a mini black box of sorts, which makes composing them into larger microservices that behave as black boxes easier.

on the other hand, if information hiding is not properly observed in the original code, you are at risk of decoupling the monolith into microservices that depend on the internal workings of other microservices to provide their service. obviously, this will hurt the maintainability and evolution of the overall architecture.

in closing

the functioning and design of an ideal microservice shares many characteristics with the functioning and design of an ideal object in an object-oriented system. for this reason, any process of migrating a monolithic application to a microservices-like architecture will be greatly simplified if the application exhibits good object-oriented practices in the first place.

do you think there are any other programming principles in or outside oop that can benefit the migration of a monolithic application to the cloud? let me know in the comments below!

microservice code style Architecture Information hiding Message passing Object (computer science) application Adoption

Published at DZone with permission of Muntazir Fadhel. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • Transitioning from Monolith to Microservices
  • MuleSoft: Do You Have an Extra Mule Under the Hood?
  • Introduction Garbage Collection Java
  • Monolithic First

Partner Resources

×

Comments
Oops! Something Went Wrong

The likes didn't load as expected. Please refresh the page and try again.

ABOUT US

  • About DZone
  • Support and feedback
  • Community research
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

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

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends:

Likes
There are no likes...yet! 👀
Be the first to like this post!
It looks like you're not logged in.
Sign in to see who liked this post!