Refactoring Legacy PHP untuk mematuhi prinsip pepejal

Untuk refactoring Legacy PHP Code, jawapannya adalah untuk meningkatkan kebolehkerjaan, kesesuaian dan fleksibiliti kod melalui peningkatan secara beransur-ansur dan bukannya penulisan semula satu kali; Amalan khusus termasuk: 1. Ikuti prinsip tanggungjawab tunggal dan memecah kelas yang menganggap terlalu banyak tanggungjawab ke dalam kelas kecil yang hanya bertanggungjawab untuk fungsi tertentu; 2. Ikuti prinsip pembukaan dan penutupan, mengembangkan fungsi melalui antara muka dan mekanisme polimorfik daripada mengubahsuai kod asal; 3. Ikuti prinsip penggantian Richter untuk memastikan subkelas boleh menggantikan kelas induk secara telus tanpa mengubah ketepatan program; 4. Ikuti prinsip pengasingan antara muka dan perpecahan antara muka kembung ke antara muka khusus yang lebih kecil; 5. Ikuti prinsip penyongsangan ketergantungan, dan membuat modul peringkat tinggi bergantung kepada abstraksi dan bukannya pelaksanaan konkrit melalui suntikan ketergantungan; Dalam operasi sebenar, ujian harus ditulis terlebih dahulu, kod masalah harus dikenalpasti, dan langkah-langkah kecil harus refactored, dan dengan bantuan alat, secara beransur-ansur meningkatkan kualiti kod daripada mengejar kesempurnaan satu masa, dan akhirnya membuat kod lebih mudah untuk memahami dan mengembangkan.

Refactoring Legacy PHP Code Untuk mengikuti prinsip -prinsip pepejal bukan tentang menulis semula segala -galanya semalaman -ini tentang membuat penambahbaikan yang lebih baik dan bijak yang meningkatkan kebolehkerjaan, kesesuaian, dan fleksibiliti. Sistem warisan sering mengalami gandingan ketat, pemisahan kebimbangan yang lemah, dan kelas kembung. Memohon prinsip -prinsip pepejal membantu menangani isu -isu ini secara sistematik.

Inilah cara mendekati kod pHP warisan refactoring dengan setiap prinsip yang kukuh dalam fikiran:

1. Prinsip Tanggungjawab Tunggal (SRP)

Kelas sepatutnya hanya mempunyai satu sebab untuk berubah.

Dalam PHP Legacy, anda akan sering mencari kelas yang melakukan terlalu banyak pertanyaan pangkalan data, format output, mengesahkan input, dan menguruskan logik perniagaan semua dalam satu fail.

Apa yang perlu dicari:

• Kelas dengan pelbagai kaedah awam melakukan perkara yang tidak berkaitan
• Kaedah panjang yang menggabungkan akses data, logik, dan output
• Pengawal yang juga mengendalikan pengesahan atau kegigihan

Cara Reflektor:

• Memecahkan kelas besar menjadi yang lebih kecil, yang fokus
• Ekstrak pengesahan, pemformatan, atau akses data ke dalam kelas khusus
• Gunakan kelas perkhidmatan untuk merangkum logik perniagaan

Contoh:

 // sebelum ini: kelas pengguna melakukan terlalu banyak
pengguna kelas {
    fungsi awam simpan () { / * menjimatkan ke db * /}
    fungsi awam sendWelcomeEmail () { / * menghantar e -mel * /}
    fungsi awam validate () { / * logik pengesahan * /}
}

// Selepas: Tanggungjawab berasingan
Kelas Userservice {
    Daftar Fungsi Awam (UserData $ data) {
        $ this-> validator-> validate ($ data);
        $ this-> userrepository-> save ($ user);
        $ this-> EmailService-> SendWelcome ($ user);
    }
}

Ini menjadikan setiap kelas lebih mudah untuk diuji dan mengubah suai secara bebas.

2. Prinsip Terbuka/Ditutup (OCP)

Entiti perisian hendaklah dibuka untuk lanjutan, tetapi ditutup untuk pengubahsuaian.

Kod warisan sering memerlukan perubahan kod sedia ada untuk menambah ciri -ciri baru -ini meningkatkan risiko melanggar sesuatu.

Apa yang perlu dicari:

• Tukar penyataan atau jika/rantai lain berdasarkan jenis
• Fungsi yang memerlukan penyuntingan setiap kali ciri baru ditambah

Cara Reflektor:

• Gunakan antara muka dan polimorfisme
• Ganti keadaan dengan strategi atau corak kilang

Contoh:

 // Sebelum ini: Menambah kaedah pembayaran baru memerlukan mengubah kod ini
Fungsi Processpayment ($ type, $ amaun) {
    jika ($ type === 'PayPal') {
        // Proses PayPal
    } elseif ($ type === 'Stripe') {
        // Jalur proses
    }
}

// selepas: dilanjutkan melalui kelas baru, bukan pengubahsuaian
Interface PaymentProcessor {
    Proses Fungsi Awam (Float $ Amaun): tidak sah;
}

Kelas PayPalProcessor melaksanakan PaymentProcessor { / * ... * /}
Kelas StripeProcessor melaksanakan PaymentProcessor { / * ... * /}

Kelas Paymentservice {
    Proses Fungsi Awam (PEMPERSEKUTAN PEMBAYARAN $ Pemproses, Float $ Amaun) {
        $ pemproses-> proses ($ jumlah);
    }
}

Sekarang anda boleh menambah kaedah pembayaran baru tanpa menyentuh logik sedia ada.

3. Prinsip Penggantian Liskov (LSP)

Subtipe mesti digantikan untuk jenis asas mereka.

Ini sering menjadi ganas apabila warisan digunakan secara tidak betul dalam kod warisan -EG, kelas kanak -kanak mengatasi kaedah induk dengan cara yang memecahkan jangkaan.

Apa yang perlu dicari:

• Kelas kanak -kanak membuang NotImplementedException
• Kaedah yang mengubah tingkah laku dengan cara yang tidak dijangka
• Warisan yang digunakan hanya untuk penggunaan semula kod, tidak benar "IS-a" hubungan

Cara Reflektor:

• Memihak kepada komposisi atas warisan
• Gunakan antara muka untuk menentukan kontrak
• Hierarki penstrukturan semula jadi kelas yang diperoleh tidak mengejutkan pengguna

Contoh: Elakkan membuat kelas Rectangle dan subclassing ke dalam Square jika menetapkan lebar mempengaruhi ketinggian tanpa diduga. Sebaliknya, gunakan komposisi atau kelas bebas yang berasingan.

4. Prinsip Pengasingan Antara Muka (ISP)

Pelanggan tidak boleh dipaksa bergantung pada antara muka yang mereka tidak gunakan.

Dalam warisan PHP, anda mungkin melihat antara muka besar atau kelas asas dengan banyak kaedah, memaksa pelaksana untuk membuang yang tidak digunakan.

Apa yang perlu dicari:

• Antara muka dengan terlalu banyak kaedah
• KELAS MELAKUKAN KAEDAH MEREKA MEREKA TIDAK PERLU (contohnya, mengembalikan null atau membuang pengecualian)

Cara Reflektor:

• Pecahkan antara muka besar ke dalam yang lebih kecil, berasaskan peranan
• Biarkan kelas melaksanakan hanya apa yang mereka perlukan

Contoh:

 // Sebelum: Satu antara muka besar
antara muka usermanagement {
    fungsi awam menyelamatkan ();
    fungsi awam padam ();
    fungsi awam SendeMail ();
    fungsi awam generatereport ();
}

// Selepas: Antara muka yang dipisahkan
Interface Storable {Public Function Save (); }
antara muka boleh ditanggalkan {fungsi awam padam (); }
antara muka mailable {public function sendEmail (); }
antara muka yang boleh dilaporkan {fungsi awam generateReport (); }

Kelas GuestUser melaksanakan penyimpanan, mailable {}
Kelas Adminuser melaksanakan penyimpanan, boleh ditanggalkan, dilaporkan {}

Sekarang kelas hanya bergantung pada apa yang sebenarnya mereka gunakan.

5. Prinsip Penyongsangan Ketergantungan (DIP)

Bergantung pada abstraksi, bukan pada konkrit.

PHP Legacy sering mempunyai ketergantungan keras (contohnya, new Database() di dalam kelas), membuat ujian dan pelaksanaan pertukaran keras.

Apa yang perlu dicari:

• kata kunci new yang digunakan di dalam logik perniagaan
• Nama Kelas Hardcoded dalam Kaedah
• Kesukaran mengejek kebergantungan dalam ujian

Cara Reflektor:

• Menyuntik kebergantungan melalui pembina atau kaedah
• Gunakan antara muka untuk meremehkan dari pelaksanaan konkrit
• PENGENALAN A CONTAINER DI SIMPLE jika diperlukan (walaupun suntikan manual membantu)

Contoh:

 // Sebelum: Gandingan ketat
Kelas Userservice {
    $ db swasta;
    fungsi awam __construct () {
        $ this-> db = mysqldatabase baru (); // hardcoded
    }
}

// Selepas: Suntikan Ketergantungan
Kelas Userservice {
    Fungsi awam __Construct (DatabaseInterface Private $ db) {}

    fungsi awam getUser ($ id) {
        kembali $ this-> db-> ambil ('pengguna', $ id);
    }
}

Sekarang anda boleh menyuntik pangkalan data mengejek untuk ujian atau beralih ke backend penyimpanan yang berbeza.

Langkah praktikal untuk kod warisan refactoring

Anda tidak perlu memohon semua prinsip pepejal sekaligus. Mulakan Kecil:

• Tulis ujian terlebih dahulu (jika tidak ada): Gunakan integrasi atau ujian unit untuk mengurangkan tingkah laku semasa.
• Kenal pasti pesalah terburuk : Cari kelas Tuhan, kaedah panjang, atau kawasan yang tinggi.
• Refactor dalam langkah -langkah kecil : Kaedah Ekstrak → Kelas Ekstrak → Pengenalan Antara muka → Invert Dependencies.
• Gunakan alat : phpstan, mazmur, atau rektor boleh membantu mengesan isu dan mengautomasikan beberapa refactoring.
• Jangan bertujuan untuk kesempurnaan : menjadikannya lebih baik daripada sebelumnya. Kemajuan ke atas kesucian.

Pepejal bukan senarai semak menulis semula -pemikiran itu. Dalam warisan PHP, memohon prinsip -prinsip ini secara beransur -ansur membawa kepada kod yang lebih mudah difahami, menguji, dan melanjutkan. Mulakan dengan SRP dan Dip; Mereka sering memberikan kemenangan terbesar dengan risiko yang paling sedikit.

Pada asasnya, jangan biarkan yang sempurna menjadi musuh yang lebih baik.

Atas ialah kandungan terperinci Refactoring Legacy PHP untuk mematuhi prinsip pepejal. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!