Anda tidak harus benar-benar mematuhi prinsip-prinsip ini, dan tidak ada hukuman agama jika melanggarnya. Namun Anda harus menganggap prinsip-prinsip ini sebagai bel peringatan. Jika salah satu dari prinsip-prinsip ini dilanggar, bel peringatan akan berbunyi. ----- Arthur J.Riel
(1) Semua data harus disembunyikan di dalam kelas tempatnya berada.
(2) Pengguna suatu kelas harus bergantung pada antarmuka bersama kelas tersebut, tetapi suatu kelas tidak dapat bergantung pada penggunanya.
(3) Minimalkan pesan dalam protokol kelas.
(4) Menerapkan antarmuka publik paling dasar yang dipahami semua kelas [misalnya, operasi penyalinan (salinan dalam dan penyalinan dangkal), penilaian kesetaraan, konten keluaran yang benar, penguraian dari deskripsi ASCII, dll.].
(5) Jangan memasukkan detail implementasi (seperti fungsi pribadi yang menempatkan kode bersama) ke dalam antarmuka publik kelas.
Jika dua metode suatu kelas memiliki bagian kode yang sama, Anda dapat membuat fungsi pribadi yang mencegah kode umum tersebut.
(6) Jangan ganggu antarmuka publik kelas dengan hal-hal yang tidak dapat digunakan atau tidak diminati pengguna.
(7) Seharusnya tidak ada hubungan penggandengan antar kelas, atau hanya hubungan penggandengan turunan. Artinya, satu kelas tidak ada hubungannya dengan kelas lain, atau hanya menggunakan operasi di antarmuka publik kelas lain.
(8) Sebuah kelas harus mewakili hanya satu abstraksi kunci.
Semua kelas dalam paket harus ditutup bersama untuk perubahan pada tipe properti yang sama. Jika perubahan mempengaruhi suatu paket, maka akan mempengaruhi semua kelas dalam paket tersebut, namun tidak akan berdampak pada paket lain.
(9) Sentralisasikan data dan perilaku terkait.
Desainer harus menyadari objek yang memperoleh data dari objek lain melalui operasi seperti get. Perilaku seperti ini menyiratkan bahwa prinsip empiris ini dilanggar.
(10) Masukkan informasi yang tidak relevan ke dalam kategori lain (yaitu perilaku tidak berkomunikasi satu sama lain).
Buat ketergantungan terhadap stabilitas.
(11) Pastikan bahwa konsep abstrak yang Anda modelkan adalah kelas, bukan hanya peran yang dimainkan oleh objek.
(12) Fungsi sistem distribusi seragam dalam arah horizontal, yaitu: menurut rancangan, kelas-kelas teratas harus membagi pekerjaan secara seragam.
(13) Jangan membuat kelas/objek mahakuasa di sistem Anda. Berhati-hatilah dengan kelas yang namanya meliputi Driver, Manager, System, dan Susystem.
Rencanakan antarmuka daripada mengimplementasikan antarmuka.
(14) Hati-hati dengan kelas yang mendefinisikan sejumlah besar metode akses di antarmuka publik. Banyaknya metode akses berarti data dan perilaku yang relevan tidak disimpan secara terpusat.
(15) Hati-hati dengan kelas yang terlalu banyak memuat perilaku yang tidak berkomunikasi satu sama lain.
Manifestasi lain dari masalah ini adalah menciptakan banyak fungsi get dan set di antarmuka publik kelas-kelas dalam aplikasi Anda.
(16) Dalam aplikasi yang terdiri dari model berorientasi objek yang berinteraksi dengan antarmuka pengguna, model tersebut tidak boleh bergantung pada antarmuka, tetapi antarmuka harus bergantung pada model.
(17) Sebisa mungkin buat model sesuai dengan dunia nyata (kita sering melanggar prinsip ini untuk mematuhi prinsip distribusi fungsi sistem, menghindari prinsip kelas serba guna, dan menempatkan data dan perilaku yang relevan secara terpusat).
(18) Hapus kelas yang tidak perlu dari desain Anda.
Umumnya, kami akan menurunkan kelas ini menjadi properti.
(19) Hapus kelas di luar sistem.
Ciri-ciri kelas di luar sistem adalah secara abstrak hanya mengirimkan pesan ke domain sistem tetapi tidak menerima pesan dari kelas lain di domain sistem.
(20) Jangan mengubah operasi menjadi kelas. Mempertanyakan kelas mana pun yang namanya merupakan kata kerja atau berasal dari kata kerja, terutama kelas yang hanya memiliki satu tindakan yang bermakna. Pertimbangkan apakah perilaku yang bermakna tersebut harus dipindahkan ke kelas yang sudah ada atau belum ditemukan.
(21) Kami sering memperkenalkan kelas proxy saat membuat model analisis aplikasi. Selama tahap desain, kita sering menemukan banyak agen yang tidak berguna dan harus dihilangkan.
(22) Minimalkan jumlah kolaborator suatu kelas.
Jumlah kelas lain yang digunakan oleh suatu kelas harus dijaga seminimal mungkin.
(23) Meminimalkan jumlah pesan yang disampaikan antara kelas dan kolaborator.
(24) Meminimalkan jumlah kolaborasi antar kelas dan kolaborator, yaitu: mengurangi jumlah pesan berbeda yang disampaikan antara kelas dan kolaborator.
(25) Meminimalkan penyebaran kelas, yaitu mengurangi produk dari jumlah pesan yang ditentukan oleh kelas dan jumlah pesan yang dikirim.
(26) Jika suatu kelas berisi objek dari kelas lain, kelas yang memuatnya harus mengirimkan pesan ke objek yang ditampungnya. Yaitu: relasi inklusi selalu menyiratkan relasi penggunaan.
(27) Sebagian besar metode yang didefinisikan dalam suatu kelas harus menggunakan sebagian besar anggota data sepanjang waktu.
(28) Jumlah objek yang terdapat dalam suatu kelas tidak boleh melebihi kapasitas memori jangka pendek pengembang. Angka ini seringkali 6.
Ketika sebuah kelas berisi lebih dari 6 anggota data, Anda dapat membagi anggota data yang terkait secara logis ke dalam sebuah grup, dan kemudian menggunakan kelas baru yang memuatnya untuk memuat grup anggota ini.
(29) Biarkan fungsi sistem didistribusikan secara vertikal dalam sistem pewarisan yang sempit dan dalam.
(30) Saat menerapkan batasan semantik, yang terbaik adalah menerapkannya sesuai dengan definisi kelas. Hal ini sering kali menyebabkan kelas meluap, dalam hal ini batasan harus diterapkan pada perilaku kelas, biasanya namun tidak harus pada konstruktor.
(31) Saat menerapkan batasan semantik pada konstruktor suatu kelas, tempatkan uji batasan pada tingkat inklusi terdalam yang diizinkan oleh domain konstruktor.
(32) Jika informasi semantik yang dibatasi bergantung pada sering berubah, yang terbaik adalah meletakkannya di objek pihak ketiga yang terpusat.
(33) Jika informasi semantik yang diandalkan oleh batasan jarang berubah, informasi tersebut paling baik didistribusikan di antara kelas-kelas yang terlibat dalam batasan tersebut.
(34) Suatu kelas harus mengetahui isinya, tetapi tidak dapat mengetahui siapa yang memuatnya.
(35) Objek yang berbagi cakupan literal (yaitu, terkandung dalam kelas yang sama) tidak boleh memiliki hubungan penggunaan satu sama lain.
(36) Warisan hanya boleh digunakan untuk memodelkan hierarki spesialisasi.
(37) Kelas turunan harus mengetahui tentang kelas dasar, dan kelas dasar tidak boleh mengetahui informasi apa pun tentang kelas turunannya.
(38) Semua data di kelas dasar harus bersifat pribadi, jangan gunakan data yang dilindungi.
Perancang kelas tidak boleh meletakkan sesuatu di antarmuka publik yang tidak dibutuhkan oleh pengguna kelas.
(39) Secara teori, hierarki pewarisan harus semakin dalam, semakin dalam semakin baik.
(40) Dalam praktiknya, kedalaman hierarki warisan tidak boleh melebihi kapasitas memori jangka pendek rata-rata orang. Nilai kedalaman yang diterima secara luas adalah 6.
(41) Semua kelas abstrak harus menjadi kelas dasar.
(42) Semua kelas dasar harus berupa kelas abstrak.
(43) Tempatkan kesamaan data, perilaku dan/atau antarmuka setinggi mungkin dalam hierarki warisan.
(44) Jika dua atau lebih kelas berbagi data yang sama (tetapi tidak ada perilaku yang sama), maka data umum tersebut harus ditempatkan di kelas yang termasuk dalam setiap kelas yang berbagi data tersebut.
(45) Jika dua atau lebih kelas memiliki data dan perilaku (yaitu metode) yang sama, maka masing-masing kelas ini harus mewarisi dari kelas dasar umum yang mewakili data dan metode tersebut.
(46) Jika dua atau lebih kelas berbagi antarmuka yang sama (mengacu pada pesan, bukan metode), maka kelas tersebut harus mewarisi dari kelas dasar yang sama hanya jika kelas tersebut perlu digunakan secara polimorfik.
(47) Analisis kasus per kasus terhadap tampilan tipe objek umumnya salah. Dalam sebagian besar kasus seperti itu, desainer harus menggunakan polimorfisme.
(48) Analisis kasus per kasus terhadap tampilan nilai atribut seringkali salah. Kelas harus dipisahkan menjadi hierarki warisan, dengan setiap nilai atribut diubah menjadi kelas turunan.
(49) Jangan memodelkan semantik dinamis suatu kelas melalui hubungan pewarisan. Mencoba memodelkan semantik dinamis dengan hubungan semantik statis menghasilkan peralihan tipe saat runtime.
(50) Jangan mengubah objek kelas menjadi kelas turunan. Hati-hati dengan kelas turunan mana pun yang hanya memiliki satu instance.
(51) Jika Anda merasa perlu membuat kelas baru saat runtime, mundur selangkah dan sadari bahwa Anda sedang membuat objek. Sekarang, generalisasikan objek-objek ini ke dalam sebuah kelas.
(52) Penggunaan metode kosong (yaitu metode yang tidak melakukan apa pun) di kelas turunan untuk menggantikan metode di kelas dasar adalah tindakan ilegal.
(53) Jangan bingung antara penyertaan opsional dengan kebutuhan akan warisan. Memodelkan inklusi opsional sebagai warisan mengarah pada proliferasi kelas.
(54) Saat membuat hierarki warisan, cobalah membuat kerangka kerja yang dapat digunakan kembali daripada komponen yang dapat digunakan kembali.
(55) Jika Anda menggunakan pewarisan berganda dalam desain Anda, asumsikan Anda telah melakukan kesalahan. Jika Anda tidak melakukan kesalahan, Anda perlu mencoba membuktikannya.
(56) Setiap kali pewarisan digunakan dalam desain berorientasi objek, tanyakan pada diri Anda dua pertanyaan: (1) Apakah kelas turunan merupakan tipe khusus dari hal yang diwarisinya? (2) Apakah kelas dasar merupakan bagian dari kelas turunan?
(57) Jika Anda menemukan pewarisan berganda dalam desain berorientasi objek, pastikan tidak ada kelas dasar yang sebenarnya merupakan kelas turunan dari kelas dasar lain.
(58) Dalam desain berorientasi objek, jika Anda perlu memilih antara inklusi dan asosiasi, silakan pilih inklusi.
(59) Jangan menggunakan data global atau fungsi global untuk pembukuan objek suatu kelas. Variabel kelas atau metode kelas harus digunakan.
(60) Desainer berorientasi objek tidak boleh membiarkan prinsip-prinsip desain fisik melemahkan desain logis mereka. Namun, kita sering menggunakan kriteria desain fisik dalam mengambil keputusan tentang desain logis.
(61) Jangan melewati antarmuka publik untuk mengubah keadaan objek.