Apa perbedaan antara Prinsip Tanggung Jawab Tunggal dan Pemisahan Kekhawatiran


19

a) Apa perbedaan antara SRP dan SoC ? Mungkin SRP diterapkan pada level kelas, sementara SoC dapat diterapkan pada level sistem , subsistem , modul , kelas atau fungsi .

b) Jika jawaban untuk a) adalah ya, apakah kemudian SoC diterapkan di tingkat kelas sinonim untuk SRP ?

Terima kasih

Jawaban:


13

Prinsip Tanggung Jawab Tunggal adalah tentang kode Anda hanya melakukan 1 hal dan Anda dapat membagi semua fungsionalitas dalam beberapa kelas yang semuanya dimaksudkan untuk melakukan 1 hal spesifik. Contohnya adalah kelas khusus untuk validasi, melakukan beberapa logika bisnis, memperkaya model, mengambil data, memperbarui data, navigasi, dll.

Separation of Concerns adalah tentang kode Anda yang tidak dipasangkan dengan erat ke beberapa kelas / sistem lainnya. Menggunakan antarmuka dalam kode Anda sangat membantu, dengan cara ini Anda dapat secara longgar menggabungkan beberapa kelas / sistem dengan kode Anda. Plusside dalam hal ini adalah lebih mudah untuk menguji unit Anda juga. Ada banyak kerangka kerja (IoC) yang dapat membantu Anda mencapai hal ini, tetapi tentu saja Anda dapat mengimplementasikannya sendiri juga.

Contoh sesuatu SoC, tetapi tidak memiliki SRP

public class Foo
{
    private readonly IValidator _validator;
    private readonly IDataRetriever _dataRetriever;

    public Foo(IValidator validator, IDataRetriever dataRetriever)
    {
        _validator = validator;
        _dataRetriever = dataRetriever;
    }

    public NavigationObject GetDataAndNavigateSomewhereIfValid()
    {
        var data = _dataRetriever.GetAllData();

        if(_validator.IsAllDataValid(data))
        {
            object b = null;
            foreach (var item in data.Items)
            {
                b = DoSomeFancyCalculations(item);
            }

            if(_validator.IsBusinessDataValid(b))
            {
                return ValidBusinessLogic();
            }
        }
        return InvalidItems();
    }

    private object DoSomeFancyCalculations(object item)
    {
        return new object();
    }
    private NavigationObject ValidBusinessLogic()
    {
        return new NavigationObject();
    }

    private NavigationObject InvalidItems()
    {
        return new NavigationObject();
    }
}

Seperti yang Anda lihat, kode ini tidak digabungkan dengan ketat ke kelas atau sistem lain, karena hanya menggunakan beberapa antarmuka untuk melakukan hal-hal. Ini bagus dari sudut pandang SoC.

Seperti yang Anda lihat kelas ini juga berisi 3 metode pribadi yang melakukan beberapa hal mewah. Dari sudut pandang SRP, metode-metode itu mungkin harus ditempatkan di dalam beberapa kelas mereka sendiri. 2 dari mereka melakukan sesuatu dengan navigasi, yang sesuai dengan beberapa kelas Navigasi. Yang lain melakukan beberapa perhitungan mewah pada suatu item, ini mungkin dapat ditempatkan dalam kelas IBusinessLogic.

Memiliki sesuatu seperti ini, Anda berdua memiliki SoC dan SRP di tempatnya:

public class Foo
{
    private readonly IValidator _validator;
    private readonly IDataRetriever _dataRetriever;
    private readonly IBusinessLogic _businessLogic;
    private readonly INavigation _navigation;

    public Foo(IValidator validator, IDataRetriever dataRetriever, IBusinessLogic businessLogic, INavigation navigation)
    {
        _validator = validator;
        _dataRetriever = dataRetriever;
        _businessLogic = businessLogic;
        _navigation = navigation;
    }

    public NavigationObject GetDataAndNavigateSomewhereIfValid()
    {
        var data = _dataRetriever.GetAllData();

        if(_validator.IsAllDataValid(data))
        {
            object b = null;
            foreach (var item in data.Items)
            {
                b = _businessLogic.DoSomeFancyCalculations(item);
            }

            if(_validator.IsBusinessDataValid(b))
            {
                return _navigation.ValidBusinessLogic();
            }
        }
        return _navigation.InvalidItems();
    }
}

Tentu saja Anda bisa berdebat jika semua logika ini harus ditempatkan dalam GetDataAndNavigateSomewhereIfValidmetode ini. Ini adalah sesuatu yang harus Anda putuskan sendiri. Bagi saya sepertinya metode ini melakukan terlalu banyak hal.


"Setelah membaca posting lengkap dalam jawaban JB King, saya pikir itu juga posting yang bagus." Tetapi jawaban JB King menyatakan kebalikan dari jawaban Anda - yaitu bahwa SoC juga tentang tanggung jawab tunggal, hanya saja itu dapat diterapkan pada tingkat yang lebih tinggi daripada SRP
user1483278

2

Adapun SRP hanya diterapkan di tingkat kelas, dalam bukunya Robert C. Martin (sejauh yang saya tahu ia mempopulerkan jika tidak muncul dengan konsep) menyatakan:

Kode Bersih, halaman. 138 : "Prinsip Tanggung Jawab Tunggal (SRP) menyatakan bahwa kelas atau modul harus memiliki satu, dan hanya satu, alasan untuk berubah."

Dalam Prinsip Agile, Pola dan Praktek di C #, halaman 116 : "[...] dan hubungkan kohesi dengan kekuatan yang menyebabkan modul , atau kelas, berubah."

Tekankan milikku.

Di APPP ia berbicara lebih banyak tentang SRP dan berfokus hampir sepenuhnya pada tingkat kelas. Walaupun dia tampaknya fokus pada level kelas, saya merasa prinsipnya juga diarahkan ke modul dan konstruksi level yang lebih tinggi lainnya.

Untuk alasan itu saya tidak akan memenuhi syarat SRP sebagai SoC di tingkat kelas seperti yang Anda sarankan dalam pertanyaan Anda.


Jadi jika kita berasumsi bahwa SRP juga dapat diterapkan pada tingkat yang lebih tinggi, maka perbedaan antara SRP dan SoC adalah bahwa SRP memiliki tanggung jawab tunggal, sementara SoC dapat memiliki serangkaian tanggung jawab yang terkait erat?
user1483278

@ user1483278: Yah saya sangat akrab dengan SRP tapi saya pertama kali mendengar SoC saat membaca pertanyaan ini jadi saya tidak bisa menjawab pertanyaan dalam komentar Anda. Dari semantik tampaknya SRP adalah tentang memiliki 1 responsabilitas dan keprihatinan SoC yang terpisah, saya tahu itu jawaban yang luar biasa tetapi dalam penerapan prinsip mengganggu menghasilkan hasil yang serupa.
Gilles

0

Di sini Anda dapat menemukan video pendek yang menjelaskan dengan jelas perbedaan antara istilah-istilah itu. https://www.youtube.com/watch?v=C7hkrV1oaSY

Pemisahan keprihatinan (SoC). Bagilah aplikasi Anda menjadi beberapa fitur berbeda dengan fungsi yang tumpang tindih sesedikit mungkin. (Microsoft).

“Kekhawatiran” = “fitur berbeda” = “bagian berbeda”

"Kepedulian" bekerja pada level tinggi dan rendah

Prinsip tanggung jawab tunggal menyatakan bahwa setiap modul atau kelas harus memiliki tanggung jawab atas satu bagian dari fungsi yang disediakan oleh perangkat lunak, dan bahwa tanggung jawab harus sepenuhnya dienkapsulasi oleh kelas. Semua layanannya harus selaras dengan tanggung jawab itu. (Definisi Wikipedia)

“Tanggung jawab” = “alasan untuk berubah”

ubah apa? “Satu bagian dari fungsi yang disediakan oleh perangkat lunak” = Unit Dasar

Kesimpulan

Prinsip Tanggung Jawab Tunggal bekerja pada unit dasar -> bekerja pada level rendah

Pemisahan Kekhawatiran bekerja pada level tinggi dan rendah

SRP dan SoC bekerja bersama untuk memisahkan masalah. Mereka persis sama di level rendah


0

Inilah pemahaman saya tentang prinsip-prinsip ini.

Separation of Concerns (SoC) - adalah tentang membagi sistem perangkat lunak menjadi modul yang lebih kecil, masing-masing pada modul ini bertanggung jawab atas satu masalah. Kekhawatiran, dalam hal ini, adalah fitur atau kasus penggunaan sistem perangkat lunak. Modul memiliki API (antarmuka) yang terdefinisi dengan baik sehingga menjadikan keseluruhan sistem sangat kohesif. Ada dua tipe utama: horisontal dan vertikal.

Prinsip Tanggung Jawab Tunggal (SRP) - adalah prinsip desain yang menyatakan bahwa setiap blok bangunan (dapat berupa kelas, modul, objek, atau bahkan fungsi) dari suatu sistem harus hanya memiliki satu tanggung jawab tunggal. Robert C. Martin. Martin menggambarkan tanggung jawab sebagai alasan untuk berubah. Secara umum, jauh lebih baik untuk memiliki satu kelas / objek yang memiliki tanggung jawab atas satu bagian dari fungsi alih-alih mampu melakukan banyak fungsi, kadang-kadang bahkan tidak terkait, membuat kelas ini besar dan erat digabungkan, jadi disebut "objek Tuhan".

Saya juga menjelaskan prinsip-prinsip ini secara lebih rinci dalam posting blog saya, silakan lihat.

https://crosp.net/blog/software-architecture/srp-soc-android-settings-example/

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.