Interface Segregation Principle (ISP) - TypeScript & React

Ringkasan: Kuasai Interface Segregation Principle (ISP). Pelajari konsep SOLID dengan contoh praktis TypeScript dan React untuk menulis kode yang lebih bersih dan lebih mudah dipelihara.

Pendahuluan

Interface Segregation Principle (ISP) menyatakan bahwa tidak boleh ada klien yang dipaksa bergantung pada metode yang tidak digunakannya. Jika diterapkan dengan baik, ISP mengurangi keterkaitan, menyederhanakan pengujian, dan membuat kode lebih mudah diubah dan dipahami. Panduan ini menunjukkan contoh praktis TypeScript dan React yang dapat Anda gunakan hari ini untuk membuat basis kode Anda lebih modular dan mudah dipelihara.

Apa itu Interface Segregation Principle?

Bayangkan remote TV dengan 90 tombol padahal Anda hanya butuh tombol “Play.” Frustrasi itu mencerminkan perangkat lunak di mana sebuah kelas harus mengimplementasikan antarmuka besar dan tidak fokus. ISP, huruf “I” dalam SOLID, mendorong perancangan antarmuka kecil dan spesifik-klien daripada satu kontrak yang melakukan segalanya. Ini menghindari antipola “antarmuka gemuk” atau “God interface” dan menghasilkan sistem yang lebih jelas dan fleksibel.¹

Mengapa antarmuka gemuk berbahaya

• Ketergantungan yang tidak perlu: Kelas menjadi terikat pada metode yang tak pernah mereka panggil, membuat perubahan tak terkait menjadi berisiko.
• Beban kognitif: Pengembang harus menelusuri metode yang tidak relevan untuk menemukan yang mereka butuhkan.
• Implementasi kosong: Kelas dipaksa untuk membuat stub metode yang tidak digunakan, menambah boilerplate.

Gagasan inti sederhana: berikan setiap klien persis apa yang dibutuhkannya, dan tidak lebih. Ini membuat komponen lebih mudah dipahami, diuji, dan dikembangkan.

Antarmuka Monolitik vs. Terpisah

Perbandingan berdampingan membuat trade-off menjadi jelas.

Memilih ISP membantu basis kode Anda tetap adaptif saat fitur ditambahkan atau direfaktor.

ISP dalam Praktek: Pelanggaran Umum

Pelanggaran tidak memecah aplikasi tetapi membuat pemeliharaan menyakitkan. Carilah kelas yang penuh metode kosong atau komponen dengan banyak props opsional.

A classic “God Interface” in TypeScript

// ANTI-PATTERN: A "fat interface" that violates ISP interface IUserActions { createUser(data: UserData): void; editUser(id: string, data: UserData): void; deleteUser(id: string): void; viewUserProfile(id: string): UserProfile; changeUserRole(id: string, newRole: Role): void; publishArticle(article: Article): void; approveComment(commentId: string): void; }

Sebuah kelas Viewer yang dipaksa mengimplementasikan ini akan menyertakan metode yang tidak bermakna atau melempar kesalahan. Ini meningkatkan biaya pemeliharaan dan risiko.

Props komponen yang membengkak di React

Gejala frontend yang umum adalah Card generik dengan banyak props opsional. Itu menciptakan ambiguitas mengenai kombinasi props yang valid dan memaksa rendering kondisional yang kompleks.

// ANTI-PATTERN: A bloated props interface interface CardProps { title: string; description?: string; imageUrl?: string; imageAltText?: string; videoUrl?: string; authorName?: string; authorAvatarUrl?: string; publicationDate?: string; articleLink?: string; onClick?: () => void; // ... and many more optional props }

Antipola ini menyiapkan kita untuk langkah refaktorisasi di bawah.

Cara merombak: Dari Antarmuka Monolitik ke Terpisah

Refaktorisasi ke ISP tidak membutuhkan penulisan ulang besar-besaran. Gunakan perubahan kecil dan terfokus untuk membagi tanggung jawab dan memperjelas kontrak.

1) Memperbaiki "God Interface" di TypeScript

Langkah A: Identifikasi peran klien. Misalnya: Admin, Editor, Viewer.

Langkah B: Buat antarmuka spesifik-peran.

// GOOD: Focused interfaces interface IViewerActions { viewUserProfile(id: string): UserProfile; }

interface IEditorActions { publishArticle(article: Article): void; approveComment(commentId: string): void; }

interface IAdminActions { createUser(data: UserData): void; editUser(id: string, data: UserData): void; deleteUser(id: string): void; changeUserRole(id: string, newRole: Role): void; }

Langkah C: Implementasikan hanya yang dibutuhkan.

class Viewer implements IViewerActions { viewUserProfile(id: string): UserProfile { console.log(Fetching profile for user ${id}...); // ... fetch and return profile } }

Seorang Administrator dapat mengimplementasikan beberapa antarmuka sesuai kebutuhan. Pemisahan ini mengurangi recompiles yang tidak perlu dan memperjelas siapa yang memiliki masing-masing kapabilitas.

2) Refaktorisasi props React yang membengkak dengan discriminated unions

Gunakan discriminated unions sehingga setiap varian komponen memiliki kontrak yang jelas. Tipe union dan discriminator TypeScript sangat ideal untuk ini.²

// GOOD: Base props type BaseCardProps = { title: string; onClick?: () => void; };

// GOOD: Specific variants type ImageCardProps = BaseCardProps & { cardType: 'image'; imageUrl: string; imageAltText: string; };

type ArticleCardProps = BaseCardProps & { cardType: 'article'; description: string; authorName: string; articleLink: string; };

type CardProps = ImageCardProps | ArticleCardProps;

Dengan pola ini, editor segera menegakkan kombinasi props yang valid dan mencegah permutasi yang tidak valid.

Mengaudit dan menegakkan ISP di seluruh tim Anda

Melakukan perbaikan sekali saja berguna, tetapi membenamkan ISP ke dalam praktik tim memberikan nilai jangka panjang. Gabungkan kriterium audit yang jelas dengan pemeriksaan otomatis untuk menjaga kesehatan antarmuka.

Kriteria audit yang jelas

Buat daftar periksa bersama untuk mendeteksi pelanggaran ISP saat review. Contoh tanda bahaya:

• Antarmuka dengan banyak metode (layak diperiksa jika di atas lima sampai tujuh metode).
• Metode kosong atau stub pada implementasi.
• Nama antarmuka yang samar menggunakan kata-kata seperti “Manager” atau “Handler.”
• Props komponen dengan banyak field opsional.

Pendekatan umum adalah memadukan review manual dengan alat otomatis untuk memperbesar penegakan.

Mengotomatisasi penegakan

ESLint dan aturan kustom kuat untuk menangkap pola sederhana, seperti props yang terlalu besar atau kelas yang mengimplementasikan antarmuka tetapi meninggalkan metode yang tidak diimplementasikan.³ Asisten pengkodean berbasis AI juga dapat membantu menandai "design smells" ketika disuruh meninjau antarmuka dan implementasi.⁴

Baik pemeriksaan otomatis maupun review manusia bernilai: alat memberikan konsistensi dan kecepatan, sedangkan manusia menangkap konteks dan maksud bisnis.

Gunakan keduanya: biarkan otomasi menangani pemeriksaan rutin dan reviewer fokus pada keputusan desain bernuansa. Perpaduan ini meningkatkan workflow TDD karena antarmuka yang lebih kecil lebih mudah dimock dan diuji—mendukung siklus Red-Green-Refactor yang lebih cepat dan unit test yang lebih jelas.⁵

ISP dan Pengembangan Berbasis AI

Seiring AI semakin tertanam dalam alur kerja pengembangan, antarmuka yang jelas membantu alat seperti model bergaya GPT memahami kode. Antarmuka kecil dan terfokus mengurangi ambiguitas dan meningkatkan kualitas kode yang dihasilkan, saran refaktor otomatis, dan dokumentasi.⁴

Antarmuka yang bersih bertindak seperti brief yang presisi bagi manusia maupun mesin. Kejelasan itu mengurangi tebak-tebakan dan menghasilkan perubahan berbantuan AI yang lebih akurat dan andal.

Pertanyaan Umum tentang ISP

Apakah ISP berarti setiap metode perlu antarmuka sendiri?

Tidak. Tujuannya bukan membuat antarmuka satu-metode di mana-mana. Kelompokkan metode yang selalu digunakan bersama oleh klien yang sama. Sasarannya adalah antarmuka yang fokus dan kohesif, bukan fragmentasi.

Apa perbedaan ISP dengan Single Responsibility Principle?

SRP berlaku untuk kelas dan menyatakan bahwa sebuah kelas harus punya satu alasan untuk berubah. ISP berlaku untuk antarmuka dan menyatakan bahwa klien tidak boleh bergantung pada metode yang tidak mereka gunakan. Anda bisa mengikuti SRP namun tetap melanggar ISP jika sebuah kelas mengimplementasikan antarmuka yang membengkak.

Kapan boleh mengabaikan ISP?

Kebanyakan ketika Anda tidak bisa mengubah antarmuka—misalnya library pihak ketiga atau API legacy yang bukan milik Anda. Juga, jika setiap klien memang membutuhkan semua metode, antarmuka yang lebih besar masih bisa kohesif dan dapat diterima.

Daftar periksa refaktor cepat

• Identifikasi peran dan klien untuk setiap antarmuka.
• Pisahkan antarmuka besar menjadi kontrak spesifik-peran.
• Gunakan discriminated unions TypeScript untuk props komponen varian.²
• Tambahkan aturan lint untuk menandai antarmuka atau props yang terlalu besar.³
• Gabungkan pemeriksaan otomatis dengan code review untuk keputusan bernuansa.

Tiga Q&A ringkas (Pertanyaan umum pengembang)

Q: Bagaimana cara cepat mendeteksi pelanggaran ISP?

A: Carilah antarmuka dengan banyak metode yang tidak saling terkait, kelas dengan implementasi kosong atau yang melempar error, atau komponen dengan puluhan props opsional. Ini tanda kuat bahwa sebuah kontrak perlu dipisah.

Q: Apa cara tercepat memperbaiki "fat interface"?

A: Identifikasi peran klien yang berbeda, buat antarmuka spesifik-peran yang fokus, dan perbarui implementasi untuk hanya mengimplementasikan apa yang diperlukan. Lakukan perubahan secara bertahap untuk mengurangi risiko.

Q: Bagaimana mencegah regresi ISP di basis kode yang berkembang?

A: Tambahkan aturan lint dan pemeriksaan CI untuk mendeteksi antarmuka yang terlalu besar dan buat daftar periksa review untuk desain antarmuka. Gabungkan otomasi dengan audit manual berkala.

Di Clean Code Guy, kami membantu tim menerapkan prinsip seperti ISP untuk membangun basis kode yang mudah dipelihara dan siap AI. Dapatkan audit basis kode gratis untuk menemukan masalah tersembunyi dan meningkatkan pemeliharaan jangka panjang.

Maintain all markdown formatting, links, and code blocks exactly as they are.