Apakah OOP menjadi lebih mudah atau lebih sulit? [Tutup]


36

Ketika konsep Pemrograman Berorientasi Objek diperkenalkan kepada pemrogram tahun yang lalu itu terlihat menarik dan pemrograman lebih bersih. OOP seperti ini

Stock stock = new Stock();
stock.addItem(item);
stock.removeItem(item);

Itu lebih mudah dipahami dengan nama deskriptif diri.

Tapi sekarang OOP, dengan pola seperti Objek Transfer Data, Nilai Objek, Repositori, Ketergantungan Injeksi dll, telah menjadi lebih kompleks. Untuk mencapai hal di atas, Anda mungkin harus membuat beberapa kelas (misalnya abstrak, pabrik, DAO dll) dan Menerapkan beberapa antarmuka

Catatan: Saya tidak menentang praktik terbaik yang membuat Kolaborasi, Pengujian, dan Integrasi menjadi lebih mudah


23
Menciptakan arsitektur perangkat lunak yang baik selalu sulit dan akan (kemungkinan besar) akan selalu terjadi.
johannes

6
Saya akan mengganti nama addItemuntuk adddan removeItemuntuk remove. Karena lebih mudah dibaca. stock.add(item)atau stock.remove(item). Dan lebih berorientasi OOP.
razpeitia

1
OOP asli hampir tidak seperti yang Anda perlihatkan. OOP bukan tentang sintaks , ini tentang semacam abstraksi yang dipopulerkan oleh Smalltalk. Ini tidak selalu membuktikan pendapat Anda salah, premis juga tidak cacat; bahkan lebih benar daripada yang Anda sadari.
Konrad Rudolph

1
Anda membandingkan apel dan jeruk, dengan logika Anda, maka pemrograman imperatif (yaitu loop dan jika-kondisi) lebih sederhana daripada semua hal yang kita miliki saat ini. Pemrograman imperatif adalah blok bangunan untuk kelas / OOP, dan kelas / OOP adalah blok bangunan untuk pola desain. Segala sesuatunya menjadi lebih kompleks ketika Anda maju karena Anda memecahkan masalah yang lebih kompleks.
Lie Ryan

2
@ LieRyan - Saya telah melihat masalah menjadi kompleks hanya karena tidak ada orang yang bertanggung jawab yang mampu menyelesaikannya dengan pemrograman imperatif sederhana dan menyerang mereka dengan pola desain di atas OOP di atas solusi imperatif sederhana yang seharusnya diimplementasikan sendiri.
mouviciel

Jawaban:


35

OOP sendiri tidak banyak berubah sejak awal. Beberapa sudut pandang baru telah dieksplorasi, tetapi prinsip-prinsip inti masih sama. Jika ada, pengetahuan kolektif yang dikumpulkan selama bertahun-tahun membuat hidup programmer lebih mudah daripada lebih sulit. Pola desain bukan halangan; mereka menyediakan kotak peralatan solusi untuk masalah standar, disaring dari pengalaman bertahun-tahun.

Jadi mengapa Anda menganggap OOP hari ini lebih kompleks daripada ketika Anda mulai menggunakannya?

Salah satu alasannya mungkin karena kode Anda terkena menjadi lebih kompleks - bukan karena OOP telah menjadi lebih kompleks, tetapi karena Anda telah maju pada tangga pembelajaran, dan bisa membaca basis kode yang lebih besar dan lebih kompleks.

Alasan lain mungkin karena paradigma kompleksitas tidak berubah, ukuran dan kompleksitas proyek perangkat lunak rata-rata mungkin sangat baik. Dengan kekuatan pemrosesan yang tersedia pada ponsel tingkat pelanggan yang akan menjadi mimpi basah pengembang di server kurang dari dua dekade lalu, masyarakat umum pada dasarnya mengharapkan GUI animasi apik untuk aplikasi pembuangan sekalipun yang termurah, dan PC desktop entry-level menjadi lebih kuat daripada "superkomputer" tahun 1980-an, wajar saja jika bilah telah dinaikkan sejak awal Smalltalk dan C ++.

Dan kemudian ada fakta bahwa dalam aplikasi modern, konkurensi dan paralelisme adalah norma daripada pengecualian, dan aplikasi sering perlu berkomunikasi antara mesin yang berbeda, mengeluarkan dan mengurai seluruh kebun binatang protokol. Meskipun OOP hebat sebagai paradigma organisasi, OOP memiliki keterbatasan, seperti halnya paradigma lain: misalnya, OOP tidak memberikan banyak abstraksi untuk konkurensi (sebagian besar implementasi lebih atau kurang merupakan renungan, atau di-outsource ke perpustakaan sepenuhnya) , dan itu bukan pendekatan terbaik untuk membangun parser dan mengubah data. Pemrograman modern sering mengalami keterbatasan paradigma OOP, dan pola desain hanya dapat membawa Anda sejauh ini. (Sendiri, Saya menganggap fakta bahwa kita membutuhkan pola desain tanda ini - jika paradigma menyediakan solusi ini di luar kotak, itu akan lebih ekspresif untuk masalah ini, dan solusi standar akan jelas. Tidak ada pola desain untuk menggambarkan pewarisan metode, karena ini adalah fitur inti dari OOP; tetapi ada Pola Pabrik, karena OOP tidak memberikan cara alami yang jelas untuk membuat objek secara polimorfis dan transparan.)

Karena itu, sebagian besar bahasa OOP modern menggabungkan fitur dari paradigma lain, yang membuatnya lebih ekspresif dan lebih kuat, tetapi juga lebih kompleks. C # adalah contoh utama untuk ini: ia memiliki akar OOP yang jelas, tetapi fitur seperti delegasi, peristiwa, inferensi tipe, tipe data varian, atribut, fungsi anonim, ekspresi lambda, generik, dll., Berasal dari paradigma lain, terutama Pemrograman Fungsional .


Jadi pola desain menambah kompleksitas. Arti pola desain tidak harus OOP tetapi ditambahkan untuk meningkatkan OOP.
tunmise fasipe

@tunmisefasipe: Tidak cukup. Pola desain hanyalah solusi yang terbukti untuk masalah standar; mereka bukan 'tambahan' untuk OOP, tetapi konsekuensi. Kompleksitas sudah ada di sana; pola desain hanya menyediakan strategi buku resep untuk mengatasinya.
tdammers

17

Tidak, ini menjadi lebih direkayasa. Dan Anda benar - dalam obrolan SO C ++ kami sering bercanda tentang AbstractSingletonFactoryProxyBeanBridgeAdapterManagers yang kita lihat dalam kode Java.

Tetapi kode yang baik tidak menunjukkan properti ini. Dalam kode yang baik, Anda masih bisa mengatakannya

std::stack<int> s;
s.push(5);
s.pop();

4
Tidak jelas dari posting Anda, tapi saya pikir over-engineering terbukti dalam kode Java dan C ++. Ini bukan properti dari kedua bahasa dengan sendirinya, tetapi dari praktik programmer ... Kedua bahasa memungkinkan penulisan kode yang baik, meskipun tidak (IMO) sangat cocok untuk itu :) Kerangka kerja di Jawa payah, sayangnya.
Andres F.

12
Berbicara tentang rekayasa berlebihan, utas ini wajib: Bahas.joelonsoftware.com/default.asp?joel.3.219431
Aman

3
@AndresF. benar, tetapi Anda tampaknya tidak mendapatkan begitu banyak dalam kode C ++, sedangkan yang Anda lakukan di Jawa dan. NET: lihat saja pola desain MVVMVMMD msdn.microsoft.com/en-us/magazine/hh965661.aspx sebagai salah satu contoh bagaimana Anda mengambil 'kode sederhana' dan menampar pola desain di atasnya untuk membuatnya terlihat 'lebih mudah' dan kemudian menampar pola desain lain pada pola desain karena pola aslinya tidak sesederhana seperti yang diiklankan. Over-engineering menjadi semakin umum.
gbjbaanb

5
Saya akan berdebat dengan bit "menjadi". Over-engineering sama tuanya dengan engineering.
Gort the Robot

4
@AndresF. Kami terutama anti-Jawa dalam obrolan, tetapi memang benar bahwa Java, lebih dari C ++ , mendorong over-engineering karena membuatnya lebih terjangkau (GC), dan perpustakaan Java perusahaan yang populer telah mempopulerkan gaya ini, seperti yang telah Anda catat dirimu sendiri.
Konrad Rudolph

10

Saya akan mengatakan bahwa masalah dengan "kompleksitas" yang Anda sebutkan tidak ada hubungannya dengan OOP. Ini lebih terkait dengan memisahkan masalah.

Beberapa tahun yang lalu saya bekerja pada suatu sistem, di mana kelas domain memiliki tanggung jawab memuat dirinya sendiri dari database, misalnya

var userId = Request.QueryString["UserID"].ToInt();
var user = new User(userId);
user.Name = ...;
...
user.Save();

Ini adalah kode yang sangat jelas. Tidak ada masalah dalam memahami ini. Namun masalahnya adalah di unit yang menguji kode. Yaitu, bagaimana saya menguji unit Userkelas tanpa harus memuat satu dari database? Dan bagaimana saya menguji kode penanganan permintaan web ini tanpa memiliki akses ke database? Itu tidak mungkin.

Itulah sebabnya kami memiliki pola seperti repositori, untuk memisahkan tanggung jawab penanganan logika domain dari pengguna dari fungsi pemuatan dan penyimpanan yang sebenarnya di penyimpanan data. IOC membantu mengurangi kopling, juga membuat kode lebih dapat diuji, dll.

Jadi jika kita kembali ke contoh yang Anda tulis, apa yang akan Anda lakukan dengan stok setelah Anda membuatnya? Simpan di basis data

Stock stock = new Stock();
stock.addItem(item);
stock.removeItem(item);
this.StockRepository.Add(stock);

Yang merah! Tidak ada gerakan dalam perkembangan OOP yang menunjukkan bahwa itu harus lebih sulit. Sayangnya, jika Anda memilih untuk menggunakan ATAU mapper untuk kode akses data Anda, Anda bisa mengalami masalah bahwa ATAU mapper menempatkan batasan pada bagaimana Anda dapat menulis sistem Anda. Tapi itu masalah lain.

Jika Anda baru mengenal pola-pola ini, Anda mungkin perlu mempelajari gaya pemrograman baru. Tetapi gaya pemrograman itu tidak lebih sulit dari pemrograman OOP sekolah lama.


Anda tahu upaya yang harus Anda lakukan untuk mengatur repositori Anda. Meskipun setelah pengaturannya, itu dapat digunakan kembali.
tunmise fasipe

mungkin masalahnya adalah dengan pengujian unit, jika kita memiliki alat yang lebih baik untuk menguji keseluruhan (seperti yang harus Anda lakukan) daripada potongan kecil, kita akan memiliki sistem yang memiliki bug lebih sedikit?
gbjbaanb

2
@ gbjbaanb: kita sudah memiliki itu, yang disebut pengujian integrasi / fungsional. Pengujian unit memiliki tujuan yang berbeda tetapi sama pentingnya
Kevin

@gbjbaanb - Kami sudah memiliki alat yang hebat untuk pengujian seluruh sistem / penerimaan, misalnya Mentimun di platform Rails. Tetapi tim yang benar-benar bagus dan menulis sangat sedikit bug, tetapi juga memberikan hasil yang cepat, mereka menulis banyak tes unit, dan hanya beberapa tes di seluruh sistem. Lihat tentang "Segitiga pengujian", misalnya di sini jonkruger.com/blog/2010/02/08/the-automated-testing-triangle
Pete

4

Tidak juga. Masalah kita belum benar-benar berubah; bilah untuk kode yang dapat diterima telah dimunculkan.

Untuk mencapai hal di atas, Anda mungkin harus membuat beberapa kelas (misalnya abstrak, pabrik, DAO dll) dan Menerapkan beberapa antarmuka

Anda tidak harus melakukan itu. Tetapi jika Anda tidak maka masalah muncul; masalah yang selalu ada. Namun sekarang, programmer memiliki pengalaman yang cukup untuk mengidentifikasi masalah-masalah itu dan menyediakan mekanisme untuk mengatasinya (jika diperlukan). Kami belajar lebih banyak tentang itu, dan menghasilkan solusi yang lebih baik (lihat - pandangan programmer tentang singleton misalnya).

Tetapi Anda juga harus menyadari bahwa memperkenalkan programmer ke OO (atau apa pun dalam hal ini) akan cenderung menutupi keadaan luar biasa. Lebih mudah untuk menjelaskan jalan bahagia, dan khawatir tentang sisanya setelah pemula memilikinya. Tidak ada peluru perak; jadi ya, saya kira segala sesuatu akan selalu tampak lebih sulit ketika delusi indah itu rusak ...


3

Contoh "intro to OO" jauh lebih sederhana daripada aplikasi dunia nyata. Anda hanya perlu satu kelas untuk mencapai hal di atas. Masalahnya adalah itu tidak berbuat banyak. Beberapa pola desain mencoba mendekati (seperti ActiveRecord.) Tetapi pada akhirnya, setiap contoh yang tidak sepele akan memiliki lebih dari satu kelas; itu tidak apa-apa.


Perhatikan juga bahwa kerangka kerja terbentuk dari waktu ke waktu. Jadi ya, pemrograman memang membutuhkan lebih banyak pengetahuan. Ini juga berarti seseorang dapat melakukan lebih banyak dalam waktu yang lebih singkat.
Jeanne Boyarsky

3

Bahasa pemrograman menggunakan OO saat ini berusaha untuk memenuhi persyaratan dan lingkungan yang kompleks yang terus berubah. OO memungkinkan pengadopsi untuk menyembunyikan berbagai tingkat kompleksitas (di antara fitur-fitur lainnya) sehingga pengkodean menjadi lebih jelas dan lebih mudah untuk dibangun dan dipahami. Namun, fitur ini tidak selalu out of the box. Dalam contoh Anda, OO telah memungkinkan Anda untuk menyembunyikan beberapa detail dari saya dengan menyediakan metode untuk mengelola item dalam koleksi dan mungkin bahkan untuk bertahan dengan menggunakan metode "AddItem". Upaya pengeluaran dalam menyembunyikan kompleksitas dapat menghasilkan kerangka kerja yang mudah digunakan dan digunakan kembali yang membuat hidup lebih sederhana. Sebagai contoh, Banyak implementasi ORM memungkinkan Anda untuk berkomunikasi dengan database tanpa meminta programmer menulis rincian SQL. Ini memang kuat dan membuatnya lebih sederhana pada pengembang.

Pola yang Anda rujuk hanyalah itu. Mereka seharusnya membuat hidup Anda lebih mudah. Tetapi terserah Anda untuk mengadopsi dan menyesuaikannya. Fakta bahwa dibutuhkan lebih banyak pekerjaan hanya karena Anda memperoleh lebih banyak manfaat. Ini seperti membayar lebih untuk Ferrari. Jika Anda ingin ekstra, Anda membayarnya. Jadi, jika Anda memutuskan untuk membangun solusi N-Tier yang dapat diukur yang dapat dijalankan pada beberapa server dan database back-end yang berbeda, ada biaya untuk itu. Jika aplikasi Anda tidak memerlukan kompleksitas ini, abaikan potongan ekstra dan kembali ke solusi paling sederhana yang memenuhi kebutuhan Anda (KISS & YAGNI).

Jadi, untuk menyelesaikannya, saya tidak berpikir bahwa OOP sebagai konsep itu sendiri semakin kompleks, kami, para pengguna OOP memiliki pilihan untuk menggunakannya dengan cara yang berbeda, dan itu adalah hal yang baik.


Hapus poin. Saya tahu YAGNI. Apa itu KISS?
tunmise fasipe

2
@tunmisefasipe, KISS adalah nama pendek untuk prinsip desain. Kata aslinya adalah "Keep It Simple (Stupid)" (ref: en.wikipedia.org/wiki/KISS_principle ) tetapi frasa yang lebih sopan adalah "Keep It So Simple".
NoChance

3
@tunmisefasipe - KISS = Keep It Simple, Stupid. Sebuah frasa yang saya ulangi untuk diri sendiri TERLALU, dan TERLALU, dan TERLALU, dan sepertinya itu tidak selalu meresap.
Michael Kohne

@MichaelKohne, kita semua lakukan! Saya kira itu adalah seni untuk dapat menyederhanakan banyak hal. E = M C C mengatakan semuanya dalam bentuk yang sangat ringkas!
NoChance

3

Jawaban Singkat : Ya, karena Anda menangani masalah yang lebih sulit.

Jawaban Panjang (sangat bias) : Bagi saya pola desain biasanya menunjukkan bahwa beberapa paradigma memiliki masalah di area tertentu. Pola OOP menangani masalah OOP (pada tingkat yang lebih rendah pola Jawa menangani masalah Jawa), pola FP menangani masalah FP dll.

Selama pemrograman Anda mungkin memiliki prioritas yang berbeda. Anda mungkin ingin memiliki program yang benar, Anda mungkin ingin memiliki waktu singkat ke pasar, program tercepat, perawatan jangka panjang atau perawatan instan oleh karyawan baru. Bergantung pada semak-semak Anda berada di dalam, Anda akan memiliki perbedaan yang sangat besar - jika Anda memprogram pengontrol pembangkit listrik, Anda ingin melakukannya dengan benar pertama kali dan tidak memperbaiki bug setiap saat ("Apakah kehancuran terjadi setiap kali Anda menekan Ctrl+Alt+Del?"). Jika Anda berada di HPC, logikanya bisa relatif sederhana tetapi Anda ingin mengeksekusinya secepat mungkin, dll. Dll. Selain itu beberapa paradigma lebih cocok dengan masalah tertentu (misalnya pemrograman AI dan logika, data, dan basis data relasional).

OOP adalah untuk beberapa memperpanjang 'terlalu bagus' dalam kasus-kasus sederhana dan itu "memodelkan kisah nyata". Misalnya dalam buku pertama tentang OOP saya baca ada kelas Person, Employeedan Managerdengan is-ahubungan. Sejauh ini bagus tapi bagaimana jika karyawan dipromosikan menjadi manajer?

Di sisi lain, paradigma lain memiliki pelajaran pertama yang lebih sulit - misalnya FP dengan variabel yang tidak berubah (lucunya orang yang memiliki pengalaman dengan pemrograman sering merasa lebih sulit untuk belajar daripada mereka yang menggunakan bahasa ini) - namun pada akhirnya mereka adalah tidak lebih keras dari OOP. Menguji fungsi murni sepele dan di Haskell / Scala / ... Anda memiliki alat yang menghasilkan tes untuk Anda.

PS. Ya - jawabannya bias terhadap OOP dan saya akui bahwa untuk beberapa hal itu merupakan 'reaksi' terhadap OOP. OOP memiliki kegunaannya tetapi itu bukan satu-satunya, solusi utama menurut saya.

PPS. Ya - gunakan pola desain - mereka membuat pemrograman OOP pada akhirnya lebih sederhana.

PPPS. Saya menggunakan OOP sebagai sinonim dari pemrograman imperatif OOP.


2

Saya pikir ini lebih merupakan kasus dokumen dan contoh menjadi lebih realistis.

Buku-buku OOP awal (khususnya buku-buku Jawa awal) menyajikan pandangan pemrograman aplikasi yang disederhanakan secara tidak masuk akal. Contoh "Debit rekening bank dengan 10 program Java" selalu sangat menyebalkan karena saya telah melihat contoh nyata dari tugas sederhana ini berjalan ke 6000 baris kode COBOL (dan upaya penggantian Java berjalan ke 3500 baris sebelum ditinggalkan) tidak layak!).

Untungnya, buku-buku OO sekarang cenderung mengakui kompleksitas kehidupan nyata, dan, memberikan contoh-contoh berguna tentang cara menghadapinya.

Tetapi jika Anda ingin melihat cara menjalankan rekening bank hanya dalam 15 baris pemrograman fungsional kode adalah orang Anda

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.