Lima Prinsip Dasar Desain Kelas (SOLID) ing Jawa

Kelas minangka blok saka aplikasi sing dibangun. Kaya bata ing bangunan. Kelas sing ditulis kanthi apik bisa nyebabake masalah ing sawijining dina. Kanggo mangerteni apa kelas ditulis kanthi bener, sampeyan bisa mriksa "standar kualitas". Ing Jawa, iki sing diarani prinsip SOLID. Ayo dadi pirembagan bab wong-wong mau.

Prinsip SOLID ing Jawa

SOLID minangka akronim sing dibentuk saka huruf kapital saka limang prinsip pisanan OOP lan desain. Prinsip kasebut diciptakake dening Robert Martin ing awal taun 2000-an, lan akronim kasebut banjur diciptakake dening Michael Feathers. Mangkene prinsip SOLID kalebu:

1. Prinsip Tanggung Jawab Tunggal.
2. Bukak Prinsip Tertutup.
3. Prinsip Substitusi Liskov.
4. Prinsip Segregasi Antarmuka.
5. Prinsip Inversi Dependensi.

Prinsip Tanggung Jawab Tunggal (SRP)

Prinsip iki nyatakake yen ora ana luwih saka siji alasan kanggo ngganti kelas. Saben obyek duwe siji tanggung jawab, rampung encapsulated ing kelas. Kabeh layanan kelas ditujokake kanggo njamin tanggung jawab iki. Kelas kasebut mesthi gampang diganti yen perlu, amarga jelas apa tanggung jawab kelas lan apa sing ora. Sing, iku bakal bisa kanggo nggawe owah-owahan lan ora wedi jalaran - impact ing obyek liyane. Lan kode kasebut luwih gampang dites, amarga sampeyan nutupi siji fungsi kanthi tes sing diisolasi saka kabeh liyane. Mbayangno modul sing proses pesenan. Yen pesenan digawe kanthi bener, bakal disimpen ing database lan ngirim email kanggo konfirmasi pesenan:

public class OrderProcessor {

    public void process(Order order){
        if (order.isValid() && save(order)) {
            sendConfirmationEmail(order);
        }
    }

    private boolean save(Order order) {
        MySqlConnection connection = new MySqlConnection("database.url");
        // save the order to the database

        return true;
    }

    private void sendConfirmationEmail(Order order) {
        String name = order.getCustomerName();
        String email = order.getCustomerEmail();

        // Sending a letter to the client
    }
}

Modul kasebut bisa diganti amarga telung alasan. Kaping pisanan, logika pangolahan pesenan bisa uga beda-beda, nomer loro, cara nyimpen (jinis database), katelu, cara ngirim surat konfirmasi (contone, tinimbang email sampeyan kudu ngirim SMS). Prinsip Tanggung Jawab Tunggal nuduhake yen telung aspek saka masalah iki sejatine telung tanggung jawab sing beda. Iki tegese kudu ana ing kelas utawa modul sing beda. Nggabungake pirang-pirang entitas sing bisa diganti ing wektu sing beda-beda lan kanggo alasan sing beda-beda dianggep minangka keputusan desain sing ala. Iku luwih apik kanggo dibagi modul dadi telung kapisah, saben kang bakal nindakake siji fungsi:

public class MySQLOrderRepository {
    public boolean save(Order order) {
        MySqlConnection connection = new MySqlConnection("database.url");
        // save the order to the database

        return true;
    }
}

public class ConfirmationEmailSender {
    public void sendConfirmationEmail(Order order) {
        String name = order.getCustomerName();
        String email = order.getCustomerEmail();

        // Sending a letter to the client
    }
}

public class OrderProcessor {
    public void process(Order order){

        MySQLOrderRepository repository = new MySQLOrderRepository();
        ConfirmationEmailSender mailSender = new ConfirmationEmailSender();

        if (order.isValid() && repository.save(order)) {
            mailSender.sendConfirmationEmail(order);
        }
    }

}

Prinsip Terbuka/Tertutup (OCP)

Prinsip iki kanthi ringkes diterangake kaya ing ngisor iki: entitas piranti lunak (kelas, modul, fungsi, lan sapiturute) kudu mbukak kanggo ekstensi, nanging ditutup kanggo owah-owahan . Iki tegese iku kudu bisa kanggo ngganti prilaku external saka kelas tanpa owah-owahan fisik kanggo kelas dhewe. Sawise prinsip iki, kelas dikembangake supaya bisa nyetel kelas menyang kondisi aplikasi tartamtu, cukup kanggo ngluwihi lan nemtokake maneh sawetara fungsi. Mulane, sistem kudu fleksibel, bisa digunakake ing kondisi variabel tanpa ngganti kode sumber. Terusake conto pesenan, ayo ngomong yen kita kudu nindakake sawetara tumindak sadurunge pesenan diproses lan sawise email konfirmasi dikirim. Tinimbang ngganti kelas dhewe OrderProcessor, kita bakal ngluwihi lan entuk solusi kanggo masalah sing ana ing tangan tanpa nglanggar prinsip OCP:

public class OrderProcessorWithPreAndPostProcessing extends OrderProcessor {

    @Override
    public void process(Order order) {
        beforeProcessing();
        super.process(order);
        afterProcessing();
    }

    private void beforeProcessing() {
        // Perform some actions before processing the order
    }

    private void afterProcessing() {
        // Perform some actions after order processing
    }
}

Barbara Liskov Substitution Principle (LSP)

Iki minangka variasi saka prinsip mbukak / tertutup sing wis dibahas sadurunge. Bisa diterangake kaya mangkene: obyek ing program bisa diganti dening ahli waris tanpa ngganti sifat program kasebut. Iki tegese kelas sing dikembangake kanthi nggedhekake kelas dhasar kudu ngilangi metode kasebut kanthi cara sing ora ngilangi fungsi saka sudut pandang klien. Yaiku, yen pangembang ngluwihi kelas sampeyan lan digunakake ing aplikasi, dheweke ora kudu ngganti prilaku sing dikarepake saka metode sing ditindhes. Subkelas kudu ngatasi metode kelas dasar kanthi cara sing ora ngilangi fungsi saka sudut pandang klien. Iki bisa ditliti kanthi rinci nggunakake conto ing ngisor iki. Ayo nganggep kita duwe kelas sing tanggung jawab kanggo validasi pesenan lan mriksa manawa kabeh barang pesenan ana ing saham. Kelas iki nduweni metode isValidsing ngasilake bener utawa salah :

public class OrderStockValidator {

    public boolean isValid(Order order) {
        for (Item item : order.getItems()) {
            if (! item.isInStock()) {
                return false;
            }
        }

        return true;
    }
}

Ayo uga nganggep manawa sawetara pesenan kudu divalidasi kanthi beda: priksa manawa kabeh barang ing pesenan ana ing saham lan apa kabeh barang wis dikemas. Kanggo nindakake iki, kita nambah kelas OrderStockValidatorkaro kelas OrderStockAndPackValidator:

public class OrderStockAndPackValidator extends OrderStockValidator {

    @Override
    public boolean isValid(Order order) {
        for (Item item : order.getItems()) {
            if ( !item.isInStock() || !item.isPacked() ){
                throw new IllegalStateException(
                     String.format("Order %d is not valid!", order.getId())
                );
            }
        }

        return true;
    }
}

Nanging, ing kelas iki kita nglanggar prinsip LSP, amarga tinimbang bali palsu yen pesenan ora lulus validasi, cara kita mbalang pangecualian IllegalStateException. Klien kode iki ora ngarep-arep iki: padha ngarepake bener utawa salah bakal bali . Iki bisa nyebabake kesalahan ing program.

Prinsip Split Antarmuka (ISP)

Ditondoi dening statement ing ngisor iki: Klien ora kudu dipeksa kanggo ngleksanakake cara sing padha ora bakal nggunakake . Prinsip pamisahan antarmuka nyaranake manawa antarmuka sing "kandel" kudu dipérang dadi luwih cilik lan luwih spesifik, supaya klien saka antarmuka cilik mung ngerti babagan cara sing dibutuhake kanggo karyane. Akibaté, nalika ngganti cara antarmuka, klien sing ora nggunakake cara iki ngirim ora ngganti. Ayo katon ing conto. Pangembang Alex nggawe antarmuka "laporan" lan nambahake rong cara: generateExcel()lan generatedPdf(). Saiki Klien A pengin nggunakake antarmuka iki, nanging mung arep nggunakake laporan PDF lan ora Excel. Apa dheweke bakal kepenak karo fungsi kasebut? Ora. Dheweke kudu ngetrapake rong cara, salah sijine ora perlu lan mung ana amarga Alex, perancang piranti lunak. Klien bakal nggunakake antarmuka sing beda utawa ninggalake kolom Excel kosong. Dadi apa solusine? Iku kasusun saka misahake antarmuka sing wis ana dadi loro cilik. Salah sawijining laporan ing format PDF, sing nomer loro yaiku laporan ing format Excel. Iki bakal menehi pangguna kesempatan kanggo nggunakake mung fungsi sing dibutuhake kanggo dheweke.

Prinsip Pembalikan Ketergantungan (DIP)

Prinsip SOLID iki ing Jawa diterangake kaya ing ngisor iki: dependensi ing sistem dibangun kanthi basis abstraksi . Modul tingkat ndhuwur ora gumantung saka modul tingkat ngisor. Abstraksi ngirim ora gumantung ing rincian. Rincian kudu gumantung saka abstraksi. Piranti lunak kudu dirancang supaya macem-macem modul otonom lan nyambungake siji liyane nggunakake abstraksi. Aplikasi klasik saka prinsip iki yaiku kerangka Spring. Ing framework Spring, kabeh modul dileksanakake minangka komponen kapisah sing bisa bebarengan. Padha mandhiri supaya bisa digunakake kanthi gampang ing modul piranti lunak liyane kajaba kerangka Spring. Iki digayuh liwat katergantungan prinsip tertutup lan mbukak. Kabeh modul menehi akses mung kanggo abstraksi sing bisa digunakake ing modul liyane. Ayo nyoba nduduhake iki nganggo conto. Ngomong babagan prinsip tanggung jawab tunggal, kita nganggep sawetara OrderProcessor. Ayo deleng maneh kode kelas iki:

public class OrderProcessor {
    public void process(Order order){

        MySQLOrderRepository repository = new MySQLOrderRepository();
        ConfirmationEmailSender mailSender = new ConfirmationEmailSender();

        if (order.isValid() && repository.save(order)) {
            mailSender.sendConfirmationEmail(order);
        }
    }

}

Ing conto iki, kita OrderProcessorgumantung ing rong kelas tartamtu MySQLOrderRepositorylan ConfirmationEmailSender. Kita uga menehi kode kanggo kelas kasebut:

public class MySQLOrderRepository {
    public boolean save(Order order) {
        MySqlConnection connection = new MySqlConnection("database.url");
        // save the order to the database

        return true;
    }
}

public class ConfirmationEmailSender {
    public void sendConfirmationEmail(Order order) {
        String name = order.getCustomerName();
        String email = order.getCustomerEmail();

        // Sending a letter to the client
    }
}

Kelas kasebut adoh saka diarani abstraksi. Lan saka sudut pandang prinsip DIP, bakal luwih bener kanggo miwiti kanthi nggawe sawetara abstraksi sing bakal ngidini kita bisa operate karo wong-wong mau ing mangsa ngarep, tinimbang karo implementasine tartamtu. Ayo nggawe rong antarmuka MailSenderlan OrderRepository, sing bakal dadi abstraksi kita:

public interface MailSender {
    void sendConfirmationEmail(Order order);
}

public interface OrderRepository {
    boolean save(Order order);
}

Saiki ayo ngetrapake antarmuka kasebut ing kelas sing wis siyap:

public class ConfirmationEmailSender implements MailSender {

    @Override
    public void sendConfirmationEmail(Order order) {
        String name = order.getCustomerName();
        String email = order.getCustomerEmail();

        // Sending a letter to the client
    }

}

public class MySQLOrderRepository implements OrderRepository {

    @Override
    public boolean save(Order order) {
        MySqlConnection connection = new MySqlConnection("database.url");
        // save the order to the database

        return true;
    }
}

Kita wis nindakake karya preparatory supaya kelas kita OrderProcessorora gumantung ing rincian konkrit, nanging ing abstraksi. Ayo gawe owah-owahan kanthi ngenalake dependensi ing konstruktor kelas:

public class OrderProcessor {

    private MailSender mailSender;
    private OrderRepository repository;

    public OrderProcessor(MailSender mailSender, OrderRepository repository) {
        this.mailSender = mailSender;
        this.repository = repository;
    }

    public void process(Order order){
        if (order.isValid() && repository.save(order)) {
            mailSender.sendConfirmationEmail(order);
        }
    }
}

Kelas kita saiki gumantung ing abstraksi tinimbang implementasi konkrit. Sampeyan bisa ngganti prilaku kanthi gampang kanthi nyuntikake ketergantungan sing dikarepake nalika instance digawe OrderProcessor. Kita ndeleng SOLID - prinsip desain ing Jawa. Luwih lengkap babagan OOP umume, dhasar basa pamrograman iki - ora mboseni lan latihan atusan jam - ing kursus JavaRush. Wektu kanggo ngrampungake sawetara masalah :)