Dalam pemrograman basis data ada teknik yang disebut "normalisasi" yang Anda lakukan untuk data yang ingin Anda simpan.

Adakah yang mencoba menerapkan konsep ini pada desain objek? Bagaimana kau? Bagaimana itu bekerja?

Sunting: Untuk memperluas / memperjelas, normalisasi database lebih dari seperangkat prinsip untuk mengurangi redundansi. Sebenarnya ada langkah-langkah dan tahapan yang Anda lalui dan setidaknya langkah-langkah yang cukup objektif yang memberi tahu Anda tahap mana Anda berada. Desain objek memiliki prinsip-prinsipnya sendiri, dan ada konsep penciuman, tetapi adakah cara untuk melakukan hal serupa yang akan memberi tahu Anda bahwa Anda berada di XX-form0, 1,2 ... dll ... dan metode untuk pindah ke level paling "normal" berikutnya?

Sementara beberapa dari ketegangan yang mendasari yang mendorong normalisasi basis data tidak ada dalam sistem OO, beberapa di antaranya. Ini telah memunculkan pola dan prinsip desain OO yang dalam beberapa hal analog dengan normalisasi, setidaknya karena sistem OO analog dengan database relasional. Sebagai contoh:

• Prinsip Tanggung Jawab Tunggal
• Pemisahan Kekhawatiran
• Once and Only Once , alias KERING

Dengan kata lain, adakah yang mencoba menerapkan teknik normalisasi basis data ke OOP? Tidak, karena OOP sudah memiliki solusi untuk masalah bersama yang dipecahkan normalisasi untuk database relasional.

Ya, Ya, Saya Memiliki

Saya sudah lama diam tentang topik ini; saatnya berbicara.

• Adakah yang mencoba menerapkan konsep ini pada desain objek?

Iya nih. Saya telah bekerja untuk memformalkan normalisasi objek (dan karenanya teori yang berorientasi objek) selama lebih dari 20 tahun.

• Bagaimana kau?

Dengan menyadari bahwa data dan kode dapat dipertukarkan, setidaknya secara teori. Ini berarti bahwa prinsip-prinsip normalisasi dan operasi relasional dapat berlaku untuk kode serta data.

• Bagaimana itu bekerja?

Sejauh ini berhasil dengan baik - saya percaya wawasan yang diperoleh adalah "senjata rahasia" dari desain, analisis, dan kemampuan refactoring saya.

Saya belum mengatakan apa-apa tentang hal ini kepada publik sebelum ini karena saya pikir pada akhirnya saya akan memiliki waktu untuk menyelesaikan penelitian - dan menghasilkan alat yang tersirat - sendiri.

Tetapi saya sampai pada kesimpulan bahwa dengan segala sesuatu yang terjadi dalam hidup saya yang lebih penting, lebih menyenangkan, dan / atau lebih menguntungkan, saya tidak akan punya waktu untuk menyelesaikan penelitian sendiri. Pernah. Ada juga kemungkinan signifikan bahwa saya sama sekali tidak memiliki landasan teori CS yang diperlukan untuk menyelesaikan pekerjaan sendirian.

Saya telah bertanya di universitas setempat tentang mensponsori satu atau dua kandidat PhD jika mereka ingin mengambil penyebabnya, tetapi sayangnya universitas lokal kami tidak mengajarkan dasar yang memadai dalam pemrograman bahasa semantik.

Ada beberapa penelitian yang menarik di bidang ini, tetapi semua itu - yang saya sadari - tidak tepat sasaran. Entah itu salah mengasumsikan bahwa karena normalisasi berasal dari latar belakang relasional itu tidak berlaku untuk model berorientasi objek, atau mengasumsikan bahwa normalisasi hanya berlaku untuk data yang ditentukan oleh objek. Namun ada beberapa proyek nyaris gagal ...

Hal-hal yang sangat menarik terjadi ketika Anda menerapkan normalisasi pada kode - yang menurut saya merupakan dasar dari semua refactoring .

Jadi sekarang saya berpikir bahwa hal terbaik untuk dilakukan adalah mengeluarkan berita, mungkin dengan meminta untuk berbicara di DevDays 2011 di DC, dan mencari tahu apakah ada komunitas yang begitu bersemangat dengan hal ini seperti saya.

Inilah intinya: Normalisasi adalah proses membuat sesuatu yang minimal dan tidak berlebihan. Karena itu prinsip Don't Repeat Yourself (DRY) pemrograman berorientasi objek adalah manifestasi yang jelas dari tujuan normalisasi. Saya percaya saya dapat menunjukkan bahwa semua prinsip desain / pemrograman / refactoring berorientasi objek yang terkenal adalah konsekuensi logis dari normalisasi objek. Saya pikir saya juga dapat menunjukkan bahwa ada lebih banyak hal menarik yang dapat dilakukan dengan sistem dalam Object Normal Form (ONF) daripada hanya refactoring.

Ini dimulai sebagai komentar pada Rein Henrichs jawaban yang sangat baik , tetapi terlalu lama ...

Normalisasi berlaku untuk data relasional. Ini digunakan untuk menghindari duplikasi, yang membuatnya lebih mudah untuk memastikan integritas data karena setiap datum disimpan hanya di satu tempat. Anda menormalkan basis data dengan menemukan pelanggaran formulir yang dinormalisasi dan memperbaikinya.

Pemrograman Berorientasi Objek berlaku untuk operasi pada data. Ini dimaksudkan untuk mengelompokkan cara-cara memanipulasi data bersama. Anda bisa menerapkan teknik serupa ke kelas untuk menghilangkan metode duplikat, mungkin dengan melihat data apa yang dimanipulasi atau tergantung pada operasi. Misalnya, 1NF dalam perspektif OO tidak akan memiliki operasi duplikat dalam kelas. 3NF mungkin sesuai dengan struktur pewarisan yang baik di mana kode yang umum digunakan dalam superclass. Saya yakin Anda bisa menemukan tempat yang sesuai injeksi ketergantungan di sana juga. Anda mencapai desain yang lebih baik (meskipun belum ditemukan bentuk normal) dengan menemukan pelanggaran prinsip desain yang baik dan refactoring.

Sebenarnya tidak ada metode algoritmik untuk mencapai desain yang baik di kedua dunia. Seperti yang ditunjukkan oleh Rein Hendrichs, ada banyak prinsip yang dapat mengidentifikasi masalah potensial (alias bau kode). Pola desain dan praktik terbaik adalah beberapa cara orang mencoba mengatasinya. Pengembangan yang digerakkan oleh percobaan mencoba untuk menemukannya lebih awal dengan menggunakan kode karena akan dilakukan secara eksternal. Seperti halnya dalam pengembangan basis data, solusi terbaik ditemukan dengan pengalaman dan analisis.

Pendekatan yang sangat baik untuk merancang objek model bisnis yang mirip dengan normalisasi adalah Pemodelan UML dalam Warna .

Ini adalah strategi desain yang ditemukan oleh Peter Coad yang membantu mengabstraksi objek model bisnis.

Sayangnya buku - Java Modeling In Color With UML: Enterprise Components and Process - terjual habis dan Anda hanya dapat membeli yang bekas.

Ada beberapa artikel di internet tentang teknik ini.

Jika Anda terbiasa dengan desain relasional, Anda akan menemukan Pemodelan UML dalam Warna berguna untuk memandu Anda:

• 'Modeling in Color' karya Peter Coad - Catatan oleh Stephen R. Palmer

Sudahkah Anda menyelidiki untuk menggunakan anotasi java ORM dalam kode Anda saat membuat diagram kelas Anda? Hibernate akan menghasilkan database setelah tahap pemodelan selesai. Diagram dalam contoh ini hanya penampil kode.

Referensi atau petunjuk objek mirip dengan kunci asing. Itu sedalam yang saya mau pikirkan tentang ini. :)

Sebenarnya saya akan berpikir lebih dalam. Jika Anda memodelkan objek Anda dengan duplikasi data 0 dan dapat "meminta" objek Anda dan melakukan pembaruan berbasis set pada mereka, tidak akan ada pemutusan. Bahkan Anda BISA melakukan ini dengan membuat perpustakaan objek konsumen. Microsoft telah melakukan hal ini tetapi mengarahkan pembuatan sintaks LINQ berbasis set bagian dari C # di atas "perpustakaan kueri".