Berapa tergantung arsitektur perangkat lunak pada bahasa?

14

Saat mendidik diri sendiri tentang arsitektur perangkat lunak dan pola desain, saya perhatikan bahwa dalam kebanyakan kasus, beberapa fitur bahasa dan spesifikasi desain tersirat dalam penjelasan.

Misalnya hampir semua artikel atau buku tentang itu akan menggambarkan ide-ide menggunakan kelas dan antarmuka. Segala sesuatu yang dapat dengan mudah ditemukan pada topik ini akan menyebutkan objek dan konsep OOP.

Bagaimana jika bahasa, di mana sistem ditulis tidak memiliki konsep seperti itu sama sekali? Misalnya bagaimana jika saya menggunakan Python atau Node, yang diketik secara dinamis dan tidak memiliki gagasan tentang antarmuka? Bagaimana jika saya menggunakan TypeScript di mana antarmuka adalah konstruksi singkat, yang tidak ada di runtime? Bagaimana jika saya mencoba merangkul pemrograman fungsional? Haruskah saya mengabaikan misalnya SOLID dan mencari konsep lain, cocok untuk bahasa saya?

Jika ya, apa itu? Sayangnya semua paradigma yang diadopsi dengan baik (sejauh yang saya ketahui) merujuk pada konsep dan tipe OOP dalam beberapa cara. Jika tidak, aturan mana yang harus saya ikuti ketika mengadaptasi arsitektur umum dan prinsip-prinsip desain dengan bahasa khusus saya dan case use

Bagaimana secara umum Anda menggambarkan ketergantungan antara arsitektur dan bahasa?

Tristan Tzara
sumber
Saya menulis sebuah artikel tentang arsitektur perangkat lunak: Mengelola kompleksitas perangkat lunak linkedin.com/pulse/…
overexchange
Pertama, ya, arsitektur perangkat lunak didorong berdasarkan teknologi yang Anda miliki. Sebagai contoh: python tidak memanfaatkan multithreading sampai utas-utas itu terikat IO. Ini adalah batasan nyata dalam menggunakan operasi cpu multi-core. Kedua, Anda harus mendengarkan ini ... youtu.be/FF-tKLISfPE Ketiga, Anda harus menganalisis / bekerja pada produk-produk perusahaan terdistribusi stabil yang ada dari domain spesifik yang disebarkan secara scalably, setidaknya 5-6 tahun. Ini adalah pemahaman organik tentang bagaimana teknologi mempengaruhi desain. Btw..produk seperti itu ditulis di dunia pra-java, dari awal.
overexchange
Teknologi wrt ... Di dunia Java, sampai desain bahasa java 5/6/7 mengendalikan para pendiri yang sebenarnya. Dari java 8, saya akan mempertimbangkan java sebagai mesin propaganda tetapi bukan sebagai bahasa pemrograman. Menurut pendapat saya, java telah menjadi teknologi manajer proyek. Jadi, sebagai pemula, saya akan menganalisis / mengerjakan suatu produk yang ditulis menggunakan C / C ++ / Python
overexchange
Tolong jangan gunakan arsitektur kata dalam pertanyaan Anda, itu membingungkan. Pertanyaan Anda adalah tentang desain. Pilihan bahasa biasanya akan memenuhi syarat sebagai arsitektur, pertanyaan Anda tidak masuk akal seperti yang dikatakan ..
Martin Maat
Juga python dan javascript tidak memiliki antarmuka, mereka hanya tidak menggunakan kata kunci yang terpisah untuk membatasi mereka
Caleth

Jawaban:

11

Arsitektur perangkat lunak sangat mirip dengan arsitektur rumah atau jembatan. Sebuah jembatan harus menahan beratnya sendiri dan kendaraan yang melewatinya atau orang-orang yang berjalan di atasnya. Itu harus tahan terhadap cuaca. Bahan yang Anda gunakan untuk membuatnya harus kuat dan relatif ringan.

Ada banyak bahan yang bisa Anda gunakan untuk membangun rumah. Anda bisa menggunakan batu bata atau plesteran. Anda bisa menggunakan balok kayu atau logam. Setiap bahan memiliki karakteristiknya sendiri, dalam hal berat, kekuatan, dan sebagainya. Semua karakteristik ini mempengaruhi arsitektur.

Dengan cara yang sama, bahasa pemrograman yang Anda gunakan memengaruhi cara Anda membangun arsitektur Anda. Arsitektur Anda akan terlihat berbeda dalam bahasa pemrograman yang memiliki kelas seperti C ++ daripada di bahasa pemrograman yang tidak, seperti C.

Prinsip SOLID sebagian besar tentang bahasa berorientasi objek (yaitu bahasa yang memiliki kelas).

Robert Harvey
sumber
4

Arsitektur tergantung pada kemampuan untuk memenuhi tujuannya. Pilihan bahasa dapat membatasi kemampuan. Bahasa lengkap Turing apa pun memiliki kemampuan untuk menyelesaikan tugas pemrograman apa pun. Setelah titik itu tentang bagaimana manusia dapat membaca bahasa memungkinkan solusinya.

Banyak skema arsitektur perangkat lunak meminta Anda untuk menghapus semua pengetahuan tentang pilihan teknologi dari aturan bisnis domain inti. Satu-satunya pilihan teknis yang Anda tidak pernah bisa menghapus pengetahuan dari inti adalah bahasa yang Anda pilih untuk mengekspresikannya.

Ketika buku-buku tentang Arsitektur terus bercerita tentang tujuan mereka, bahasa tidak masalah asalkan mampu mencapai tujuan. Ketika buku-buku memberi tahu Anda bagaimana mencapai tujuan-tujuan ini, bahasa tersebut mulai berkembang.

candied_orange
sumber
Poin bagus dalam jawaban Anda, tetapi saya yakin, secara historis arsitektur perangkat lunak diimplementasikan dengan teknologi dalam tren.
pertukaran berlebihan
@Exex bertukar titik arsitektur yang baik adalah untuk menghasilkan perangkat lunak yang dapat bertahan lebih lama dari tren saat ini dengan siap untuk yang berikutnya.
candied_orange
Setidaknya di dunia middleware, arsitektur produk tidak dapat berpikir melampaui RPC / RMI / CORBA hingga tahun 1990-an. Saya melihat desain klasik mengandalkan panggilan remore berorientasi prosedur. Kemudian ServiceOArch mengubah tren middleware, dalam hal arsitektur.
overexchange
2
@CandiedOrange itulah teorinya. Dalam praktiknya, saya telah melihat banyak orang melakukan apa yang kadang-kadang disebut "pengembangan didorong oleh sensasi" - lakukan saja apa yang paling banyak dibicarakan oleh lingkaran teman sebaya mereka pada saat Desain sehingga Anda dapat berpartisipasi dalam pembicaraan itu.
marstato
@marstato Setuju. Contoh terbaiknya adalah, menggunakan Spring / Springboot dalam tren saat ini, untuk setiap proyek baru, tanpa mengetahui, mengapa?
pertukaran berlebihan
1

Arsitektur sebagai sebuah istilah memiliki makna yang sangat spesifik yang sangat terkait dengan arsitektur di dunia fisik dan pada intinya adalah tentang seni dan praktik membangun sesuatu, tentang bagaimana segala sesuatu dibuat dan disatukan. Diambil seperti itu, ketika arsitektur dilakukan dengan baik, saya pikir bahasanya sangat terikat bersama dengan arsitektur, seperti halnya bangunan yang dirancang dengan baik harus secara intim diinformasikan oleh materi dari mana ia dibangun.

Dalam perangkat lunak, pilihan arsitektur harus dibuat dengan cara yang sesuai dengan sifat-sifat bahasa. Jika Anda membangun sistem dengan bahasa yang berorientasi objek, maka saya berharap arsitektur sistem juga berorientasi objek. Jika Anda membangun sistem dengan bahasa fungsional maka saya berharap arsitektur sistem itu juga berfungsi.

Masuk akal?

RibaldEddie
sumber
Terimakasih atas tanggapan Anda! kebetulan Anda mengetahui sumber daya apa pun, menguraikan arsitektur perangkat lunak terkait dengan bahasa yang diketik secara dinamis atau fungsional? tbh semua yang saya lihat berfungsi untuk Java langsung dari kotak tetapi akan memerlukan beberapa adaptasi untuk misalnya js. yang merupakan pedoman yang memungkinkan untuk mengadaptasi pola arsitektur umum ke bahasa yang diketik dengan lemah? haruskah seseorang mencobanya atau haruskah hal itu sepenuhnya berbeda?
Tristan Tzara
kekhawatiran saya adalah bahwa jika seseorang menggunakan misal Java, maka ada banyak praktik dan pola terbaik untuk arsitektur, tetapi saya belum melihat adanya bahasa yang berbeda jenis. jadi saya bertanya-tanya, bagaimana cara merawatnya
Tristan Tzara
pada dasarnya, apakah eg SOLID masih berdiri dalam kasus seperti itu? bagaimana cara mengadaptasinya jika ya? apa yang harus dilakukan jika tidak?
Tristan Tzara
Prinsip SOLID sangat berorientasi pada objek. Namun saya pikir mereka menyandikan prinsip tingkat tinggi yang mungkin berlaku untuk sistem perangkat lunak apa pun terlepas dari bahasa. Tetapi prinsip-prinsip dasar adalah persis seperti itu: Anda harus tahu dan memahaminya sebelum membangun banyak di luar makanan burung.
RibaldEddie
@TristanTzara Pemrograman berorientasi objek ditemukan sebelum, dan tanpa, bahasa berorientasi objek apa pun. Anda dapat melakukannya dalam bahasa tujuan umum apa pun. Bahkan mereka yang tidak memiliki kelas.
candied_orange
1

Saya akan mengatakan, untuk memulai, bahwa bahkan bahasa yang Anda pikirkan memiliki pengaruh mendalam pada apa yang dapat Anda bayangkan. Ada alasan PASCAL diciptakan oleh Niklaus Wirth dan C oleh Brian Kernighan dan Dennis Ritchie.

Pada level yang lebih tinggi, kemampuan untuk mengekspresikan konsep tertentu (dan kurangnya konsep lain) akan mengarahkan pemikiran Anda dan membuat Anda sampai pada solusi tertentu yang tidak harus sama dengan orang lain, dengan latar belakang yang berbeda, akan muncul.

Akhirnya, konsep yang Anda sebutkan dapat diimplementasikan dalam bahasa tujuan umum apa pun. Hanya saja mereka mungkin tidak memiliki dukungan sintaksis di dalamnya dan implementasinya mungkin rumit. Anda dapat menulis kode rakitan berorientasi objek x86 jika Anda memiliki komitmen yang cukup (atau cukup gila) seperti yang Anda bisa dengan C. Sebenarnya, implementasi pertama C ++ adalah preprosesor yang mengkompilasi kode C ++ Anda menjadi C (dan nama simbol yang dibuat acak dibuat debugging jauh lebih menyenangkan).

kasar
sumber