“Terlalu berorientasi objek”


21

Saya berasal dari latar belakang OO yang kuat, dan saya baru-baru ini mulai bekerja di sebuah organisasi yang, walaupun kode ini ditulis di Jawa, memiliki penekanan yang jauh lebih sedikit pada desain OO yang baik daripada apa yang biasa saya lakukan. Saya telah diberitahu bahwa saya memperkenalkan "terlalu banyak abstraksi", dan bahwa saya harus mengkode cara yang selalu dilakukan, yang merupakan gaya prosedural di Jawa.

TDD juga tidak banyak dipraktekkan di sini, tetapi saya ingin memiliki kode yang dapat diuji. Mengubur logika bisnis dalam metode privat statis dalam "kelas-Tuhan" yang besar (yang tampaknya menjadi norma untuk tim ini) tidak terlalu dapat diuji.

Saya berjuang dengan jelas dalam mengkomunikasikan motivasi saya kepada rekan kerja saya. Adakah yang punya saran tentang bagaimana saya bisa meyakinkan rekan kerja saya bahwa menggunakan OO dan TDD mengarah ke kode yang lebih mudah dikelola?

Pertanyaan tentang hutang teknis ini terkait dengan pertanyaan saya. Namun, saya mencoba untuk menghindari timbulnya hutang di tempat pertama, sebagai lawan dari membayarnya setelah fakta yang meliputi pertanyaan lain.


17
Apa peranmu Pengembang kasar? Anda kacau - dapatkan pekerjaan yang lebih baik. Pengembang Pimpinan? Anda mungkin dapat membuat perbedaan ...
Matthew Flynn

2
Tidak terlalu banyak utang teknologi, seperti berurusan dengan desain yang buruk dan orang-orang yang tidak akan berubah
ozz

1
Saya mengetahui argumen teknis dan bisnis, saya bertanya bagaimana cara terbaik untuk menyampaikan pengetahuan ini kepada rekan kerja saya yang tampaknya tidak menyadari hal ini. Mereka melihat banyak kelas, saya melihat sistem yang dapat diuji dan dapat
dikembangkan

5
Maaf, kamu harus pergi. Anda berbicara di atas kepala kolega Anda. Itu tidak akan berubah sampai proyek menjadi tidak dapat dipelihara. Jika Anda tidak menyukai pengujian manual dan pawai kematian, lebih baik Anda pergi ke tempat lain.
kevin cline

4
Tanpa melihat kode yang dipermasalahkan (ya, sulit untuk memberikan sampel yang cukup baik, jadi kami hanya perlu memercayai penilaian Anda di sini), sulit untuk mengetahui apakah memang ada kekurangan OO, atau jika Anda mendorong kultus kargo rekayasa berlebihan OO abtractions tanpa alasan yang bagus. Saya pikir semua orang telah melihat contoh OOP over-engineered, di mana abstraksi bersandar pada lapisan pabrik abstrak yang memproduksi pabrik abstrak, dll.
Kromster mengatakan mendukung Monica

Jawaban:


32

Anda tidak mengeluh bahwa itu tidak dapat dipelihara, hanya saja tidak sesuai dengan keinginan Anda. Jika itu adalah pilihan gaya yang disengaja, itu mungkin hanya kasus perbedaan kreatif yang tidak dapat didamaikan, dan Anda harus menyesuaikan gaya Anda agar sesuai, atau menemukan tempat yang sesuai dengan gaya pilihan Anda.

Orang dapat dan memang menulis kode modular, efisien, abstrak, relatif bebas bug dalam gaya prosedural sepanjang waktu. Java adalah pilihan bahasa yang aneh untuk toko seperti itu, tetapi saya dapat melihatnya terjadi jika faktor eksternal memutuskan bahasa tersebut, seperti perlu dikembangkan untuk Android, misalnya.

Semua orang jenius. Tetapi jika Anda menilai seekor ikan dengan kemampuannya memanjat pohon, ia akan hidup seumur hidup dengan percaya bahwa itu bodoh. - Albert Einstein

Jika itu pilihan yang disengaja, Anda tidak bisa benar-benar menilai mereka dengan seberapa baik mereka mematuhi prinsip-prinsip desain berorientasi objek yang baik, Anda harus menilai dengan seberapa baik mereka mematuhi prinsip-prinsip desain prosedural yang baik, dan juga refactor sesuai. Java tidak membiarkan Anda menulis kode di luar kelas, jadi keberadaan satu saja tidak berarti mereka menginginkan modul berorientasi objek.

Di sisi lain, jika kodenya berantakan di kedua paradigma, Anda mungkin harus memotong kerugian Anda.


3
itu prosedural dan berantakan. Tapi saya berbicara tentang kode baru yang saya tulis disebut "terlalu berorientasi objek"
ThuneGrill

5
Kode prosedural yang berantakan diperpanjang dengan kode OO mungkin tidak menjadi perbaikan setelah semua, hanya menambah kebingungan.
wirrbel

7
@ThuneGrill, Kau berasumsi mereka memilih gaya mereka coding dari ketidaktahuan desain berorientasi objek, bahwa jika Anda hanya bisa mendidik mereka, mereka akan melihat cahaya. Jika seseorang dengan perangkat lunak bisnis yang menguntungkan dalam bahasa sangat berorientasi objek belum melihat ke manfaat OOD sekarang, tidak ada cara "orang baru" akan meyakinkan dia. Ambil kata saya untuk itu dan kata komentator lainnya. Jika Anda tidak dapat atau tidak akan menyesuaikan gaya Anda untuk memudahkan tim membaca, Anda harus mengurangi kerugian Anda.
Karl Bielefeldt

3
@ThuneGrill: Karl benar. Tetap pada alasan pragmatis, bukan alasan agama. OOP jelas merupakan ide yang bagus, tetapi saya telah melihatnya membawa ke ekstrem yang konyol. Hasilnya adalah membuat gunung dari tanah. Hal-hal yang dapat dilakukan dalam 1000 baris kode akhirnya menjadi 10.000 baris kode dengan kelas berlimpah. Kemudian, Wah, sulit untuk mempertahankan, dan kinerjanya payah. (Tidak peduli apa kelas koleksi digunakan.)
Mike Dunlavey

1
Saya tidak perlu menyerah pada gagasan bahwa Anda dapat meyakinkan orang tentang hal ini. Ini sulit, tetapi bisa dilakukan - saya telah melakukannya. Karena pertanyaan ini tampaknya tertutup, lihat workplace.stackexchange.com/questions/9703/…
Amy Blankenship

7

Membaca pertanyaan Anda, saya ingat satu ujung buku Program Pragmatis.

Salah satu tipsnya adalah Be a Catalyst for Change:

Anda mungkin berada dalam situasi di mana Anda tahu persis apa yang perlu dilakukan dan bagaimana melakukannya. Seluruh sistem hanya muncul di depan mata Anda — Anda tahu itu benar. Tetapi minta izin untuk mengatasi semuanya dan Anda akan menemui penundaan dan tatapan kosong. Orang akan membentuk komite, anggaran akan membutuhkan persetujuan, dan segala sesuatunya akan menjadi rumit. Setiap orang akan menjaga sumber daya mereka sendiri. Kadang-kadang ini disebut "kelelahan awal."

Saatnya memasak Sup Batu. Cari tahu apa yang bisa Anda minta secara wajar. Kembangkan dengan baik. Setelah Anda mendapatkannya, perlihatkan kepada orang-orang, dan biarkan mereka kagum. Lalu katakan "tentu saja, akan lebih baik jika kita menambahkan ...." Berpura-pura itu tidak penting. Duduk dan tunggu mereka mulai meminta Anda untuk menambahkan fungsionalitas yang Anda inginkan. Orang-orang merasa lebih mudah untuk bergabung dengan kesuksesan yang berkelanjutan. Perlihatkan kepada mereka sekilas masa depan dan Anda akan membuat mereka berkumpul.

Jadi, saya pikir Jika Anda mulai melakukan pekerjaan dengan baik dengan pengetahuan OO dan TDD Anda, segera mereka akan mulai mencari dan bertanya tentang pekerjaan Anda.


Mencoba menjadi, tetapi arsitek-uber (yang tidak kode) tidak akan memilikinya.
ThuneGrill

Begitu dia menyadari manfaat TDD dan OO yang lebih baik (keandalan, produktivitas, ...), Anda akan mendapatkan perhatian Anda!
Rodrigo

3

Untuk menjual cara baru bekerja, Anda harus menunjukkan manfaat yang jelas. Menulis lebih banyak lapisan abstraksi, tanpa manfaat yang jelas tetapi samar: "itu bisa bermanfaat untuk masa depan" tidak akan berhasil.

Buat pabrik tempat pabrik membuat lebih dari satu jenis objek. Gunakan injeksi ketergantungan, yang langsung menunjukkan manfaat. Membuat antarmuka yang sebenarnya akan diimplementasikan oleh lebih dari satu kelas.

Apa yang saya lihat terlalu sering dalam "OO sejati" adalah bahwa teknik-teknik canggih digunakan untuk memecahkan masalah yang sangat sederhana dengan cara yang terlalu rumit.

Bagaimana Anda bisa menunjukkan manfaat pabrik jika hanya akan membuat objek yang sama? Temukan masalah dalam kode Anda yang mendapat manfaat dari teknik-teknik canggih dan menunjukkan poin Anda dan bekerja dari sana.

Perang dimenangkan satu pertempuran pada satu waktu.


1

Anda hanya dapat meyakinkan mereka dengan mengambil sejumlah kecil kode dan menerapkan TDD dan praktik OO yang lebih baik untuk merealisasikan manfaatnya. Anda telah mengarahkan mereka ke tanah yang dijanjikan, bukan hanya menunjukkan kartu pos yang bagus.

Tentu saja, saya pikir ada banyak kasus abstraksi yang digunakan di banyak basis kode saat ini. Hanya memasukkan apa yang Anda butuhkan, dan itu termasuk abstraksi juga.


1
Baru saja, itulah yang menyebabkan seluruh diskusi. Saya hanya memperkenalkan 3-4 abstraksi di atas fungsionalitas yang ada
ThuneGrill
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.