As software systems grow more complex, it's easy for code to become tangled, with classes that do too much, logic that's hard to reuse, and changes in one place breaking unrelated parts of the app. To combat this, developers lean on design principles, guidelines that help us write clean, modular, and maintainable code. One of the most influential sets of principles in modern software engineering is known as 'SOLID'. SOLID outlines five key rules for object-oriented design. But even beyond OOP, these principles help teams write better code , whether you're building a mobile app, scripting in shell, or designing a backend service.

Understanding SOLID means understanding how to break software into well-defined, independent parts — so each part is easier to change, extend, and reason about.

Not literally, the SOLID principles were coined for object-oriented programming by Robert C. Martin (Uncle Bob). Unix, on the other hand, is rooted in process-based design, with utilities built primarily in C and shell scripts, not classes and objects.

But philosophically, Unix aligns with many of the same ideas, especially the most important one: Single Responsibility Principle (SRP).

What is SOLID? Why it Matters

SOLID is an acronym for five design principles that aim to make software easier to understand, maintain, and extend.

These principles are key in OOP and Clean Architecture — but they also echo Unix's composable, minimalist philosophy.

A class should have one, and only one, reason to change.

It means every class (or function, or module) should do one thing well. If it has multiple responsibilities, it will be harder to maintain and more prone to bugs.

Each command-line utility is designed to do one job and do it well.

Examples:

• grep - filters lines that match a pattern
• cut - extracts specific columns or fields
• sort - sorts lines in a file or stream

These tools are intentionally small and composable. You combine them using pipes (|) to build complex behaviors.

Example:

cat access.log | grep 404 | cut -d' ' -f1 | sort | uniq -c | sort -nr

Each tool:

• Does one thing
• Can be updated independently
• Has a clear reason to change

That’s SRP — just not in class-based code, but in process-based design.

Unix doesn't enforce these principles through classes — but its *culture* encourages similar separation of concerns.

SRP isn’t just for classes. In an Android app (especially with Clean Architecture), SRP applies to:

• Presentation layer: handles UI state only
• Domain layer: handles business logic
• Data layer: handles data access

• ViewModel: handles user interactions and state
• UseCase: handles one specific business operation (e.g., GetUserPosts)
• Repository: abstracts data source access (e.g., DB, network)

If a component does too many things — UI + business logic + data access — it becomes hard to test, understand, or change.

Here’s a conceptual side-by-side comparison:

Both systems:

• Break problems into small, testable steps
• Compose functionality through clearly defined boundaries
• Emphasize separation of concerns

"Software entities should be open for extension but closed for modification."

How Unix achieves this:

• You 'extend' commands by combining them in scripts
• You 'wrap' commands with functions or aliases (without changing internal code)
• Environment variables (e.g., $PAGER, $EDITOR) let programs integrate external tools

Example:

mygrep() {
  grep --color=auto "$@" | less
}

The grep command wasn’t modified — it was extended.

"High-level modules should not depend on low-level modules. Both should depend on abstractions."

Unix tools don't have formal abstractions (like interfaces or abstract classes), but:

• They rely on text streams — a form of implicit interface
• You can swap tools if they follow common conventions (e.g., replacing less with more)
• You can script plug-in architectures with exec calls or sourcing shell functions dynamically

Example:

if [ -x ./mybackend ]; then
  ./mybackend "$@"
else
  default_backend "$@"
fi

This allows swappable implementations — an inversion of control.

• Unix strongly embodies SRP: each tool does one thing.
• Other SOLID principles (especially Interface Segregation and Open/Closed) show up in Unix behavior, if not structure.
• Whether in pipes or layers, the key is small, composable, testable units that reduce coupling and increase maintainability.

This is one of the hardest and most important questions in applying the Single Responsibility Principle (SRP) well. There’s no universal line, it’s a judgment call, but there are practical guidelines and heuristics to help you decide when a piece of code needs to be split due to too many responsibilities.

Don’t split prematurely, SRP is about clarity and safety, not bureaucracy.

A responsibility is a reason to change, not just a “thing it does.”

**Robert C. Martin (Uncle Bob):**“A responsibility is a reason to change.”

So the key test is: If a change request comes in, which part of this component will it affect?

Signal: If two or more distinct types of changes would require touching the same file/class/module.

Examples:

• You need to change a UI layout and also fix a bug in database syncing — and both require touching the same class? Split it.

If you're struggling to write a small, focused unit test, the class probably does too much.

Heuristic:

• If you must mock too many unrelated dependencies to test a method, that method may not have a single responsibility.

Signal: The class uses concepts from more than one domain.

Android example:

snippet.kotlin

class UserProfileManager {
    fun drawUI() { ... }
    fun fetchFromServer() { ... }
    fun saveToDatabase() { ... }
}

This class:

• knows how to draw,
• talks to network,
• and stores to local DB.

These are 3 separate domains → split it.

When one class keeps being involved in a wide variety of issues or changes — it's a red flag.

There’s no magic LOC number, but if:

• You can't explain what a class does in one sentence,
• Or a function needs multiple scrolls to read through,

…it likely violates SRP.

Split when:

• You have more than one reason to change,
• Code spans multiple unrelated concerns,
• Testing becomes awkward,
• Changes become risky or confusing.

That’s a deep and important question, and the answer depends on balancing project scope, risk, and maintenance horizon.

My minimum: For a solo developer or small team, I’d adopt Clean Architecture principles (modular layers, separation of concerns, testability) as soon as:

• The app has multiple distinct business rules, user flows, or data sources.
• It’s expected to evolve or be maintained for months or more.
• There’s a need for testing logic independently of the UI or Android framework.

That threshold can be surprisingly low — for example:

• An Android podcast player with downloads, metadata fetching, playback, favorites
• A task manager with offline sync and reminders
• A health tracking app with charts and history

If your app:

• Has more than one core feature,
• Or touches more than one domain (UI, DB, network),
• Or is not trivial to unit test as-is…

…then going with a modular layered approach like Clean Architecture pays off early.

Clean Architecture is not needed (and can actively slow you down) if:

• You’re building a throwaway prototype or MVP.
• The app has one screen, one user flow, or just UI + local data.
• You’re solo, and need to ship fast, with low future change risk.

Example: A flashlight app, a simple calculator, a QR scanner, you can write these with just an Activity and a couple helper classes. No need for UseCases, Repositories, DataSources, etc.

You don’t need to go full Clean from day one.

Here’s a path:

1. Start flat with clear separation: UI → ViewModel → Repo → Network/DB.
2. As logic grows, extract UseCases to isolate operations.
3. If the app keeps growing, split into domain, data, and presentation modules.
4. Add interfaces and DI (like Hilt/Koin) to fully decouple and test.

This is sometimes called “clean-lite” or “onion-by-need”.

• The app has nontrivial logic, multiple domains, or business rules.
• You plan to maintain/test/grow it seriously.
• You want a clear separation of concerns.

• It’s just UI + a bit of state.
• You're prototyping.
• Overhead will slow you more than help.

snippet.cpp

by:
▖     ▘▖▖
▌ ▌▌▛▘▌▙▌
▙▖▙▌▙▖▌ ▌
 
published: June 16 2025.