RoyalZSoftware
Back to Blog

Always separate integration and behavior code

Alexander Panov 2023-06-03 2 min read
Always separate integration and behavior code

In the world of software development, writing clean and maintainable code is essential for long-term success. One key principle that can greatly contribute to code clarity and reusability is splitting the integration and the actual behavior into two separate places.

My key point in this post: You should always, even if it remains in the same file, split your integration code from your business logic.

Understanding the fundamentals

When we refer to splitting integration and behavior, we are advocating for the separation of concerns within our codebase. Integration refers to communication with external systems or APIs, while behavior represents the core logic and functionality of our application.

Let's take the bowling game Kata as an example: The integration will be the UI; The business rules will say

  • "You can't have more than 10 points per throw"

  • "Hitting a strike will double next times points"

  • et cetera

Why Separate Integration and Behavior?

  1. Code Modularity / Testability: By separating integration and behavior, we create modular components that are easier to understand and maintain. Each component has a clear purpose and can be tested independently, leading to more robust and reliable code. Read about my top 5 tdd learnings

  2. Reusability: With a clear separation between integration and behavior, we can reuse the behavior logic in multiple integration scenarios. This allows us to avoid code duplication and improve overall code efficiency.

  3. Flexibility and Adaptability: When integration and behavior are decoupled, it becomes easier to modify or replace integrations without affecting the core behavior. This flexibility is especially valuable in situations where external systems or APIs change frequently.

Why am I telling you all this?

I had a conversation about this with a co-worker. He defended the YAGNI approach, which is indeed a great mantra to remind you not to over-engineer.

On the other side: Just creating a class that holds the behavior for our module. A class that doesn't know about the external dependencies, like:

won't hurt anybody and will make refactoring, testing and extending later on more pleasing.

Conclusion

In conclusion, separating integration and behavior in software development brings numerous benefits. It improves code clarity, maintainability, and reusability while enabling easier testing and flexibility for future changes. Embracing this practice empowers us to build robust and adaptable software solutions.

Level up your coding skills 🚀 with exclusive content on software development best practices. Join our newsletter community today for valuable insights and tips delivered straight to your inbox.

More articles

Building a Web Server in Go: A Beginner's Guide

Building a Web Server in Go: A Beginner's Guide

Oleksandr Vlasov 2024-11-26 3 min read
React Hooks — createContext, useContext, useMemo

React Hooks — createContext, useContext, useMemo

Oleksandr Vlasov 2024-10-23 4 min read
Mastering Git Rebase Interactive: Squashing Commits for a Clean History

Mastering Git Rebase Interactive: Squashing Commits for a Clean History

Alexander Panov 2024-10-21 2 min read