DEV Community: Sanudin

From OOP to SOLID: Everything You Need to Know in One Article

Sanudin — Sun, 24 May 2026 16:52:32 +0000

🕐 ~8 min read

📝 A note on this article
This post is based on my personal study notes on OOP and SOLID principles. To make these notes more readable and useful — for myself and for others — I worked with AI to help expand and structure them into a proper blog format. The ideas, learning journey, and understanding are mine; the AI helped with the writing and presentation.

Good code doesn't happen by accident. Behind every codebase that's a pleasure to work with, there's a set of ideas guiding how things are structured and connected.

This article covers that full journey — from what OOP is, how objects relate, what bad design looks like, and finally: the five SOLID principles that tie it all together.

Let's go.

Part 1: What Is OOP?

Object Oriented Programming (OOP) is a way of writing code that mirrors the real world. Instead of one long list of instructions, you group related data and behavior into objects.

🤖 Think of a robot toy. It has properties (color, height, battery) and behaviors (walk, talk, wave). In OOP, that robot is an object — and the blueprint used to build it is called a class.

Two key terms:

Class — the blueprint (template)
Object — a real instance built from the blueprint

The Four Pillars

Pillar	What it does
Inheritance	A child class inherits properties and behaviors from a parent class
Encapsulation	Internal data is hidden — only controlled access is allowed from outside
Abstraction	Complex internals are hidden; only what's needed is exposed
Polymorphism	The same action can behave differently depending on the object

Part 2: How Objects Relate

Objects don't exist in isolation. They connect, collaborate, and depend on each other — and the type of relationship matters.

Association

Two objects know about each other and can interact. Comes in three cardinalities:

One-to-one — one passport per person
One-to-many — one teacher, many students
Many-to-many — many students, many courses

Inside association, when one object "owns" another, the relationship is either:

Aggregation (loose) — the child survives without the parent. A backpack contains books, but the books still exist if you throw the backpack away.
Composition (tight) — the child cannot exist without the parent. A house has rooms; demolish the house, the rooms cease to exist.

Dependency

A temporary, usage-based relationship. One class uses another inside a method but doesn't hold onto it permanently. Weaker than association.

Generalization & Realization

Generalization — pulling shared traits from multiple classes into one superclass (inheritance)
Realization — a class implementing an interface, promising to fulfill a defined contract

Part 3: What Bad Design Looks Like

Before learning the rules, it helps to understand what you're guarding against. Robert C. Martin identified three symptoms of bad design:

🪨 Rigidity — the system is hard to change. Touch one thing, and a cascade of other things need updating. Developers become afraid to make changes.

🍪 Fragility — the system breaks in unexpected places when you make a change. You fix a bug in the payment module, and somehow the email notifications stop working.

🏗️ Immobility — useful components can't be reused. They're so entangled with their surroundings that extracting them would take longer than rewriting from scratch.

All three share the same root cause: poor management of dependencies between components.

Part 4: SOLID

SOLID is a set of five principles that directly address the problems above. Each one targets a specific failure mode.

S — Single Responsibility Principle

"A module should be responsible to one, and only one, actor."

Every class should have exactly one reason to change — it serves one actor (one group of stakeholders).

👨‍🍳 A restaurant worker who is simultaneously the chef, cashier, security guard, and delivery driver is a disaster waiting to happen. One change in one role disrupts all the others.

Split your classes. One responsibility each.

O — Open/Closed Principle

"A software artifact should be open for extension but closed for modification."

Add new behavior by extending — not by editing existing, working code.

🔌 A power strip lets you plug in new devices without rewiring the strip itself. That's OCP in action.

When requirements change, slot in new code alongside the old — don't rewrite what's already working.

L — Liskov Substitution Principle

"If S is a subtype of T, objects of type T may be replaced with objects of type S without altering program correctness."

A subclass must be fully substitutable for its parent class. Every promise the parent makes, the child must keep.

🤖 If the parent robot can cook, the child robot must be able to cook too — not throw an error or silently do nothing.

If your subclass has empty methods, stub implementations, or "not supported" throws — that's a Liskov violation.

I — Interface Segregation Principle

"Clients should not be forced to depend upon interfaces that they do not use."

Don't create fat interfaces that force classes to implement methods they don't need. Split interfaces into smaller, focused ones.

🍴 Don't give every restaurant customer a steak knife, soup spoon, chopsticks, and a fondue skewer when they only ordered soup.

Smaller interfaces = narrower dependencies = changes stay localized.

D — Dependency Inversion Principle

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

Your business logic should not be hardwired to specific implementations. It should talk to interfaces — and the low-level details implement those interfaces.

🤖 Don't solder a spatula into the robot's arm. Give the arm a standard connector, and let tools be swapped in and out.

This is what makes infrastructure (databases, APIs, file systems) swappable without touching business logic.

Quick Reference: SOLID at a Glance

Principle	Problem it solves	Key question to ask
SRP	Classes doing too much	"Does this class serve more than one group of stakeholders?"
OCP	Editing old code to add features	"Can I add this as an extension instead of a modification?"
LSP	Broken inheritance hierarchies	"Can I swap the child for the parent without anything breaking?"
ISP	Fat interfaces with unused methods	"Is this class forced to implement something it doesn't need?"
DIP	Business logic locked to infrastructure	"Does my high-level code depend on a concrete class it shouldn't?"

Where to Start

If you're applying these for the first time:

Start with SRP — find your "doing too much" classes and split them
Check inheritance for LSP violations — empty methods are the warning sign
Introduce interfaces at infrastructure boundaries — that's DIP in practice

These principles aren't a checklist. They're questions to ask every time you sit down to write code.

Originally published at sanudin.dev

Dari OOP ke SOLID: Semua yang Perlu Kamu Tahu dalam Satu Artikel

Sanudin — Sun, 24 May 2026 16:50:29 +0000

🕐 ~8 menit baca

📝 Catatan tentang artikel ini
Artikel ini dibuat berdasarkan catatan belajar pribadi saya tentang OOP dan prinsip SOLID. Untuk membuat catatan tersebut lebih mudah dibaca dan bermanfaat — bagi saya dan orang lain — saya menggunakan bantuan AI untuk mengembangkan dan menyusunnya menjadi artikel blog. Ide, perjalanan belajar, dan pemahamannya adalah milik saya; AI membantu di bagian penulisan dan penyajiannya.

Kode yang enak dibaca dan mudah diubah bukan kebetulan. Di balik setiap codebase yang menyenangkan untuk dikerjakan, ada sekumpulan ide yang memandu bagaimana semuanya disusun dan dihubungkan.

Artikel ini membahas perjalanan lengkap itu — mulai dari apa itu OOP, bagaimana objek saling berhubungan, seperti apa desain yang buruk, hingga akhirnya: lima prinsip SOLID yang menyatukan semuanya.

Yuk mulai.

Bagian 1: Apa Itu OOP?

Object Oriented Programming (OOP) adalah cara menulis kode yang mencerminkan dunia nyata. Alih-alih satu daftar panjang instruksi, kamu mengelompokkan data dan perilaku yang saling berkaitan ke dalam objek.

🤖 Bayangkan mainan robot. Robot punya properti (warna, tinggi, baterai) dan perilaku (berjalan, berbicara, melambaikan tangan). Dalam OOP, robot itu adalah objek — dan cetak biru yang digunakan untuk membuatnya disebut class.

Dua istilah kunci:

Class — cetak biru (template)
Object — wujud nyata yang dibuat dari cetak biru tersebut

Empat Pilar OOP

Pilar	Fungsinya
Inheritance	Class anak mewarisi properti dan perilaku dari class induk
Encapsulation	Data internal disembunyikan — akses dari luar hanya melalui jalur yang ditentukan
Abstraction	Kerumitan internal disembunyikan; hanya yang perlu digunakan saja yang ditampilkan
Polymorphism	Aksi yang sama bisa berperilaku berbeda tergantung pada objeknya

Bagian 2: Bagaimana Objek Saling Berhubungan

Objek tidak hidup sendiri-sendiri. Mereka terhubung, bekerja sama, dan saling bergantung — dan jenis hubungannya penting.

Asosiasi

Dua objek saling mengenal dan bisa berinteraksi. Ada tiga jenis kardinalitas:

One-to-one — satu orang satu paspor
One-to-many — satu guru, banyak murid
Many-to-many — banyak murid, banyak mata pelajaran

Dalam asosiasi, ketika satu objek "memiliki" objek lain, hubungannya bisa berupa:

Aggregation (longgar) — objek anak bisa hidup tanpa induknya. Tas ransel berisi buku, tapi bukunya tetap ada meski tasnya dibuang.
Composition (erat) — objek anak tidak bisa eksis tanpa induknya. Rumah punya kamar; hancurkan rumahnya, kamarnya ikut lenyap.

Dependency

Hubungan sementara berbasis pemakaian. Satu class memakai class lain di dalam sebuah method, tapi tidak menyimpannya secara permanen. Lebih lemah dari asosiasi.

Generalization & Realization

Generalization — mengangkat sifat-sifat yang sama dari beberapa class ke satu superclass (pewarisan)
Realization — sebuah class mengimplementasikan interface, berjanji untuk memenuhi kontrak yang sudah didefinisikan

Bagian 3: Seperti Apa Desain yang Buruk?

Sebelum belajar aturannya, penting untuk memahami apa yang sedang kita hindari. Robert C. Martin mengidentifikasi tiga gejala desain yang buruk:

🪨 Rigidity (Kekakuan) — sistem susah diubah. Sentuh satu hal, dan banyak hal lain ikut perlu diperbarui. Developer jadi takut untuk melakukan perubahan.

🍪 Fragility (Kerapuhan) — sistem rusak di tempat yang tidak terduga saat kamu melakukan perubahan. Kamu memperbaiki bug di modul pembayaran, tiba-tiba notifikasi email berhenti berfungsi.

🏗️ Immobility (Ketidakmampuan Dipindahkan) — komponen yang berguna tidak bisa dipakai ulang. Mereka terlalu kusut dengan sekitarnya sehingga mencabutnya butuh lebih lama dari menulis ulang dari awal.

Ketiganya punya akar penyebab yang sama: pengelolaan dependensi antar komponen yang buruk.

Bagian 4: SOLID

SOLID adalah lima prinsip yang secara langsung mengatasi masalah di atas. Masing-masing menargetkan kegagalan desain yang spesifik.

S — Single Responsibility Principle

"Sebuah modul harus bertanggung jawab pada satu, dan hanya satu, aktor."

Setiap class harus punya tepat satu alasan untuk berubah — ia melayani satu aktor (satu kelompok stakeholder).

👨‍🍳 Seorang pekerja restoran yang sekaligus menjadi koki, kasir, satpam, dan pengantar makanan adalah bencana yang menunggu terjadi. Perubahan di satu peran mengganggu semua peran lainnya.

Pisahkan class-mu. Satu tanggung jawab per class.

O — Open/Closed Principle

"Artefak perangkat lunak harus terbuka untuk ditambahkan, tapi tertutup untuk dimodifikasi."

Tambahkan perilaku baru dengan cara memperluas — bukan mengedit kode lama yang sudah berjalan.

🔌 Stop kontak memungkinkan kamu mencolokkan perangkat baru tanpa perlu membongkar kabelnya. Itulah OCP dalam praktik.

Ketika kebutuhan berubah, tambahkan kode baru di samping yang lama — jangan tulis ulang yang sudah berjalan.

L — Liskov Substitution Principle

"Jika S adalah subtipe dari T, objek bertipe T bisa digantikan dengan objek bertipe S tanpa mengubah kebenaran program."

Sebuah subclass harus sepenuhnya bisa menggantikan class induknya. Setiap janji yang dibuat induk, harus dipenuhi oleh anak.

🤖 Kalau robot induk bisa memasak, robot anak juga harus bisa memasak — bukan melempar error atau diam saja tanpa melakukan apa-apa.

Kalau subclass-mu punya method kosong, implementasi stub, atau melempar "not supported" — itu pelanggaran Liskov.

I — Interface Segregation Principle

"Client tidak boleh dipaksa bergantung pada interface yang tidak mereka gunakan."

Jangan buat interface besar yang memaksa class mengimplementasikan method yang tidak mereka butuhkan. Pecah interface menjadi bagian-bagian kecil yang lebih fokus.

🍴 Jangan berikan setiap pelanggan restoran pisau steak, sendok sup, sumpit, dan tusuk fondue ketika mereka hanya memesan sup.

Interface yang lebih kecil = dependensi yang lebih sempit = perubahan tetap terlokalisir.

D — Dependency Inversion Principle

"Modul tingkat tinggi tidak boleh bergantung pada modul tingkat rendah. Keduanya harus bergantung pada abstraksi."

Logika bisnis tidak boleh terkait langsung dengan implementasi spesifik. Ia harus bicara dengan interface — dan detail tingkat rendah yang mengimplementasikan interface tersebut.

🤖 Jangan solder spatula ke tangan robot. Beri tangannya konektor standar, dan biarkan alat-alatnya bisa diganti-ganti.

Inilah yang membuat infrastruktur (database, API, file system) bisa diganti tanpa menyentuh logika bisnis.

Ringkasan Cepat: SOLID Sekilas

Prinsip	Masalah yang diatasi	Pertanyaan kuncinya
SRP	Class mengerjakan terlalu banyak hal	"Apakah class ini melayani lebih dari satu kelompok stakeholder?"
OCP	Mengedit kode lama untuk menambah fitur	"Bisakah ini ditambahkan sebagai ekstensi, bukan modifikasi?"
LSP	Hirarki pewarisan yang rusak	"Bisakah anak menggantikan induk tanpa ada yang rusak?"
ISP	Interface gemuk dengan method yang tidak dipakai	"Apakah class ini dipaksa mengimplementasikan sesuatu yang tidak dibutuhkan?"
DIP	Logika bisnis terikat ke infrastruktur	"Apakah kode tingkat tinggi bergantung pada class konkret yang seharusnya tidak?"

Mulai dari Mana?

Kalau kamu baru pertama kali menerapkan ini:

Mulai dengan SRP — cari class yang "mengerjakan terlalu banyak" dan pecah
Periksa pewarisan untuk pelanggaran LSP — method kosong adalah tanda peringatannya
Tambahkan interface di batas infrastruktur — itulah DIP dalam praktik

Prinsip-prinsip ini bukan checklist. Mereka adalah pertanyaan yang perlu kamu ajukan setiap kali duduk untuk menulis kode.

Originally published at sanudin.dev