Proyek Perangkat Lunak dan Evolusi OOP

Menguasai resep untuk pengembangan proyek perangkat lunak yang efektif, saya mencoba menemukan sendiri alasan yang membuatnya berguna untuk menggunakan prinsip-prinsip pengembangan arsitektur SOLID (artikel Bagaimana tidak memahami prinsip-prinsip pengembangan arsitektur SOLID ).

Analisis terhadap prinsip-prinsip ini memungkinkan untuk memilih beberapa pola kunci dan elemen dasar yang ada dalam pembangunan. Mereka memungkinkan kami untuk menggambarkan, memahami dan mengimplementasikan SOLID dalam pekerjaan nyata dengan proyek perangkat lunak.

Menjadi menarik untuk melakukan analisis penerapan konsep-konsep ini untuk paradigma pemrograman yang diterima secara umum, misalnya, untuk OOP. Nah, jika hasil karya ini akan bermanfaat bagi Anda.

Saat ini, ada banyak pendekatan untuk desain dan implementasi proyek perangkat lunak selanjutnya. Yang paling dituntut dalam bekerja dengan proyek perangkat lunak besar adalah: pemrograman struktural , pemrograman fungsional , pemrograman berorientasi objek .

Bagi saya, menjadi menarik untuk menganalisis penyebab pendekatan desain ini. Dan dalam proses analisis, penemuan tak terduga adalah fakta bahwa mereka semua secara implisit didasarkan pada premis berikut:

          ,      . 

Pengembangan Proyek Perangkat Lunak

Apa itu proyek tanpa perlu pengembangan? Proyek-proyek seperti itu jarang ditemukan dan terutama ditandai dengan pembayaran upah per satuan cepat tanpa kewajiban berikutnya dari pihak programmer, misalnya:

• sebuah proyek kecil yang dapat ditulis dengan satu pendekatan;
• Sebuah proyek tanpa kode yang rumit secara struktural, dibebani dengan sejumlah besar hubungan;
• produk perangkat lunak tanpa memerlukan dukungan dan dukungan pengguna.

Dalam situasi seperti itu, upaya programmer untuk mempertahankan, misalnya, pendekatan berorientasi objek terbuang sia-sia. Sering terjadi bahwa saya menemukan diri saya dalam pelajaran yang tidak berarti selama pengembangan utilitas konsol satu kali, ketika saya tiba-tiba menyadari bahwa menulis teks kelas 4 di proyek ini menunda saya selama 15 menit dan tidak membawa saya lebih dekat dengan hasilnya. Yang paling menyedihkan adalah bahwa semua kelas yang hampir tidak ditulis dalam proyek semacam itu dilupakan dan tidak digunakan kembali, yaitu, mereka tidak memfasilitasi pekerjaan kita di masa depan.

Dalam semua situasi lain, programmer, meminimalkan pekerjaannya, harus mengembangkan proyek yang kompleks secara struktural, yaitu:

• Memperbaiki kesalahan dengan menganalisis kode dan menemukan tempat di mana kesalahan ini dihasilkan.
• Untuk memperkenalkan fungsionalitas baru, sambil mempertahankan fungsionalitas semua kemampuan yang tersedia sebelumnya. Dalam melakukannya, gunakan kode yang ada (ditulis dan diuji) dalam pelaksanaan tugas-tugas baru ini.
• Berikan dukungan dalam menggunakan produk perangkat lunak.
• Lakukan deskripsi dan koordinasi fungsi semua versi proyek.
• Simpan semua format data yang digunakan oleh proyek (bahkan ketinggalan jaman) operasional.
• Dan melakukan banyak tugas lain yang muncul dalam konfrontasi dengan pesaing yang disebabkan oleh perubahan kerangka kerja atau akhir dukungan untuk OS usang ...

Jika Anda mencari analogi dengan pengembangan proyek perangkat lunak, Anda dapat mengingat evolusi spesies biologis.

      "".     -       .       -  . 

Pekerjaan programmer tidak mudah, tetapi programmer memiliki "pembantu". Penolong ini tersembunyi di suatu tempat jauh di dalam struktur dunia kita, di mana ada dua fitur:

• kemampuan untuk menulis satu algoritma yang bermanfaat dan menggunakannya untuk banyak tugas serupa,
• kehadiran banyak tugas serupa dalam solusi mereka.

Algoritma ini, berguna dalam banyak bidang, akan disebut algoritma universal untuk singkatnya. Implementasinya untuk bidang aplikasi tertentu dapat disebut spesialisasi, karena proses penyempurnaan algoritma untuk digunakan dalam bidang aplikasi yang sempit mirip dengan spesialisasi evolusi sel dalam organisme hidup.

Jelas, untuk membuat suatu algoritma, perlu untuk mengidentifikasi fitur yang memastikan penerapan algoritma. Tanda-tanda ini harus dicari dalam input data dan dalam deskripsi situasi awal (konteks). Untuk membuat algoritma universal , perlu di setiap bidang subjek, yang memiliki serangkaian tanda data dan situasi, untuk mengidentifikasi tanda-tanda penerapan yang identik untuk semua bidang. Semua tanda lain yang tidak memberikan penerapan diabaikan oleh algoritma universal . Memformalkan algoritma universal , kami sampai pada perlunya menggunakan abstraksi - salah satu prinsip terpenting OOP. Selain itu, OOP dicirikan oleh penekanan hanya pada abstraksi data.

Di sini saya akan mencoba menulis contoh menggunakan abstraksi dari berbagai bidang.

Blok bangunan proyek perangkat lunak

Menggunakan berbagai teknik abstraksi, programmer mengimplementasikan algoritma dalam bentuk bagian kode, yang merupakan elemen yang terpisah dan lengkap dari karyanya. Elemen ini, tergantung pada bahasa pemrograman yang digunakan, dapat berupa fungsi, objek, dan urutan instruksi. Untuk kenyamanan diskusi lebih lanjut, kami akan menyebut fragmen kode ini dengan kata " komponen ".

Komponen - sepotong kode (prosedur, kelas, komponen penempatan, dll.):

• yang mengimplementasikan beberapa algoritma lengkap yang bekerja dalam situasi awal tertentu dan dengan data input tertentu,
• yang dapat digunakan beberapa kali dalam satu proyek (bahkan lebih baik berkali-kali dalam proyek yang berbeda),
• semua instruksi yang terletak dekat dan dilihat tanpa perlu operasi pencarian tambahan di lingkungan pengembangan,
• perubahan yang dilakukan oleh pemrogram relatif independen sehubungan dengan sisa kode.

Pola dalam pengembangan proyek perangkat lunak

Menggunakan komponen istilah, menjadi mungkin untuk merumuskan seperangkat undang-undang sederhana yang ada dalam pengembangan proyek perangkat lunak. Saya akan menyajikan pola-pola ini dalam bentuk pernyataan berikut, dibagi menjadi 3 kategori.

1. Pernyataan yang menggambarkan sifat-sifat suatu komponen .
   1.1. Komponen yang ditulis dengan benar harus digunakan dan lebih sering beberapa kali.
   1.2. Di setiap tempat di mana komponen digunakan, perilaku konstan diharapkan darinya, yang mengarah ke hasil yang berulang.
   1.3. Saat menggunakan komponen di beberapa tempat, hasilnya harus memuaskan setiap tempat penggunaan.
   1.4. Perilaku yang tertanam dalam komponen menciptakan batasan tempat penggunaan komponen ini.
   1.5. Di setiap tempat penggunaan komponen , semua batasannya dapat dilibatkan.
   1.6. Setiap perubahan pada komponen akan mengubah keterbatasannya dan membutuhkan verifikasi semua tempat penggunaannya, yang menyebabkan programmer membuang waktu.
   1.7. Dianjurkan untuk menulis komponen dalam bentuk kode dalam satu contoh, yaitu, perlu untuk menghilangkan duplikasi kode yang sama. Ini akan mengurangi jumlah pengeditan saat membuat perubahan ke komponen .
2. Pernyataan yang menggambarkan pola dalam pelaksanaan tugas baru oleh programmer.
   2.1. Dianjurkan untuk memilih opsi untuk mengimplementasikan tugas baru sambil meminimalkan waktu yang dihabiskan oleh programmer.
   2.2. Untuk mengimplementasikan tugas baru, programmer dapat menambahkan komponen baru atau mengubah perilaku komponen lama.
   2.3. Menambahkan komponen pada dasarnya hanya memerlukan pemeriksaan di tempat penggunaan baru, dan menghasilkan waktu minimal untuk programmer.
   2.4. Perubahan perilaku komponen yang disebabkan oleh tugas baru, menurut pernyataan [1.6], memerlukan verifikasi di tempat penggunaan baru dan di semua tempat penggunaan lama, yang menghasilkan waktu tambahan untuk pemrogram dibandingkan dengan situasi dalam pernyataan [2.3]. Dalam kasus komponen yang diterbitkan , ini membutuhkan pekerjaan semua programmer menggunakan komponen yang dimodifikasi.
3. Pernyataan yang menggambarkan pola dalam interaksi algoritma universal dan spesialisasi mereka:
   3.1. Ada kesempatan untuk menulis komponen dasar (nama ini diperkenalkan dengan analogi dengan kelas dasar dan demi singkatnya kita akan menggunakan kata " basis "). Basis hanya memenuhi fitur paling penting dari beberapa algoritma universal .
   3.2. Dimungkinkan untuk menulis komponen - spesialisasi (selanjutnya untuk singkatnya kita akan menggunakan kata " spesialisasi "). Spesialisasi melengkapi algoritma universal dari pangkalan , sehingga dapat diterapkan pada area penggunaan tertentu.
   3.3. Basis , sebagai berikut dari pernyataan [3.1], [3.2], memiliki kompleksitas kurang dan pembatasan aplikasi lebih sedikit daripada spesialisasi .
   3.4. Menurut pernyataan [1.7], disarankan untuk mengembangkan spesialisasi tanpa duplikasi kode algoritma universal dari database .
   3.5. Tempat penggunaan database tidak memerlukan verifikasi setelah melakukan perubahan pada spesialisasi yang dibentuk dengan benar.

Konsep Pemrograman Berorientasi Objek

Saya akan mencoba, menggunakan pernyataan di atas, untuk menganalisis konsep dasar pemrograman berorientasi objek. Analisis ini memotong konsep abstraksi , karena sudah dijelaskan sebelumnya dalam formalisasi metode membangun algoritma universal .

Kelas, Obyek

Konsep-konsep OOP ini memperkuat kelayakan menggunakan jenis komponen khusus yang dijelaskan oleh kombinasi beberapa data internal dan metode untuk bekerja dengan data ini. Semua pernyataan dari grup [1] dan [2] diterjemahkan ke dalam OOP, di mana komponen istilah diganti dengan konsep kelas .

Pada saat yang sama, pada pandangan pertama, hubungan antara kelas dan objek habis oleh sekelompok pernyataan [3], di mana basis digantikan oleh konsep kelas , dan implementasinya digantikan oleh konsep objek . Selain itu, implementasinya dinamis, yaitu dapat berubah selama pelaksanaan program.

Enkapsulasi

Konsep " enkapsulasi " dapat dipertimbangkan dari dua "sisi".

Sisi pertama dari konsep " enkapsulasi " adalah isolasi komponen dari bagian lain dari kode. Properti ini memungkinkan pemrogram untuk melakukan operasi di area kode yang terletak "tutup" untuk membuat perubahan pada komponen . Yaitu, untuk meminimalkan waktu yang dihabiskan oleh programmer dengan mengecualikan dari pekerjaan pencarian dan analisis elemen-elemen yang berinteraksi secara berbeda dari program. Sisi ini ditentukan oleh sifat-sifat komponen berikut dari definisinya.

Sisi kedua dari konsep " enkapsulasi " adalah penyembunyian implementasi internal komponen . Penyembunyian ini dimungkinkan dengan menggunakan konsep-konsep dasar dan implementasi yang dijelaskan dalam kelompok pernyataan [3]. Untuk melakukan ini, metode kelas publik diidentifikasi dengan basis , dan metode kelas swasta dan dilindungi diidentifikasi dengan implementasi . Di tempat-tempat penggunaan, pembatasan yang dibuat oleh basis digunakan , dan oleh karena itu menjadi mungkin untuk membuat perubahan dalam implementasi yang tidak terkait dengan pembatasan dasar . Dan perubahan implementasi ini tidak perlu diperiksa di tempat-tempat di mana database digunakan [3.5], yang meminimalkan tenaga kerja programmer.

Patut dicatat bahwa konsep " enkapsulasi " memiliki analogi dalam biologi. Proses pertama ini mirip dengan fungsi biologis " Sel membran ".

Warisan

Konsep " warisan " terus memperkuat pentingnya menggunakan kombinasi implementasi basis +. Untuk ini, dalam kelompok pernyataan [3] perlu untuk mengidentifikasi metode kelas induk dengan basis , dan mengidentifikasi metode kelas penerus dengan implementasi .

Dalam implementasinya, konsep " pewarisan " memungkinkan penggunaan pernyataan [2.3], yaitu, menggunakan penambahan kode alih-alih mengubah dan menggandakannya. Dalam hal ini, perlu untuk mengecualikan duplikasi dari algoritma dasar . Namun, pendekatan yang menggunakan pewarisan untuk mengkhususkan algoritma universal memiliki minus yang signifikan. Kerugian ini adalah adanya dua komponen yang sangat terhubung, yang sulit diubah secara independen. Hubungan ketergantungan ini dihasilkan oleh hubungan orangtua-anak.

Ada banyak cara alternatif untuk menggunakan bundel basis + implementasi . Saya akan memberikan contoh lebih lanjut tentang metode tersebut.

Pada saat yang sama, saya perhatikan bahwa untuk konsep " warisan " dari PLO, orang juga dapat menemukan analogi dalam proses evolusi biologis. Dalam biologi, istilah " hereditas " digunakan untuk ini.

Polimorfisme

Menurut pendapat saya, konsep " polimorfisme " adalah sisi kedua ketika melihat prosedur untuk membuat algoritma universal . Sisi pertama ( abstraksi ) adalah pandangan dari sudut pandang bagaimana membuat algoritma universal . Pada saat yang sama, ketika melihat algoritma universal dari sudut pandang pengguna, kami mendapatkan catatan konsep polimorfisme . Artinya, polimorfisme adalah kemampuan yang berguna dari suatu fungsi ( komponen ) untuk memproses data dari berbagai jenis. Menambahkan konsep ini ke OOP memperkuat kegunaan menggunakan algoritma universal dalam pengembangan proyek perangkat lunak.

Implementasi polimorfisme dalam berbagai bahasa pemrograman sangat berbeda. Dalam artikel Wikipedia untuk polimorfisme , tergantung pada implementasinya, ada 4 subtipe: parametrik, inklusi (atau subtipe), overload, tipe casting. Implementasi ini memiliki perbedaan signifikan, tetapi semuanya disatukan oleh satu tujuan - ini menulis algoritma universal yang tidak perlu diduplikasi untuk spesialisasi spesifiknya.

Dan kali ini, hampir tanpa kejutan, ia menemukan analogi untuk konsep " polimorfisme " dalam biologi. Nama istilah biologis ini sepenuhnya sesuai dengan konsep OOP. " Polimorfisme " - kemampuan satu organisme untuk hidup di negara dengan struktur internal yang berbeda atau dalam bentuk eksternal yang berbeda.

Kesimpulan

Dengan demikian, hampir semua konsep dasar OOP dapat direpresentasikan sebagai seperangkat pernyataan sederhana yang dibentuk atas dasar hukum pengembangan proyek perangkat lunak. Selain itu, untuk OOP, komponen istilah diidentifikasi dengan konsep kelas . Jika kita memilih arti yang berbeda untuk komponen istilah, misalnya, fungsi , maka dimungkinkan untuk merumuskan konsep dasar pemrograman fungsional .

Dalam proses penulisan artikel, analogi biologis ditemukan untuk konsep yang digunakan dalam pemrograman. Analogi ini muncul karena kesamaan metode pengembangan produk perangkat lunak dan beberapa proses evolusi biologis.

IMHO, disarankan untuk mempertimbangkan kedua bidang ilmiah ini bersama-sama. Dalam hal ini, dimungkinkan untuk melakukan transfer undang-undang dari satu industri ke industri lainnya, dan dengan demikian memastikan pengembangan teknologi informasi dan deskripsi formal proses biologis.

Terima kasih atas perhatian anda

Ulasan

Saya akan sangat berterima kasih atas umpan balik, saran dan saran, karena mereka membantu saya menyesuaikan arah pengembangan pekerjaan di bidang ini.

Referensi

• Teori umum tentang algoritma wiki
• Artikel pertama dari seri ini

Diedit oleh Borisova M.V.