DEV Community: Sanudin

Git & Collaboration: A Beginner's Guide (With Real Analogies)

Sanudin — Mon, 08 Jun 2026 00:39:41 +0000

🌐 Read this post in Bahasa Indonesia here.

📝 A note on this article
This post is based on my personal study notes on version control and Git collaboration. 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.

Learning Git doesn't have to be intimidating. In this article, I'll break down the essential concepts of version control and collaboration — using simple analogies that anyone can understand.

What Is Git?

Git is a version control system. Think of it as a save system for your code — like save points in a video game. Every time you save (commit), Git remembers the state of your project at that moment. If something goes wrong, you can always go back.

Repository: Your Project's Warehouse

A repository (or "repo") is the folder that Git watches. There are two types:

Local repository: lives on your computer. Your personal workspace.
Remote repository: lives on a server (GitHub, GitLab, Bitbucket). The "official" shared copy your team can access.

They stay connected through a Remote URL, so you can push your local changes up and pull others' changes down.

git init                            # Start tracking a folder
git remote add origin <url>         # Connect to a remote repo
git push origin main                # Send commits to remote
git pull origin main                # Get latest from remote

Commit: Your Project's Save Point

A commit is a snapshot of your project at a specific moment. Each commit has:

A message describing what changed
A unique ID (hash)
A timestamp

git add .                           # Stage all changes
git commit -m "Add homepage layout" # Save a snapshot
git log --oneline                   # View commit history

Write meaningful commit messages. Future you will thank present you.

Checkout, Reset, Revert: Traveling Through Time

These three commands all interact with your commit history — but in very different ways:

`git checkout` — Visit the Past (Temporarily)

Like a time traveler with a visitor's pass. You can look around at an old commit without changing anything permanently.

git checkout <commit-hash>          # Visit an old commit
git checkout main                   # Go back to the present
git checkout -b new-branch <hash>   # Start a new branch from old commit

`git reset` — Erase History

Goes back to a past commit and removes everything that came after. Use with care — especially if you've already pushed.

git reset --soft HEAD~1             # Undo last commit, keep changes staged
git reset --hard HEAD~1             # Undo last commit, delete changes too

`git revert` — The Safe Undo

Creates a new commit that reverses a previous one. History stays intact — the safest option when working on a shared repo.

git revert <commit-hash>            # Undo a commit safely

Rule of thumb: if you've already pushed, use revert. If you haven't, reset is fine.

Branches: Parallel Universes for Your Code

A branch is an independent line of development. You can create branches to work on features or fixes without touching the stable main branch.

git switch -c feature/dark-mode     # Create and switch to new branch
git switch main                     # Switch back to main
git branch -d feature/dark-mode     # Delete merged branch
git push origin feature/dark-mode   # Push branch to remote

A common branch naming convention:

Type	Prefix	Example
New feature	`feature/`	`feature/dark-mode`
Bug fix	`fix/`	`fix/login-redirect`
Urgent fix	`hotfix/`	`hotfix/payment-crash`

Stash: The Pause Button for Unfinished Work

You're halfway through a feature. Code is messy, not ready to commit. Then your team lead says: "Can you quickly fix that bug on main?"

You can't switch branches with uncommitted changes. But you're not ready to commit either. The answer: stash it.

Analogy: You're drawing a picture but need to use the table for something else. You put everything in a drawer. Later, you open the drawer and continue exactly where you left off.

git stash                           # Save work temporarily
git switch fix/some-bug             # Switch branches freely
# ... fix the bug, commit, come back ...
git switch feature/dark-mode
git stash pop                       # Restore your work

Adding a label makes it easier to manage multiple stashes:

git stash push -m "WIP: dark mode palette"   # Named stash
git stash list                               # See all stashes
git stash pop                                # Restore latest
git stash apply stash@{1}                    # Restore specific (keep in list)
git stash drop stash@{1}                     # Remove specific
git stash -u                                 # Include untracked (new) files

Merge & Pull Requests: Bringing It All Together

When your feature is ready, you merge it back into main.

git switch main
git merge feature/dark-mode

On GitHub/GitLab, this is typically done through a Pull Request (PR) — a formal process where:

You push your branch and open a PR
Teammates review your code and leave feedback
Once approved, it gets merged

Merge Options

Method	What happens
Merge commit	All commits preserved + merge commit added
Squash and merge	All commits squashed into one
Rebase and merge	Commits replayed on top of main, no merge commit

Handling Conflicts

When two branches edit the same line, Git can't auto-merge. You'll see:

<<<<<<< HEAD
const msg = "Hello!";
=======
const msg = "Hi there!";
>>>>>>> feature/dark-mode

Manually resolve it, then:

git add <file>
git commit

Code Reviews: The Quality Gate

Before a PR is merged, someone reviews it. Good reviewers check for:

Logical correctness
Readability and naming
Test coverage
Complexity (is it simpler than it needs to be?)
Style guideline compliance

Code reviews aren't just about catching mistakes — they're also how knowledge spreads through a team.

Fork & Clone: Contributing Without Access

Forking copies someone else's repo into your GitHub account. Cloning copies a repo to your local machine.

The typical open-source contribution flow:

# 1. Fork on GitHub (click the Fork button)

# 2. Clone your fork
git clone https://github.com/your-username/the-project.git

# 3. Add original repo as upstream
git remote add upstream https://github.com/original-owner/the-project.git

# 4. Create a branch, make changes, push
git switch -c fix/typo-readme
git add . && git commit -m "Fix typo in README"
git push origin fix/typo-readme

# 5. Open a Pull Request on GitHub

Keeping Your Fork Synced

git fetch upstream
git switch main
git merge upstream/main
git push origin main

Git GUI Apps: You Don't Have to Type Everything

Knowing the commands makes you a stronger developer — but you don't have to use the terminal every day. There's a whole ecosystem of GUI (Graphical User Interface) apps that let you commit, branch, merge, and stash by clicking buttons, with a visual map of your repo history.

Here are the most popular ones:

App	Platform	Price	Best For
GitHub Desktop	Mac, Windows	Free	Beginners, GitHub users
GitLens (VS Code ext.)	All OS	Free / Paid	Devs living in VS Code/Cursor
GitKraken	Mac, Win, Linux	Free (limited) / Paid	Visual power users
Fork	Mac, Windows	Free trial / ~$50	Speed + power balance
Sourcetree	Mac, Windows	Free	Atlassian/Bitbucket users

GitHub Desktop is the simplest — made by GitHub, focused on the essentials. GitLens is a VS Code extension that adds inline blame, visual commit graphs, and stash management right inside your editor. GitKraken has a stunning commit graph and drag-and-drop merging. Fork hits a great balance of speed and power. Sourcetree (by Atlassian) is free and feature-rich, especially if you use Bitbucket.

Even if you use a GUI app daily, knowing the underlying commands helps you debug problems and work on servers where no GUI exists. Think of GUI apps as a productivity layer on top of your Git knowledge — not a replacement for it.

Summary

Concept	In Short
Repository	Warehouse for your project files + history
Commit	A saved snapshot with a message
Checkout	Visit past commits temporarily
Reset	Erase commit history (use carefully)
Revert	Safely undo a commit
Branch	Independent line of development
Stash	Temporarily save unfinished work
Merge	Combine branches
Pull Request	Formal request to review and merge code
Fork	Copy someone else's repo to your account
Clone	Copy a repo to your local machine

The more you use it, the more natural it feels. One commit at a time. 🚀

Originally published as a series (Git for Everyone) at: What Is Git, Repository, and Commit | Traveling Through Time — Checkout, Reset, and Revert
| Branches, Stash, and Git Workflow | Merge, Pull Requests, and Code Reviews | Fork, Clone, and Open Source Collaboration | Git GUI Apps — You Don't Have to Use the Terminal

Git & Kolaborasi: Panduan untuk Pemula (Lengkap dengan Analogi)

Sanudin — Mon, 08 Jun 2026 00:36:09 +0000

🌐 Baca artikel ini dalam Bahasa Inggris di sini.

📝 Catatan tentang artikel ini
Artikel ini dibuat berdasarkan catatan belajar pribadi saya tentang version control dan Git kolaborasi. 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.

Belajar Git itu tidak harus membingungkan. Di artikel ini, saya akan menjelaskan konsep-konsep penting dalam version control dan kolaborasi menggunakan bahasa yang sederhana — bahkan dengan analogi yang bisa dipahami anak kecil sekalipun.

Apa Itu Git?

Git adalah version control system — sistem yang merekam setiap perubahan yang kamu lakukan pada file-file proyekmu.

Bayangkan Git seperti fitur save point di video game. Setiap kali kamu menyimpan (commit), Git mengambil "foto" dari kondisi proyekmu saat itu. Kalau ada yang salah, kamu bisa kembali ke foto sebelumnya.

Repository: Gudang Proyekmu

Repository (atau "repo") adalah folder yang diawasi oleh Git. Ada dua jenisnya:

Local repository: ada di komputermu sendiri. Ruang kerja pribadimu.
Remote repository: ada di server (GitHub, GitLab, Bitbucket). Salinan "resmi" yang bisa diakses seluruh tim.

Keduanya terhubung lewat Remote URL, sehingga kamu bisa mengirim perubahan ke remote (push) atau mengambil perubahan terbaru dari sana (pull).

git init                            # Mulai memantau sebuah folder
git remote add origin <url>         # Hubungkan ke remote repo
git push origin main                # Kirim commit ke remote
git pull origin main                # Ambil update terbaru dari remote

Analogi: Local repo adalah buku sketsamu di rumah. Remote repo adalah papan pengumuman kelas — semua orang bisa melihat dan mengaksesnya.

Commit: Save Point Proyekmu

Commit adalah snapshot dari kondisi proyekmu pada satu titik waktu. Setiap commit berisi:

Pesan yang menjelaskan apa yang berubah
ID unik (hash)
Timestamp

git add .                           # Staging semua perubahan
git commit -m "Tambah layout halaman utama"  # Simpan snapshot
git log --oneline                   # Lihat riwayat commit

Tulis pesan commit yang jelas dan bermakna. Dirimu di masa depan — dan rekan timmu — akan berterima kasih.

Checkout, Reset, Revert: Mesin Waktu Git

Ketiga perintah ini berinteraksi dengan riwayat commit — tapi dengan cara yang sangat berbeda:

`git checkout` — Kunjungi Masa Lalu (Sementara)

Seperti mesin waktu dengan tiket visitor. Kamu bisa melihat kondisi kode di commit lama tanpa mengubah apapun secara permanen.

git checkout <commit-hash>          # Kunjungi commit lama
git checkout main                   # Kembali ke sekarang
git checkout -b branch-baru <hash>  # Buat branch baru dari commit lama

`git reset` — Hapus Riwayat

Kembali ke commit tertentu dan menghapus semua yang terjadi setelahnya. Gunakan dengan hati-hati — terutama jika sudah di-push ke remote.

git reset --soft HEAD~1             # Undo commit terakhir, perubahan tetap ada (staged)
git reset --hard HEAD~1             # Undo commit terakhir, perubahan ikut terhapus

`git revert` — Undo yang Aman

Membuat commit baru yang membalikkan efek dari commit sebelumnya. Riwayat tetap utuh — pilihan paling aman saat bekerja di repo bersama.

git revert <commit-hash>            # Undo sebuah commit dengan aman

Panduan praktis: Kalau sudah di-push, gunakan revert. Kalau belum, reset tidak masalah.

Branch: Jalur Paralel untuk Kode

Branch adalah jalur pengembangan yang terpisah. Kamu bisa membuat branch untuk mengerjakan fitur atau perbaikan bug tanpa menyentuh branch main yang stabil.

git switch -c feature/dark-mode     # Buat dan pindah ke branch baru
git switch main                     # Kembali ke main
git branch -d feature/dark-mode     # Hapus branch yang sudah di-merge
git push origin feature/dark-mode   # Push branch ke remote

Konvensi penamaan branch yang umum:

Tipe	Prefix	Contoh
Fitur baru	`feature/`	`feature/dark-mode`
Perbaikan bug	`fix/`	`fix/login-redirect`
Hotfix mendesak	`hotfix/`	`hotfix/payment-crash`

Analogi: Bayangkan sungai yang mengalir. Branch adalah anak sungai yang memisah diri untuk menjelajahi jalur lain — dan nantinya bergabung kembali ke sungai utama.

Stash: Tombol Pause untuk Pekerjaan yang Belum Selesai

Kamu sedang di tengah-tengah mengerjakan sebuah fitur. Kode masih berantakan, belum siap untuk di-commit. Tiba-tiba team lead bilang: "Bisa tolong perbaiki bug itu di branch main sekarang?"

Kamu tidak bisa switch branch dengan perubahan yang belum di-commit. Tapi kamu juga belum siap commit. Jawabannya: simpan dulu dengan stash.

Analogi: Kamu sedang menggambar tapi meja harus dipakai untuk hal lain. Kamu dengan rapi menyimpan gambar dan pensil ke dalam laci. Nanti kamu buka lacinya dan lanjut persis dari titik yang sama.

git stash                           # Simpan pekerjaan sementara
git switch fix/some-bug             # Bebas pindah branch
# ... perbaiki bug, commit, balik lagi ...
git switch feature/dark-mode
git stash pop                       # Kembalikan pekerjaanmu

Menambahkan label membuat stash lebih mudah dikelola:

git stash push -m "WIP: palet dark mode"     # Stash dengan nama
git stash list                               # Lihat semua stash
git stash pop                                # Kembalikan stash terbaru
git stash apply stash@{1}                    # Kembalikan stash tertentu (tetap di list)
git stash drop stash@{1}                     # Hapus stash tertentu
git stash -u                                 # Sertakan file baru yang belum di-track

Merge & Pull Request: Menyatukan Pekerjaan

Saat fiturmu selesai, kamu merge branch-mu kembali ke main.

git switch main
git merge feature/dark-mode

Di GitHub/GitLab, proses ini biasanya dilakukan lewat Pull Request (PR):

Push branch-mu dan buka PR
Rekan tim me-review kode dan meninggalkan komentar
Setelah disetujui, kode di-merge

Tiga Opsi Merge

Metode	Yang Terjadi
Merge commit	Semua commit dipertahankan + merge commit ditambahkan
Squash and merge	Semua commit digabung jadi satu
Rebase and merge	Commit diputar ulang di atas main, tanpa merge commit

Menangani Conflict

Ketika dua branch mengedit baris yang sama, Git tidak bisa merge otomatis. Kamu akan melihat:

<<<<<<< HEAD
const msg = "Halo!";
=======
const msg = "Hai semuanya!";
>>>>>>> feature/dark-mode

Selesaikan secara manual, lalu:

git add <file>
git commit

Code Review: Pintu Gerbang Kualitas

Sebelum PR di-merge, seseorang akan me-review kodenya. Reviewer yang baik memeriksa:

Apakah logikanya benar?
Apakah kode mudah dibaca dan penamaannya jelas?
Apakah ada test yang cukup?
Apakah kode lebih kompleks dari yang seharusnya?
Apakah sesuai dengan style guideline tim?

Code review bukan sekadar mencari kesalahan — ini juga cara pengetahuan menyebar di seluruh tim. Jangan lupa juga memberikan pujian ketika kode sudah ditulis dengan baik.

Fork & Clone: Berkontribusi Tanpa Akses

Forking menyalin repo orang lain ke akun GitHub-mu. Cloning menyalin repo ke komputer lokalmu.

Alur kontribusi open source yang umum:

# 1. Fork di GitHub (klik tombol Fork)

# 2. Clone fork-mu
git clone https://github.com/username-kamu/nama-proyek.git

# 3. Tambahkan repo asli sebagai upstream
git remote add upstream https://github.com/pemilik-asli/nama-proyek.git

# 4. Buat branch, buat perubahan, push
git switch -c fix/typo-readme
git add . && git commit -m "Perbaiki typo di README"
git push origin fix/typo-readme

# 5. Buka Pull Request di GitHub

Sinkronisasi Fork-mu

git fetch upstream
git switch main
git merge upstream/main
git push origin main

Perbedaan Fork vs Clone: Fork menyalin ke akun GitHub-mu (remote). Clone menyalin ke komputermu (lokal). Keduanya tidak mempengaruhi repo asli.

Tips untuk Mulai Berkontribusi

Kalau kamu baru ingin terjun ke open source:

Mulai dari yang kecil — perbaiki typo di dokumentasi, tambahkan komentar, perbaiki README. Jangan langsung menyerang bug paling kompleks.
Pelajari ekosistem proyek — baca README.md, CONTRIBUTING.md, dan riwayat commit untuk memahami konvensi yang digunakan.
Ikuti konvensi yang ada — cara menulis commit, penamaan branch, format PR description.

Aplikasi Git GUI: Tidak Harus Selalu Pakai Terminal

Mengetahui perintahnya membuatmu jadi developer yang lebih kuat — tapi kamu tidak harus mengetik di terminal setiap hari. Ada banyak aplikasi GUI (Graphical User Interface) yang memungkinkan kamu commit, branch, merge, dan stash hanya dengan klik, plus visualisasi riwayat repo yang mudah dipahami.

Berikut yang paling populer:

Aplikasi	Platform	Harga	Cocok Untuk
GitHub Desktop	Mac, Windows	Gratis	Pemula, pengguna GitHub
GitLens (ext. VS Code)	Semua OS	Gratis / Berbayar	Developer yang sehari-hari di VS Code/Cursor
GitKraken	Mac, Win, Linux	Gratis (terbatas) / Berbayar	Power user visual
Fork	Mac, Windows	Gratis trial / ~$50	Keseimbangan kecepatan & fitur
Sourcetree	Mac, Windows	Gratis	Pengguna Atlassian/Bitbucket

GitHub Desktop adalah yang paling sederhana — dibuat oleh GitHub, fokus pada hal-hal esensial. GitLens adalah ekstensi VS Code yang menambahkan inline blame, visual commit graph, dan manajemen stash langsung di dalam editor-mu. GitKraken punya tampilan commit graph yang keren dan fitur drag-and-drop untuk merge. Fork menawarkan keseimbangan yang baik antara kecepatan dan fitur. Sourcetree (buatan Atlassian) gratis dan kaya fitur, terutama kalau kamu pakai Bitbucket.

Meskipun pakai aplikasi GUI sehari-hari, memahami perintah dasarnya tetap penting — untuk debugging dan bekerja di server yang tidak punya GUI. Anggap aplikasi GUI sebagai lapisan produktivitas di atas pengetahuan Git-mu, bukan penggantinya.

Ringkasan

Konsep	Singkatnya
Repository	Gudang untuk file dan riwayat proyekmu
Commit	Snapshot tersimpan dengan pesan
Checkout	Kunjungi commit lama sementara
Reset	Hapus riwayat commit (hati-hati)
Revert	Undo commit dengan aman
Branch	Jalur pengembangan terpisah
Stash	Simpan sementara pekerjaan yang belum selesai
Merge	Gabungkan dua branch
Pull Request	Permintaan formal untuk review dan merge
Fork	Salin repo orang lain ke akunmu
Clone	Salin repo ke komputer lokalmu

Mulai dari yang kecil, commit sesering mungkin, dan jangan takut membuat branch baru. Satu commit pada satu waktu. 🚀

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

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

🌐 Read this post in Bahasa Indonesia here.

📝 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 as a series at: Part 1: What is OOP? | Part 2: When Objects Meet | Part 3: Why Bad Design Hurts | Part 4: SOLID

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

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

🌐 Baca artikel ini dalam Bahasa Inggris di sini.

📝 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 as a series at: Part 1: What is OOP? | Part 2: When Objects Meet | Part 3: Why Bad Design Hurts | Part 4: SOLID

DEV Community: Sanudin

Git & Collaboration: A Beginner's Guide (With Real Analogies)

What Is Git?

Repository: Your Project's Warehouse

Commit: Your Project's Save Point

Checkout, Reset, Revert: Traveling Through Time

git checkout — Visit the Past (Temporarily)

git reset — Erase History

git revert — The Safe Undo

Branches: Parallel Universes for Your Code

Stash: The Pause Button for Unfinished Work

Merge & Pull Requests: Bringing It All Together

Merge Options

Handling Conflicts

Code Reviews: The Quality Gate

Fork & Clone: Contributing Without Access

Keeping Your Fork Synced

Git GUI Apps: You Don't Have to Type Everything

Summary

Git & Kolaborasi: Panduan untuk Pemula (Lengkap dengan Analogi)

Apa Itu Git?

Repository: Gudang Proyekmu

Commit: Save Point Proyekmu

Checkout, Reset, Revert: Mesin Waktu Git

git checkout — Kunjungi Masa Lalu (Sementara)

git reset — Hapus Riwayat

git revert — Undo yang Aman

Branch: Jalur Paralel untuk Kode

Stash: Tombol Pause untuk Pekerjaan yang Belum Selesai

Merge & Pull Request: Menyatukan Pekerjaan

Tiga Opsi Merge

Menangani Conflict

Code Review: Pintu Gerbang Kualitas

Fork & Clone: Berkontribusi Tanpa Akses

Sinkronisasi Fork-mu

Tips untuk Mulai Berkontribusi

Aplikasi Git GUI: Tidak Harus Selalu Pakai Terminal

Ringkasan

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

Part 1: What Is OOP?

The Four Pillars

Part 2: How Objects Relate

Association

Dependency

Generalization & Realization

Part 3: What Bad Design Looks Like

Part 4: SOLID

S — Single Responsibility Principle

O — Open/Closed Principle

L — Liskov Substitution Principle

I — Interface Segregation Principle

D — Dependency Inversion Principle

Quick Reference: SOLID at a Glance

Where to Start

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

Bagian 1: Apa Itu OOP?

Empat Pilar OOP

Bagian 2: Bagaimana Objek Saling Berhubungan

Asosiasi

Dependency

Generalization & Realization

Bagian 3: Seperti Apa Desain yang Buruk?

Bagian 4: SOLID

S — Single Responsibility Principle

O — Open/Closed Principle

L — Liskov Substitution Principle

I — Interface Segregation Principle

D — Dependency Inversion Principle

Ringkasan Cepat: SOLID Sekilas

Mulai dari Mana?

`git checkout` — Visit the Past (Temporarily)

`git reset` — Erase History

`git revert` — The Safe Undo

`git checkout` — Kunjungi Masa Lalu (Sementara)

`git reset` — Hapus Riwayat

`git revert` — Undo yang Aman