Edit:
Untuk menghindari kebingungan lebih lanjut: Saya tidak berbicara tentang layanan web dan semacamnya. Saya berbicara tentang penataan aplikasi secara internal, ini bukan tentang bagaimana komputer berkomunikasi. Ini tentang bahasa pemrograman, kompiler dan bagaimana paradigma pemrograman imperatif diperluas.
Asli:
Di bidang pemrograman imperatif, kami melihat dua paradigma dalam 20 tahun terakhir (atau lebih): berorientasi objek (OO), dan berorientasi layanan (SO) alias. berbasis komponen (CB).
Kedua paradigma memperluas paradigma pemrograman imperatif dengan memperkenalkan gagasan mereka sendiri tentang modul. OO memanggil mereka objek (dan kelas) dan memungkinkan mereka merangkum data (bidang) dan prosedur (metode) secara bersamaan. JADI, sebaliknya, memisahkan data (catatan, kacang, ...) dari kode (komponen, layanan).
Namun, hanya OO yang memiliki bahasa pemrograman yang mendukung paradigma tersebut: Smalltalk, C ++, Java dan semua yang kompatibel dengan JVM lainnya, C # dan semua yang lainnya .NET-compatibles, Python dll.
SO tidak memiliki bahasa ibu seperti itu. Ini hanya muncul di atas bahasa prosedural atau bahasa OO: COM / DCOM (biner, C, C ++), CORBA, EJB, Spring, Guice (semua Java), ...
Kerangka kerja SO ini jelas menderita dari dukungan bahasa asli yang hilang dari konsep mereka.
- Mereka mulai menggunakan kelas OO untuk mewakili layanan dan catatan. Ini mengarah ke desain di mana ada perbedaan yang jelas antara kelas yang hanya memiliki metode (layanan) dan yang memiliki bidang saja (catatan). Warisan antara layanan atau catatan kemudian disimulasikan oleh pewarisan kelas. Secara teknis, ini tidak dijaga dengan ketat tetapi pada umumnya programmer disarankan untuk membuat kelas untuk memainkan hanya satu dari dua peran.
- Mereka menggunakan bahasa eksternal tambahan untuk mewakili bagian yang hilang: IDL, konfigurasi XML, Anotasi dalam kode Java, atau bahkan DSL yang disematkan seperti di Guice. Ini sangat diperlukan, tetapi tidak terbatas pada, karena komposisi layanan bukan bagian dari kode layanan itu sendiri. Dalam OO, objek membuat objek lain sehingga tidak perlu untuk fasilitas seperti itu tetapi untuk SO ada karena layanan tidak instantiate atau mengkonfigurasi layanan lain.
- Mereka membangun efek platform dalam di atas OO (EJB awal, CORBA) di mana programmer harus menulis semua kode yang diperlukan untuk "mendorong" SO. Kelas hanya mewakili sebagian dari sifat layanan dan banyak kelas harus ditulis untuk membentuk layanan bersama. Semua pelat ketel itu diperlukan karena tidak ada SO kompiler yang akan melakukannya untuk programmer. Ini seperti beberapa orang melakukannya dalam C untuk OO ketika tidak ada C ++. Anda hanya meneruskan catatan yang menyimpan data objek sebagai parameter pertama ke prosedur yang merupakan metode. Dalam bahasa OO parameter ini implisit dan kompiler menghasilkan semua kode yang kita butuhkan untuk fungsi virtual dll. Untuk SO, ini jelas hilang.
- Terutama kerangka kerja yang lebih baru secara ekstensif menggunakan AOP atau introspeksi untuk menambahkan bagian yang hilang ke bahasa OO. Ini tidak membawa ekspresi bahasa yang diperlukan tetapi menghindari kode platform boiler yang dijelaskan pada poin sebelumnya.
- Beberapa kerangka kerja menggunakan pembuatan kode untuk menghasilkan kode pelat ketel. File konfigurasi dalam XML atau anotasi dalam kode OO adalah sumber informasi untuk ini.
Tidak semua fenomena yang saya sebutkan di atas dapat dikaitkan dengan SO tetapi saya harap itu jelas menunjukkan bahwa ada kebutuhan untuk bahasa SO. Karena paradigma ini sangat populer: mengapa tidak ada? Atau mungkin ada beberapa yang akademis tetapi setidaknya industri tidak menggunakannya.