Model Anemik dan Kaya dalam Konteks Template GRASP

Dalam edisi terbaru podcast DotNet & More, kami berdiskusi dengan Maxim Arshinov, laporannya yang akan datang tentang Moskwa. Selanjutnya, "Cemerlang dan Kemiskinan Model Subjek." Posisi Maxim akan mudah diakses langsung di konferensi. Dan, di samping itu, saya ingin mempertimbangkan visi debat besar model domain Anemic VS "Rich" ("Rich") melalui prisma dari template GRASP yang dulu populer


Diskusi telah berlangsung lama, misalnya:



Sebelum memulai analisis, saya ingin mengklarifikasi masalah perselisihan. Perbedaan utama antara model anemik dan yang kaya adalah bahwa ia tidak mengandung logika bisnis dalam tubuh kelas. Contoh yang terkenal dari model anemia adalah pola DTO yang terkenal.


Model "kaya", pada gilirannya, mungkin berisi logika yang menjelaskan aturan bisnis, fungsi , dll. Harap perhatikan bahwa kami mempertimbangkan metode yang mencerminkan logika bisnis. ToString, GetHashCode, dan bagian kelas "teknis" lainnya tidak termasuk dalam diskusi, dan karenanya diabaikan.


GRASP


Sebagaimana dicatat di awal artikel, kami akan mempertimbangkan masalah ini dalam konteks pola GRASP . Seperangkat template ini disajikan dalam buku oleh Craig Larman "Penggunaan UML dan Pola Desain" dan sangat memengaruhi pemrograman modern, misalnya, aturan Kopling Rendah / Kohesi Tinggi diumumkan dalam GRASP.


Untuk orang-orang yang terbiasa dengan pola GoF, rangkaian pola ini mungkin tampak terlalu kabur. Masalahnya adalah bahwa pola GRASP difokuskan bukan pada penyelesaian masalah yang diterapkan, tetapi pada distribusi tanggung jawab untuk tindakan dan operasi tertentu antara objek:


  • Pencipta bertanggung jawab untuk membuat objek.
  • Pengontrol bertanggung jawab atas operasi dari pengguna
  • Tipuan bertanggung jawab untuk mengatur hubungan lemah antara objek.
    Dan sebagainya.

Dalam konteks artikel ini, saya ingin fokus pada pola-pola berikut:


  • Ahli Informasi
  • Fabrikasi Murni

Ahli Informasi


Masalah: Apa prinsip dasar berbagi tanggung jawab antar fasilitas?
Solusi: Tetapkan tugas ini ke kelas yang memiliki informasi yang cukup untuk melaksanakannya.


Dengan kata lain:


Tanggung jawab harus diberikan kepada orang yang memiliki informasi maksimum yang diperlukan untuk pelaksanaan - ahli informasi.

Dalam konteks C # : metode harus dideklarasikan di kelas yang bidang dan propertinya digunakan dalam metode ini.
Misalnya, jika untuk menghitung jumlah utang, semua informasi yang diperlukan adalah inti dari debitur (jumlah, waktu penerbitan pinjaman), maka pada intinya inilah metode yang tepat harus diumumkan.
Tentu saja penyederhanaan ini agak berlebihan, tetapi poin utamanya harus jelas.


Fabrikasi Murni


Masalah: Kelas mana yang harus menyediakan implementasi Kohesi Tinggi dan Kopling Rendah jika templat Pakar Informasi tidak memberikan solusi yang sesuai.
Solusi: Tetapkan sekelompok tugas dengan tingkat keterlibatan tinggi ke kelas artifisial yang tidak mewakili konsep spesifik area subjek.


Dengan kata lain:


Jika tidak mungkin untuk secara tegas memilih entitas yang sesuai dari model subjek, yang tanggung jawabnya dapat diberikan, perlu untuk membuat kelas sintetis yang tidak ada di area subjek.

Dalam konteks C # : jika implementasi metode menyediakan untuk penggunaan seragam beberapa entitas atau dependensi eksternal, maka metode ini harus dinyatakan dalam kelas yang terpisah. Dan kelas-kelas ini disebut layanan.
Misalnya, jika untuk menghitung jumlah utang Anda perlu tahu tidak hanya atribut debitur, tetapi juga parameter bank (suku bunga, periode penundaan yang diizinkan), maka ada baiknya membuat layanan terpisah yang berisi metode yang sesuai.


Dan apa artinya semua ini?


Dalam konteks di atas, kita dapat membedakan algoritma yang cukup sederhana yang membantu untuk membuat keputusan, menempatkan metode dalam model atau layanan :


  • Jika metode hanya menggunakan properti model, itu harus dinyatakan dalam model
  • Jika suatu metode menggunakan, untuk sebagian besar, properti dari satu model dan hanya sebagian lainnya, itu dapat dideklarasikan dalam model
  • Jika metode ini secara seragam menggunakan properti beberapa model, maka ada baiknya memindahkannya ke layanan yang terpisah atau yang sudah ada
  • Jika suatu metode menggunakan ketergantungan eksternal, misalnya, suatu Repositori, itu harus dipindahkan ke layanan yang terpisah atau yang sudah ada


Ringkasan


Pola GRASP tidak bisa dilihat sebagai kebenaran tertinggi. Tetapi mereka dapat membantu untuk dengan mudah memahami objek mana yang digunakan untuk perilaku ini atau itu. Dengan demikian, sengketa adalah model anemia atau "kaya" mungkin tidak masuk akal, karena keputusan dibuat dalam setiap kasus, tergantung pada model area subjek dan perilaku yang terkait dengannya. Dalam proses perancangan sistem, kedua entitas dengan dan tanpa perilaku akan muncul. Dan ini benar sekali.

Source: https://habr.com/ru/post/id470021/


All Articles