Polimorfisme adalah kemampuan sesuatu untuk muncul dalam berbagai bentuk, tergantung pada

konteks, dan kemampuan hal yang berbeda untuk muncul sama dalam konteks tertentu. Ini adalah dua
sisi lain dari mata uang polimorfik. Sebuah perbaikan terjadi setelah diterima bahwa sesuatu tidak harus
hanya apa yang tampaknya menjadi. Kemudian, eksplorasi dinamis apa yang ada di balik penampilan
statis menjadi mungkin.
Bab ini menyoroti beberapa pada konsekuensi dari atas, agak filosofis, pernyataan. Secara khusus,
gagasan substitusi dijelaskan dan berkaitan dengan konsep jenis dan subtipe. Jenis mengarah pada
gagasan antarmuka dan peran penting mereka untuk komponen. Sebagai komponen secara independen
dikerahkan, itu adalah sangat penting bahwa lingkungan deployment menerima komponen yang
independen memperpanjang lingkungan ini. Paradigma penting diperpanjang independen diperkenalkan
untuk menangkap kebutuhan ini. Pembahasan diperpanjang independen secara alami mengarah ke
pertanyaan keamanan, keselamatan, dan kepercayaan. Bab ini diakhiri dengan diskusi dimensi yang
berbeda diperpanjang independen, aspek evolusi perangkat lunak, dan ringkasan singkat dari beberapa
bentuk lain dari polimorfisme sebelumnya tidak dibahas dalam bab ini.

1,6 substitusi - menggunakan satu untuk yang lain
Antarmuka kontrak yang ditentukan Self-berdiri memisahkan klien dan penyedia. Antarmuka yang sama
dapat digunakan oleh sejumlah besar klien yang berbeda, tetapi juga didukung oleh sejumlah besar
penyedia yang berbeda. Untuk menghindari mengurangi spektrum kemungkinan klien dan penyedia
tidak perlu, sebuah antarmuka harus ditentukan dengan hati-hati. Ini seharusnya tidak memerlukan
terlalu banyak baik dari klien atau provider nya. Namun, jika memerlukan terlalu sedikit dari mereka,
antarmuka hanya sebagai sia-sia.
Jika antarmuka memerlukan terlalu sedikit dari klien - misalnya, tidak ada non-sepele pra-kondisi - dapat
membebani penyedia. Secara khusus, seperti interface akan sulit atau bahkan tidak mungkin untuk
melaksanakan. Selain itu, dapat mungkin untuk mengimplementasikan secara efisien. Di sisi lain, jika
sebuah antarmuka membutuhkan terlalu sedikit dari operator misalnya, tidak ada postconditions non-
sepele - itu tidak ada gunanya untuk klien.
Sebuah antarmuka hati-hati dibuat tidak memerlukan lebih dari sangat penting untuk layanan yang akan
diberikan. Interface seperti biasanya meninggalkan ruang kepala yang signifikan untuk klien dan
penyedia. Secara khusus, klien dan penyedia selalu bebas untuk overfulfill kontrak mereka. Seorang
klien dapat membentuk lebih dari yang dibutuhkan oleh prasyarat atau mengharapkan kurang dari
dijamin oleh postcondition tersebut. Demikian juga, penyedia mungkin memerlukan kurang dari dijamin
oleh prasyarat atau membangun lebih dari yang dibutuhkan oleh postcondition tersebut.
Pra-dan postconditions biasanya ditentukan dengan menggunakan predikat. Gagasan mengharapkan
kurang dari dijamin mengambil bentuk implikasi logis - jaminan menyiratkan harapan. Demikian juga,
implikasi dapat digunakan untuk mengungkapkan bahwa lebih mungkin diberikan dari yang dibutuhkan -
yang disediakan menyiratkan diperlukan. Menggunakan simbol umum untuk implikasi (), di atas dapat
diringkas sebagai:
didirikan oleh klien tertentu
diminta oleh antarmuka (prasyarat)
diperlukan oleh penyedia tertentu
didirikan oleh penyedia tertentu
dijamin oleh antarmuka (postcondition)
diharapkan oleh klien tertentu
Berikut adalah contoh. Pertimbangkan TextModelas antarmuka diperkenalkan dalam Bab 5 (hal. 67).
Bagian yang relevan dari antarmuka diulang di bawah ini.
antarmuka TextModel {
int max (); / / panjang maksimum teks ini dapat memiliki
int length (); / / panjang saat
hangus baca (int pos); / / karakter pada posisi pos
void write (int pos, char ch); ch karakter / / insert pada posisi pos
/ / *Len: int; txt: array dari char
/ / Pre len: = this.length (); (alli: 0 i <len: txt *i+: = this.read (i)):
/ / Len <this.max () and0 pos len
/ / Post this.length () = len + 1
/ / Dan (alli: 0 i <pos: this.read (i) = txt *i+)
/ / Dan this.read (pos) = ch
/ / Dan (alli: pos <i <this.length (): this.read (i) = txt [i - 1])
/ /]
...
}
Perhatikan bagaimana antarmuka membutuhkan penelepon operasi writeto memastikan bahwa
karakter yang akan ditulis dimasukkan dalam kisaran saat ini dari teks. Sebuah implementasi
GreatTextModelmay bersantai ini dengan memungkinkan insersi terjadi melewati akhir teks saat ini,
dengan padding dengan kosong jika diperlukan. Dengan demikian, pelaksanaan penyedia tentang
writemay memiliki prasyarat melemah berikut dan diperkuat postcondition (perubahan ditekankan).
class GreatTextModel mengimplementasikan TextModel {
...
void write (int pos, char ch) {
/ / *Len: int; txt: array dari char
/ / Pre len: = this.length (); (semua i: 0 i <len: txt *i+: = this.read (i));
/ / Len <this.max () dan 0 pos <this.max ()
/ / Post this.length () = max (len, pos) + 1
/ / Dan (semua i: 0 i <min (pos, len): this.read (i) = txt *i+)
/ / Dan this.read (pos) = ch
/ / Dan (semua i: pos <i len: this.read (i) = txt *i - 1])
/ / Dan (semua i: len <i <pos: this.read (i) = "")
/ /]
...
}
...
}
Prasyarat dari TextModel.writedoes antarmuka memang menyiratkan bahwa dari GreatTextModel.write
pelaksanaan:
this.length () <this.max () dan 0 pos this.length ()

this.length () <this.max () dan 0 pos <this.max ()
The postcondition dari GreatTextModel.writedoes pelaksanaan memang menyiratkan bahwa dari
TextModel.write antarmuka, asalkan prasyarat kuat dari interface yang dimiliki. Jika tidak, antarmuka
tidak membuat pernyataan sama sekali tentang kemungkinan postconditions:
(Dari prasyarat:
len: = this.length (); max: = this.max ();
(Alli: 0 i <len: Char *i+: = this.read (i))
)
len <max dan 0 pos max
dan
this.length () = max (len, pos) + 1
dan (alli: 0 i <min (pos, len): this.read (i) = Char *i+)
dan this.read (pos) = ch
dan (alli: pos <i len: this.read (i) = Char *i - 1])
dan (alli: len <i <pos: this.read (i) = "")

this.length () = len + 1
dan (alli: 0 i <pos: this.read (i) = Char *i+)
dan this.read (pos) = ch
dan (alli: pos <i <this.length (): this.read (i) = Char [i - 1])
Dalam kedua kasus, verifikasi implikasi ini sangat mudah dan tersisa sebagai latihan bagi pembaca begitu
ingin. Pembaca lebih memilih untuk tidak pergi ke tingkat detail dapat dengan aman melewati latihan
ini.
Ada, mengejutkan, banyak cara yang mungkin lebih lanjut di mana penyedia dapat menafsirkan kontrak
antarmuka. Sebagai contoh, penyedia dapat menerima posisi sewenang-wenang, termasuk yang negatif,
dalam semua operasi, hanya dengan terlebih dahulu kliping posisi yang ditentukan pada kisaran saat ini
berlaku. Atau, penyedia dapat memutuskan untuk tumbuh teks dinamis, membuat max mengembalikan
nilai non-konstan. Sama, penyedia dapat memutuskan untuk menciptakan ilusi teks panjang tak
terhingga, preinitialized dengan semua kosong.
Jelas, klien berdasarkan kontrak antarmuka tidak akan dapat manfaat dari salah satu perbaikan
pelaksanaan di atas. Namun, implementasi yang sama juga dapat mendukung antarmuka kontrak lain
yang mengungkapkan kemampuan yang lebih umum.
Pada akhir klien dari sebuah antarmuka, jenis yang sama relaksasi adalah mungkin. Seorang klien dapat
menjamin lebih dari yang diperlukan dan mengharapkan kurang dari disediakan. Sebagai contoh, klien
TextModel.writemay menggunakan operasi hanya untuk menambahkan ke teks:
{Text TextModel, int pos, char ch;
...
jika text.length () <text.max () {
text.write (text.length (), ch);
/ / Berharap text.read (text.length () - 1) = ch
}
...
}
Perhatikan bagaimana pra-dan postconditions membuatnya cukup sulit untuk mengungkapkan kondisi
seperti: "jika text.length () <text.max () pada satu waktu, maka ini akan terus memegang selama
text.length () tidak . mengubah "Kondisi seperti ini sangat penting untuk menghindari" kondisi lomba
"dengan pemeriksaan prasyarat - contoh di atas, misalnya, tergantung padanya. Karena pengertian yang
waktu abstrak dan sequencing, sejarah atau-pernyataan berdasarkan teknik spesifikasi yang
diperkenalkan dalam Bab 5 secara alami dapat menutupi detail seperti.
Seperti lagi mudah diverifikasi, kondisi klien mapan, bersama-sama dengan
TextModel.lengthpostcondition tersebut, menyiratkan TextModel.writeprecondition tersebut. Juga,
TextModel.writepostcondition, bersama-sama dengan jaminan klien, menyiratkan harapan klien:
text.length () 0
dan
text.length () <text.max () dan pos = text.length ()

text.length () <text.max () dan 0 pos text.length ()
(Dari prasyarat:
len: = this.length (); max: = this.max ();
(Alli: 0 i <len: Char *i+: = this.read (i))
)
pos = len
dan
text.length () = len + 1
dan (alli: 0 i <pos: text.read (i) = Char [i])
dan text.read (pos) = ch
dan (alli: pos <i <text.length (): text.read (i) = Char [i - 1])

text.read (text.length () -1) = ch
Memahami fleksibilitas diperkenalkan oleh hanya membutuhkan implikasi, bukan ekuivalensi, menjadi
sangat penting ketika mempertimbangkan interaksi dari beberapa penyedia dan klien. Gambar 6.1
menggambarkan peran penting dari kontrak antarmuka ketika mempertimbangkan beberapa klien dan
beberapa penyedia layanan yang diiklankan oleh sebuah antarmuka.
Perpustakaan selalu mendukung konsep katering penyedia layanan untuk banyak klien. Namun, dalam
salah satu konfigurasi yang diberikan, hanya ada satu implementasi dari antarmuka perpustakaan dan
satu-satunya kekhawatiran di sisi penyedia adalah versioning. Seperti dijelaskan di atas, situasi telah
berubah secara dramatis dengan pengenalan interface diri berdiri dan pengiriman dinamis (terlambat
mengikat).
Kapan hukum untuk mengganti satu penyedia layanan untuk orang lain? Sebuah jumlah yang tidak
diketahui klien dapat mengandalkan layanan hanya dengan mengandalkan apa yang dijanjikan oleh
kontrak antarmuka layanan. Oleh karena itu, penyedia layanan lain bisa datang jika memenuhi kontrak
yang sama. Jika penyedia memenuhi kontrak yang sama dengan yang lain, mantan dikatakan
disubstitusikan untuk yang kedua.

6.2 Jenis, subtipe, dan memeriksa jenis
Idealnya, semua kondisi kontrak akan dinyatakan secara eksplisit dan secara resmi sebagai bagian dari
spesifikasi antarmuka. Selain itu, akan sangat diinginkan untuk memiliki compiler atau alat cek klien
otomatis lainnya dan penyedia terhadap kontrak dan menolak yang salah. Dalam prakteknya, yang ideal
ini cukup jauh dari dicapai. Sepenuhnya meresmikan kontrak antarmuka merupakan hambatan besar
pertama. Melakukan hal itu sulit dan sering dianggap terlalu mahal.
Namun, bahkan di mana kontrak formal tersedia, pemeriksaan otomatis tetap menjadi tantangan utama
dari penelitian yang sedang berlangsung. Hal ini diketahui bahwa tujuan umum verifier efisien tidak
layak. Oleh karena itu, penelitian berkonsentrasi pada alat-alat yang menggunakan heuristik untuk
mengotomatisasi sebagian dari proses pembuktian manual. Alat seperti ini disebut provers teorema.
Membuktikan Teorema akan terlalu mahal untuk dilakukan dalam compiler produksi untuk tahun yang
akan datang, dan membutuhkan bantuan manual dengan seorang ahli.
Compiler saat ini tidak dapat memeriksa kondisi yang paling dalam kontrak. Beberapa bahkan tidak
dapat diperiksa secara efisien pada saat runtime. Namun, akan lebih bermanfaat bertujuan untuk
memeriksa kemungkinan untuk menyingkirkan kesalahan berpotensi bencana kesalahan awal. Oleh
karena itu, memeriksa compiler-time lebih baik daripada memeriksa beban-waktu, memeriksa beban
waktu lebih baik dari pemeriksaan runtime, dan memeriksa runtime lebih baik daripada tidak ada
pemeriksaan. Namun, terkadang kemudian memeriksa adalah satu-satunya kemungkinan. Sebagai
contoh, konflik antara versi komponen independen yang disediakan hanya dapat diperiksa pada
konfigurasi atau beban waktu. Demikian juga, kesalahan kisaran indeks bisa, secara umum, hanya dapat
dideteksi pada saat runtime.
Sebuah kelas kesalahan yang dapat menyebabkan hasil yang sangat bencana adalah kesalahan memori.
Sebuah kesalahan memori terjadi ketika sebuah program membaca sel memori didasarkan pada asumsi
yang salah tentang apa sel berisi. Program ini mungkin mengharapkan, katakanlah, sebuah referensi
obyek, sedangkan sel benar-benar berisi baik sesuatu yang berbeda - misalnya, angka floating-point -
atau belum diinisialisasi sama sekali. Kesalahan memori adalah di antara yang terburuk karena mereka
dapat mempengaruhi bagian-bagian yang sama sekali tidak berhubungan dari sebuah program, yang
terkenal sulit untuk melacak, dan dapat sewenang-wenang merusak.
Untungnya, ada cara untuk menangani secara otomatis dengan kondisi-kondisi yang perlu diverifikasi
untuk menghilangkan kesalahan memori. Idenya adalah untuk mengelompokkan semua nilai semantik
terkait, seperti semua bilangan bulat, menjadi set. Set seperti ini disebut tipe. Sebuah sistem tipe
memastikan bahwa semua akses memori jenis kompatibel. Dengan menggabungkan sistem tipe dengan
manajemen memori otomatis dan cek runtime tertentu, implementasi bahasa sepenuhnya dapat
menghilangkan kesalahan memori - dan beberapa kelas kesalahan lain juga. Banyak bahasa modern,
termasuk Smalltalk, Java, C #, Oberon, dan Komponen Pascal, termasuk dalam kategori ini. Namun,
banyak orang lain, termasuk Object Pascal, Modula-2, C, dan C + +, tidak.
Dasar jenis, seperti INTEGER atau, dapat dipahami sebagai set nilai. Dalam konteks objek dan interface,
tipe paling baik dipahami sebagai satu set obyek yang mengimplementasikan antarmuka tertentu.
Jenis nama semua operasi dari sebuah antarmuka dan jumlah dan jenis parameter dan jenis nilai
kembali dari masing-masing operasi. Jenis-jenis input dan in-out parameter merupakan bagian dari
prasyarat operasi itu. Jenis-jenis output dan in-out parameter ditambah jenis nilai yang dikembalikan
merupakan bagian dari postconditions operasi itu. Namun, lain pra-dan postconditions yang mungkin
menjadi bagian dari kontrak yang mendasari bukan bagian dari tipe. Dengan demikian, tipe adalah
sebuah antarmuka dengan kontrak disederhanakan.
Sebagai jenis adalah kontrak disederhanakan, adalah mungkin bahwa sebuah program yang melewati
memeriksa jenis masih melanggar kontrak. Ini adalah poin penting dan dibahas pada bagian 6.5.
Sebuah objek dapat mengimplementasikan lebih dari interface yang diperlukan dalam konteks tertentu.
Ini dapat mengimplementasikan interface tambahan atau versi antarmuka yang diperlukan diperpanjang
dengan operasi tambahan atau keduanya. Misalnya, antarmuka View, TextView, dan
GraphicsViewbelow berada dalam hubungan seperti ekstensi. TextViewand GraphicsVieware kedua
interface yang menerapkan semua operasi di View, tetapi juga menambahkan operasi khusus untuk teks
dan grafis melihat masing-masing. Satu set yang lebih lengkap TextViewoperations telah disajikan dalam
Bab 5 (hal. 69).
antarmuka View {
void close ();
batal mengembalikan (int kiri, int atas, kanan, bawah int int);
}
antarmuka TextView meluas View {
int caretPos ();
kekosongan setCaretPos (int pos);
}
antarmuka GraphicsView meluas View {
int cursorX ();
int sepintas ();
kekosongan setCursorXY (int x, int y);
}
Dalam keadaan apa bisa obyek yang mengimplementasi satu jenis digunakan dalam konteks
mengharapkan jenis lain? Jawabannya berikut langsung dari pembahasan di atas kontrak. Seorang klien
mengharapkan jenis tertentu benar-benar mengharapkan obyek memenuhi kontrak. Dengan demikian,
semua benda memenuhi kontrak bisa digunakan. Pada tingkat jenis, ini mencakup semua jenis
diperpanjang selama pemahaman adalah bahwa objek dari jenis diperpanjang menghormati kontrak
dasar.
Jelas, TextViewobject atau GraphicsViewobject dapat digunakan di mana pun Viewobject diharapkan.
Sebagai set pandangan teks adalah bagian yang tepat dari set pandangan, TextViewis disebut subtipe
View. Demikian juga, GraphicsViewis-jenis sub of View.
Pandangan contoh menunjukkan pembentukan subtipe dengan mendefinisikan antarmuka baru dan
penamaan antarmuka dasar yang akan diperpanjang oleh antarmuka baru. Ini disebut warisan
antarmuka dan merupakan cara yang paling umum untuk membentuk sub-tipe. Cara lain adalah
subtyping struktural, di mana tidak ada antarmuka dasar bernama.
Sebaliknya, operasi yang berulang dan subtipe dikatakan terbentuk jika subset dari operasi bertepatan
dengan operasi yang ditetapkan untuk jenis lain.
Sebuah variabel tipe Viewcan merujuk ke objek dari tipe View, TextView, GraphicsView, atau subtipe
lain. Ini disebut polimorfisme, dan variabel dikatakan dari jenis polimorfik. Karena ada beberapa bentuk
yang berbeda dari polimorfisme, yang satu ini juga disebut subtipe atau inklusi polimorfisme. Nama
terakhir ini mengacu pada masuknya subset di set basis mereka.
Sejauh sistem tipe yang bersangkutan, objek subtipe yang disubstitusikan untuk objek tipe dasar.
Namun, sekali lagi peringatan: seperti jenis menyederhanakan kontrak, sehingga tidak subtipe
polimorfisme menyederhanakan substitusi. Kenyataan bahwa sebuah benda berada dalam hubungan
yang tepat subtipe tidak menjamin bahwa pelaksanaan objek menghormati kontrak dasar, atau, dalam
hal ini, kontrak apapun. Di sisi lain, itu adalah adil untuk mengatakan bahwa jenis dan aturan subtyping
statis dapat mencegah banyak langsung "berbahaya" pelanggaran kontrak.

6.3 Selengkapnya Tentang Subtipe
Jenis-jenis parameter dan nilai kembali dari operasi antarmuka yang merupakan bagian dari pra-dan
postconditions operasi itu. Diskusi "overfulfilling kontrak" oleh penyedia layanan membantu untuk
memahami apa modifikasi hukum untuk jenis operasi antarmuka subtipe mungkin berlaku. (Ini akan
menjadi logis untuk berbicara tentang subkontrak ketika mengacu pada kontrak yang terkait dengan
subtipe. Sayangnya, subkontrak memiliki arti yang sama sekali berbeda dan mapan.)
Perhatikan bahwa bagian ini sebagian besar menyajikan konsekuensi langsung dari apa yang telah
dibahas di atas, tetapi cukup teknis di alam. Hal ini dapat dengan aman dilewati, terutama pada
membaca pertama.
Jenis parameter output dan kembali nilai-nilai merupakan bagian dari postconditions operasi itu.
Provider A dapat membentuk lebih dari yang dibutuhkan oleh kontrak. Oleh karena itu, antarmuka
subtipe dapat menggantikan jenis parameter output dan nilai-nilai kembali dengan sesuatu yang lebih
spesifik - yaitu, dengan subtipe. Dengan kata lain, jenis parameter output dan nilai-nilai kembali dapat
bervariasi dari jenis ke subtipe ketika bergerak dari sebuah antarmuka dari jenis tertentu untuk sebuah
antarmuka dari subtipe dari tipe tersebut. Sebagai jenis parameter output dan kembali nilai-nilai
sehingga dapat bervariasi dalam arah yang sama dengan jenis antarmuka yang berisi, ini disebut
kovarians.
Jenis parameter input merupakan bagian dari prasyarat operasi itu. Provider A mungkin mengharapkan
kurang dari dijamin oleh kontrak. Oleh karena itu, antarmuka subtipe bisa menggantikan jenis
parameter input dengan sesuatu yang lebih umum - supertypes. Dengan kata lain, jenis parameter input
dapat bervariasi dari jenis ke supertypes ketika pergi dari sebuah antarmuka dari jenis tertentu untuk
sebuah antarmuka dari subtipe dari tipe tersebut. Sebagai jenis parameter input sehingga dapat
bervariasi dalam arah yang berlawanan dari jenis interface yang berisi, ini disebut contravariance.
Persyaratan co-dan contravariance dapat digambarkan secara grafis dengan menunjukkan bagaimana
fungsi bisa diganti dengan yang lain apakah itu mencakup yang sama atau domain yang lebih besar dan
jika memiliki sama atau kisaran yang lebih kecil. Gambar 6.2 mengilustrasikan hal ini. Dalam hal domain
dan jangkauan, fungsi g pada gambar dapat digunakan di tempat-tempat fungsi f yang diharapkan.
Akhirnya, jenis in-out parameter secara simultan merupakan bagian dari operasi pra-dan postcondition.
Dari kombinasi argumen untuk jenis pra-dan postconditions dikembangkan di atas, dapat disimpulkan
bahwa jenis in-out parameter tidak dapat bervariasi sama sekali dalam antarmuka subtipe. Fenomena
ini kadang-kadang disebut invarian dari in-out jenis parameter. Jika, di samping operasi, antarmuka juga
diperbolehkan mengandung atribut dimodifikasi, ini juga memiliki jenis invarian.
Berikut adalah contoh. Pertimbangkan untuk menambahkan operasi getModelto antarmuka View.
Dalam kasus tampilan teks model adalah tipe TextModel, dan ini bisa tercermin covariantly
mendefinisikan getModelin TextView. Hal yang sama dapat dilakukan untuk getModelin GraphicsView.
antarmuka View {
... / / Seperti di atas
Model getModel ();
}
antarmuka TextView meluas View {
... / / Seperti di atas
TextModel getModel ();
}
antarmuka GraphicsView meluas View {
... / / Seperti di atas
GraphicsModel getModel ();
}
Hal ini jelas berguna. Klien yang hanya peduli Viewwill mendapatkan Modelwhen generik mereka
meminta model dilihat. Namun, klien yang tahu bahwa mereka berhadapan dengan TextViewobject
akan mendapatkan TextModel a.
GAMBAR 6.2
Selanjutnya, pertimbangkan sebuah operasi setModelused untuk menghubungkan maksud untuk model
tertentu. Jika bagian dari View, setModelwould harus mengambil sebuah objek dari tipe Model.
antarmuka View {
... / / Seperti di atas
kekosongan setModel (Model m); / / apakah ini ide yang baik?
}
Namun, objek TextView membutuhkan objek TextModel sebagai modelnya dan GraphicsViewneeds a
GraphicsModel. Jika perubahan kovarian parameter input aman, setModelcould diubah dalam
TextViewto menerima TextModeland di GraphicsViewto menerima GraphicsModel a.
Menggunakan antarmuka subtipe memungkinkan substitusi objek subtipe untuk objek tipe dasar.
Dengan demikian, pandangan teks harus mengharapkan untuk digunakan dalam konteks yang tahu
hanya tentang antarmuka View. Dalam konteks itu, prasyarat setModelsimply membutuhkan, sejauh
jenis yang bersangkutan, sebuah Modelobject. Jadi, bahkan jika TextViewwere diperbolehkan (salah)
untuk memodifikasi covariantly jenis parameter setModelsinput, itu tidak akan membantu. Yang terbaik
yang bisa terjadi adalah jenis kesalahan pelanggaran dinamis tertangkap.
Beberapa sistem tipe memungkinkan pengenalan typings yang digabungkan dengan hirarki warisan
antarmuka. Dengan kata lain, bagian dari prasyarat operasi dasar adalah bahwa operasi subtipe mungkin
covariantly memodifikasi bagian-bagian tertentu yang biasanya akan jatuh di bawah pembatasan
contravariance. Sistem jenis tersebut harus memperkenalkan pembatasan lain untuk tetap sehat, yaitu,
untuk terus memungkinkan klaim tentang adanya kesalahan tertentu dalam program-program yang
diketik.
Sebagai contoh, untuk memeriksa statis, asli Eiffel tipe sistem (Meyer, 1990) diperlukan analisis global
konservatif seluruh program termasuk semua pustaka yang digunakan. Analisis global ini disebut tipe
sistem-tingkat pemeriksaan, dan itu jelas mengalahkan gagasan pemeriksaan modular (hal. 77). Sebuah
perpustakaan mungkin jenis cek sendiri dan dengan demikian akan dikirimkan ke klien. Kemudian,
kombinasi klien dan kode perpustakaan dapat menyebabkan kesalahan mengetik di perpustakaan. Jenis
kesalahan tersebut tidak langsung disebabkan oleh penambahan kode klien, tetapi sulit untuk
menjelaskan. Memeriksa Modular membutuhkan monotonisitas, yang berarti bahwa jika salah satu
modul ditentukan secara internal jenis yang tepat, maka penambahan modul lain tidak dapat
mempengaruhi hasil ini.
Jenis pencocokan (Bruce et al., 1997) dan sistem tipe Eiffel direvisi (Meyer, 1996) keduanya
memungkinkan untuk jenis modular memeriksa operasi individu tetapi memerlukan mengetik lebih
spesifik variabel. Secara khusus, jenis pencocokan mengharuskan perubahan kovarian dalam posisi
contravariant dapat terjadi hanya dimana variabel diketik dinyatakan sebagai monomorfik - yaitu, tidak
dapat merujuk ke sebuah objek dari subtipe. Demikian pula, revisi Eiffel mengharuskan perubahan
kovarian tersebut hanya dapat terjadi dimana variabel diketik dapat konservatif bertekad untuk menjadi
monomorfik. Sather adalah bahasa lain berorientasi objek yang membutuhkan variabel yang akan
dinyatakan sebagai baik monomorfik atau polimorfik (Szyperski et al, 1994;. Omohundro dan
Stoutamire, 1996).

6.4 Obyek bahasa dan jenis
Beberapa bahasa, seperti Smalltalk, tidak memiliki sistem tipe eksplisit. Dalam beberapa kasus ini,
compiler masih dapat memperoleh jenis dengan pemeriksaan fragmen program yang ketat lokal, seperti
di Smalltalk dialek Strongtalk (Bracha dan Griswold, 1993). Dalam bahasa seperti, menghindari mengetik
eksplisit adalah masalah kenyamanan - ada kurang untuk menulis. Compiler masih dapat memeriksa
mengetik program dan jenis statis keselamatan yang diawetkan. Menambahkan mengetik eksplisit
masih berguna, karena membuat keputusan arsitektur dan desain penting eksplisit.
Dalam kasus lain, termasuk asli Smalltalk, inferensi tipe tidak mungkin tanpa bergantung pada analisis
global dari kode seluruh tubuh (Palsberg dan Schwartzbach, 1991). Ketik memeriksa Smalltalk dan
bahasa serupa sehingga ditangguhkan untuk runtime. Sebagai contoh, Smalltalk ekspresi x insert: 4: 3
mensyaratkan bahwa xrefers variabel saat runtime untuk obyek yang memahami insert pesan: at:.
Namun, dalam kasus umum, ini tidak dapat diverifikasi secara statis. Akibatnya, xmay merujuk pada
runtime untuk obyek yang tidak memahami pesan insert: at:. Setidaknya, ini diperiksa secara dinamis
dan "pesan tidak dipahami" eksepsi dimunculkan pada saat runtime dalam kasus seperti itu.
Bahasa yang lebih modern, seperti Java dan Komponen Pascal, menggunakan sistem tipe eksplisit dan
statis memeriksa program pada waktu kompilasi. Selain itu, mereka memeriksa jenis penyempitan gips
saat runtime. (A penyempitan cor cor di mana programmer menegaskan bahwa variabel jenis tertentu
benar-benar mengacu pada obyek dari sebuah subtipe dari tipe tersebut. Gips menyempit satu set
untuk subset.)
Bagi pembaca yang mengikuti kisah co-/contravariance di atas, adalah menarik bahwa beberapa bahasa
utama mendukung setiap perubahan dalam jenis operasi ketika membentuk subtipe. Dalam C + +,
kovarian tipe kembali diperkenalkan hanya pada awal tahun 1994 (Ellis dan Stroustrup, 1994, p. 421).
Java dan C # masih tidak mendukung perubahan jenis. (The Java 1.0 spesifikasi beta diperbolehkan
untuk kembali nilai-nilai kovarian, sementara tidak spesifikasi alpha maupun akhir 1.0 atau 1.1
spesifikasi tidak.) Seperti C + +, Pascal Component mendukung perubahan kovarian dari nilai kembali,
tetapi tidak ada perubahan atau co-contravariant lainnya.

6.5 Jenis, antarmuka, dan komponen
Beberapa bahasa pemrograman tidak memerlukan programmer untuk menentukan jenis dan, sebagai
gantinya, menyimpulkan jenis yang paling umum yang masih memungkinkan fragmen program untuk
menjadi jenis yang tepat. Tentu saja, pendekatan ini tidak mungkin di mana antarmuka yang berdiri
sendiri. Pada saat penciptaan antarmuka tersebut, mungkin tidak ada implementasi yang tersedia.
Memang, klien dapat diprogram sebelum penyedia pertama mengimplementasikan antarmuka menjadi
tersedia. Untuk menjaga klien dan penyedia independen, antarmuka diri berdiri harus sepenuhnya dan
secara eksplisit diketik untuk mendapatkan keuntungan dari jenis pemeriksaan.
Bahasa pemrograman lain membangun subtipe kompatibilitas antara dua jenis struktural. Asumsikan
bahwa antarmuka dari satu jenis kebetulan berisi semua operasi yang dikandung oleh jenis lain - dan
operasi di dua antarmuka sendiri tepat diketik. Dalam kasus ini, mantan jenis disimpulkan menjadi
subtipe yang terakhir. Seperti, dalam hal ini, subtyping didasarkan pada jenis struktur, ini kadang-kadang
disebut subtyping struktural berbeda dengan menyatakan subtyping. Jelas, dalam situasi di mana semua
jenis disimpulkan, jenis tidak memiliki nama dan subtyping harus didasarkan pada kompatibilitas
struktural.
Saat melihat jenis sebagai kontrak disederhanakan, menjadi jelas bahwa subtyping struktural berbahaya.
Struktur tipe hanya mencakup sebagian dari kontrak - bagian yang dapat dinyatakan dalam sistem tipe
yang digunakan. Jenis bernama mengacu pada kontrak penuh. Jika jenis lain kemudian dianggap sebagai
subtipe dari jenis ini, ia harus menghormati kontrak tipe dasar, selain kontrak sendiri. Sebagai kontrak
penuh hanya disebut, hubungan subtipe yang tepat tidak dapat disimpulkan secara otomatis. Dengan
demikian, seorang programmer harus secara eksplisit menyatakan apakah atau tidak tipe harus
dianggap sebagai subtipe hukum jenis lain. Jika demikian menyatakan, programmer menerima
kewajiban untuk memverifikasi bahwa hubungan subtipe memang dibenarkan.
Banyak artikel (misalnya, Magnusson, 1991) menggambarkan kisah apokrif dari editor grafis yang
menerima semua benda yang terjadi untuk memiliki metode imbang. Sayangnya, program pengguna
gagal mengerikan setelah tidak sengaja memasukkan benda koboi ke dalam editor grafis, yang kemudian
menyebabkan editor untuk redraw semua benda.
Kadang-kadang dikatakan bahwa subtyping struktural disengaja tidak mungkin dalam praktek.
Argumennya adalah bahwa, untuk hal ini terjadi, semua operasi dari tipe dasar, termasuk semua nomor
parameter dan jenis dan tipe mereka kembali, sengaja harus setuju. Untuk antarmuka substansial ini
memang tidak mungkin. Memang, bahkan untuk drawexample di atas, bukan tidak mungkin bahwa
grafis metode objek menarik yang akan dilakukan tanpa parameter apapun - seperti yang mungkin
menjadi kasus untuk metode imbang objek koboi.
Untuk antarmuka kecil, dan ini adalah khas pada akar hierarki subtipe, situasinya berbeda. Cukup sering,
jenis akar tidak memiliki atau hanya beberapa operasi yang sangat dasar. Selain itu, jenis akar cenderung
dirancang dengan mengikuti pola desain umum. Dengan demikian, memang mungkin dan kemungkinan
bahwa subtipe sengaja diturunkan menyebabkan objek dalam posisi di mana mereka, tanpa sadar,
memutuskan kontrak.
Sebagai contoh, jenis dasar untuk antarmuka seperti Eventand Propertyare mungkin kosong. Atau,
mereka mungkin berisi operasi untuk mendapatkan beberapa "pemilik" objek - sumber acara atau
benda yang memiliki properti. Dengan demikian, struktur jenis dasar, katakanlah, Eventand
Propertymay bersamaan. Mendapatkan hubungan sub-tipe dari yang tidak dapat diterima, tentu saja,
sebagai sebuah peristiwa tidak properti dan sebaliknya.
Aspek lain dari komponen dukungan potensi mereka dari beberapa interface. Hal ini kadang-kadang
diperlukan untuk menentukan set yang dibutuhkan interface dan kemudian
menerima komponen yang menyediakan setidaknya ini interface yang diperlukan. Set antarmuka
tersebut kadang-kadang disebut kategori. Sebagai contoh, Microsoft COM IDL telah diperpanjang untuk
mendukung kategori tersebut. Hal ini dapat digunakan untuk mendukung tes one-stop, seperti
memeriksa bahwa komponen menerapkan semua antarmuka diperlukan untuk membuatnya kontrol
ActiveX.
Di Jawa dan C # (dan kebanyakan bahasa CLR-penargetan lainnya), bahkan benda dapat
mengimplementasikan beberapa interface dan interface dapat memperpanjang beberapa interface.
Sebuah contoh akan menjadi penggabungan dua TextViewexamples yang disajikan di atas (hal. 69 dan
89) - antarmuka TextView harus memperpanjang kedua TextObserverand yang Viewinterface. Di Jawa,
ini mungkin. Namun, Java tidak memiliki konsep kategori dan implementasi obyek dari satu set
antarmuka karena itu harus diuji satu per satu. Namun, karena kategori seperti set antarmuka yang
dikenal sebelumnya, mereka dapat dinyatakan sebagai antarmuka kosong yang berasal dari set
antarmuka yang bersangkutan. Pengujian apakah atau tidak sebuah objek mengimplementasikan
kategori tertentu kemudian sebesar memeriksa jika mengimplementasikan antarmuka kategori ini.
Pendekatan ini bekerja hanya jika objek tersebut sudah dilengkapi untuk benar-benar
mengimplementasikan antarmuka kategori daripada hanya menerapkan semua antarmuka individu
yang dibutuhkan oleh kategori. Menggunakan gagasan structuralinterface set dan memeriksa
pencocokan set seperti memecahkan masalah ini. Contohnya adalah Buchi dan jenis senyawa Weck
(1998).

6.6 Paradigma diperpanjang independen
Fungsi utama dari orientasi komponen untuk mendukung diperpanjang independen.
Sebuah sistem independen extensible jika extensible dan jika ekstensi dikembangkan dapat
dikombinasikan (Szyperski, 1996). Sebagai contoh, semua sistem operasi adalah satu-tingkat
independen extensible oleh loading aplikasi.
Namun, banyak aplikasi sendiri berubah menjadi sistem mandiri extensible. Extensions untuk aplikasi
kadang-kadang disebut plugin. Aplikasi, seperti Netscape Navigator atau Internet Explorer, perlahan-
lahan berubah menjadi platform dengan mendukung peningkatan jumlah plugin yang semakin
kompleks. Contoh pertama plugin pendukung "sub-plugin" telah tiba. Salah satu contohnya adalah
Gazelle, sebuah plugin browser yang mendukung download dari Komponen Pascal "applet" yang
mengeksekusi dalam kerangka komponen blackbox lokal (Paznesh, 1997). Java adalah sekarang bagian
dari banyak browser, tetapi di mana itu tidak terjadi, plugin Sun Java Activator adalah contoh lain.
Sebagai aplikasi terfragmentasi dan berubah menjadi arsitektur extensible, sistem operasi tidak berdiri
masih baik. Sebuah desain radikal mengurangi sistem operasi itu sendiri ke kernel minimal, disebut
micro-kernel, dan peternakan hampir semua OS fungsi untuk server aplikasi-tingkat. Micro-kernel
awalnya didorong oleh sistem operasi riset seperti Mach (Accetta et al., 1986) yang dengan sendirinya
tidak pernah benar-benar membuat ke pasar yang lebih umum.
Namun, desain micro-kernel juga dipengaruhi desain sistem operasi kekuatan industri, termasuk
Microsoft Windows NT (Cutler, 1993), yang menyebabkan Windows 2000 dan Windows XP, dan baru-
baru ini Apple Mac OS X (www.apple.com/macosx/ ), yang langsung didasarkan pada Mach.
Menggabungkan "dekernelization" upaya arsitek sistem operasi dan upaya modularisasi arsitek aplikasi
mengarah ke visi baru untuk arsitektur sistem secara keseluruhan - komponen mana-mana! Namun,
tidak hanya tentang mampu membangun setara dengan sistem operasi tradisional yang dikombinasikan
dengan beberapa aplikasi. Ini adalah semua tentang membentuk arsitektur sistem yang independen
extensible pada semua tingkatan. Ini adalah tentang diperpanjang independen sebagai prinsip
konstruksi rekursif diterapkan secara seragam. Sistem tersebut telah dieksplorasi dalam proyek
penelitian (misalnya, sistem Ethos, Szyperski, 1992a) dan juga dalam proyek-proyek industri. Salah satu
pendekatan yang paling ambisius, Taligent, gagal. Untuk memahami mengapa, akan sangat membantu
untuk kembali dulu ke upaya awal untuk mengembangkan desain mikro-kernel untuk sistem operasi.
Partisi sistem menjadi komponen-komponen terkecil (untuk memaksimalkan penggunaan kembali)
bertentangan dengan efisiensi, tetapi juga dengan ketahanan saat menghadapi evolusi dan berbagai
konfigurasi. Hal ini dibahas secara rinci dalam Bab 4. Argumen serupa dengan ketahanan dapat dibuat
untuk kinerja. Arsitektur Micro-kernel memberlakukan isolasi total dari proses aplikasi-tingkat untuk
membentuk mekanisme sistem keselamatan dan dukungan keamanan. Namun, isolasi datang pada
harga, dan penyeberangan sering batas-batas domain perlindungan dapat mempengaruhi kinerja. (Ada
unit manajemen memori yang memisahkan manajemen address space dari domain perlindungan,
misalnya ARM MMU (Furber, 1996). Namun, dukungan hardware untuk banyak domain perlindungan
ringan belum membuatnya menjadi mainstream. Alternatif Software ada (Wahbe et al., 1993), tetapi
belum mendapatkan tingkat kepercayaan yang perintah mekanisme perlindungan hardware.) Pada
akhirnya, untuk sistem operasi untuk menjadi layak, arsitek yang harus berjuang untuk abalance antara
fleksibilitas di satu sisi dan kinerja dan ketahanan di sisi lain.
Setelah gelombang awal euforia, banyak ahli sistem operasi sekarang setuju bahwa ekstrim "micro-
kernelism" bukanlah desain yang optimal untuk sistem operasi. Setelah semua, fleksibilitas dan
konfigurabilitas hanya satu sisi dari karakteristik sebuah sistem operasi. Sisi lain, dan setidaknya sama
pentingnya, adalah pengiriman kinerja sistem secara keseluruhan. Ini adalah kebutuhan kedua yang
secara langsung bertentangan dengan desain mikro-kernel yang ekstrim. Misalnya, dimulai dengan versi
4.0, Microsoft pindah bagian penting dari kode driver display ke dalam kernel NT untuk meningkatkan
secara substansial kinerja grafis-intens aplikasi. Langkah ini, sayangnya, juga memperkenalkan ancaman
besar bagi ketahanan NT - driver layar rusak akan benar-benar membuat poligon di memori kernel.
Dimulai dengan Windows 2000, Microsoft kini menerbitkan test driver suite dan mendorong produsen
driver untuk mendapatkan driver mereka disertifikasi oleh layanan pihak ketiga yang independen.
Otoritas sertifikasi tanda cryptographically driver bersertifikat - driver unsigned status kualitas yang
tidak diketahui adalah, secara default, ditolak oleh Windows (seperti Windows XP).
Bagaimana komponen teknologi dan diperpanjang independen sebagai konsep desain sistem rekursif
pernah menjadi layak jika kinerja begitu sangat terpengaruh? Jawaban atas pertanyaan ini akan tampak
sangat penting bagi masa depan teknologi komponen. Namun dalam kenyataannya, ternyata menjadi
pertanyaan yang salah.
Pertanyaan sebenarnya harus dijawab adalah "Mengapa kinerja begitu parah
terpengaruh? "Jawaban yang jelas adalah" karena mahal untuk melakukan panggilan lintas-con-teks.
"Setiap kali sebuah doa melintasi konteks (proses dan sebagainya), yang
Sistem operasi harus memastikan beberapa hal. Hal ini untuk memastikan bahwa kebijakan keamanan
dihormati - yaitu, memeriksa apakah atau tidak panggilan terjadi di bawah otorisasi yang tepat.
Selanjutnya, ia harus menyesuaikan mekanisme perlindungan hardware dengan beralih dari pemanggil
untuk Callee konteks. Akhirnya, ia harus memastikan bahwa parameter panggilan ditransfer dari
penelpon untuk konteks callee. Setelah disebut fungsi kembali, proses tersebut harus dikembalikan.
Selain biaya pokok tidak dapat dihindari, switch juga mempengaruhi cache prosesor. Pada beberapa
mesin, cache bahkan harus memerah karena alasan keamanan.
Semua ini mahal - panggilan lintas-konteks pada sistem operasi baik-tuned masih mudah seratus kali
lebih mahal daripada panggilan lokal dalam proses. Ini bukan kesalahan sistem operasi. Kebanyakan
arsitektur bergantung pada hardware yang didukung proses isolasi untuk menjamin keamanan. Contoh
dari hal ini adalah melindungi proses di hadapan lain proses out-of-control yang mencoba untuk menulis
ke alamat memori sewenang-wenang. Mengingat benar "disegel" sistem operasi dan setup yang tepat
otorisasi, bahkan program jahat sakit-terbentuk ditulis langsung dalam bahasa assembly mesin tidak
dapat membahayakan program lain mengeksekusi pada mesin yang sama.
Biaya perlindungan hardware tinggi tetapi dapat ditoleransi jika switching dapat dibatasi, misalnya,
beberapa ratus switch per detik. Ini adalah kasus di bawah operasi time-sharing normal dari sistem
operasi tradisional. Dalam hal ini, komunikasi antar-proses (IPC) biasanya didasarkan pada pipelining
data stream yang memisahkan sumber dan tujuan dan mengurangi frekuensi switching konteks. Jelas,
untuk erat berinteraksi komponen, "komunikasi intercomponent" terjadi pada frekuensi yang lebih
tinggi dan jauh lebih sinkron - komponen sumber sering harus menunggu hasilnya sebelum dapat
melanjutkan.
Pada mesin dibangun untuk penggunaan interaktif dan terbuat dari barang-barang komoditas murah,
disebut komputer pribadi, ini telah lama menyebabkan pemanfaatan sistem operasi yang agak berbeda.
Baik Mac OS maupun MS-DOS memiliki model proses yang benar. Perlindungan Hardware sebagian
besar diabaikan. Sebuah program jahat bisa dengan mudah "crash" seluruh sistem. Ini, dan kadang-
kadang masih adalah, dianggap dapat diterima sebagai mesin ini biasanya melayani satu pengguna yang
bertanggung jawab dan siapa yang bisa menghindari kecelakaan itu hanya dengan menghindari
penggunaan aplikasi tidak dapat diandalkan.
Pada saat yang sama, mesin-mesin dan sistem operasi berkinerja sangat baik ketika datang untuk
penggunaan interaktif khas. Ekstensi sistem ataupun plugins disebut secara langsung, tanpa konteks
switch yang terlibat. Arsitektur komponen di daerah khusus telah digunakan utama untuk beberapa
waktu. Sebagai contoh, Apple QuickTime termasuk modul plugin dari awal, meskipun layanan
multimedia QuickTime adalah salah satu yang paling penting kinerja sistem dapat menawarkan.
Apakah mungkin untuk memiliki kue dan memakannya juga? Mungkinkah ada cara ketiga, dengan
komposisi komponen efisien yang juga menawarkan jenis keamanan sudah menuntut di bagian 2.2?
Salah satu cara adalah memilih dengan hati-hati rincian dari komponen. Jika kebanyakan interaksi tetap
dalam batas-batas komponen ini, biaya yang dikeluarkan saat melintasi batas-batas komponen dapat
ditoleransi. Bab 8 terus diskusi tentang berbagai aspek yang mengatur komponen granularity. Cara lain
adalah untuk menjamin statis bahwa komponen akan aman. Hal ini dibahas lebih lanjut dalam bagian
berikutnya.
6.7 Keselamatan oleh konstruksi - kelangsungan hidup komponen
Diskusi mengenai poin keselamatan jenis ke arah yang benar. Setelah semua, perlindungan hardware
"hanya" menghilangkan kesalahan memori - mencegah salah satu bagian dari sistem mengakses
(membaca, menulis, atau mengeksekusi) bagian lain dari sistem yang tidak memiliki otorisasi. Dalam
sistem benar-benar jenis-aman, pembacaan setara adalah bahwa tidak ada bagian yang dapat
mengakses bagian lain yang belum diberi referensi atau yang tidak dalam lingkup statis visibilitas.
Berikut adalah contoh. File kelas Java (format dikompilasi portabel Jawa) dan mesin virtual Java telah
dibuat untuk berinteraksi dengan cara yang mencegah tipe-aman applet dari dieksekusi dalam
lingkungan non-lokal. Java adalah bahasa jenis-aman. Ini menyediakan manajemen memori otomatis
menggunakan
pengumpulan sampah. Akhirnya, ia melakukan pemeriksaan runtime pada semua operasi yang
"berbahaya," tetapi tidak dapat statis diperiksa, seperti batas array cek. Bersama-sama, teknik ini
menjamin bahwa kesalahan memori tidak dapat terjadi. Sebagai file kelas, yang dihasilkan oleh compiler
Java, bisa dirusak, mesin virtual memeriksa ulang mereka ketika memuat satu datang dari sebuah situs
non-lokal, seperti di internet.
Komponen Pascal adalah contoh lain. Bahasa menawarkan jaminan sama kuat. Di sini lingkungan
eksekusi menerima bentuk portabel antara yang dihasilkan oleh compiler yang didasarkan pada
pendekatan yang sama sekali berbeda. Formulir ini juga diperiksa ulang, tapi kemudian dikompilasi ke
dalam cache lokal binari dan referensi di masa depan dengan komponen yang sama langsung
menggunakan biner cache. Seperti Jawa, Komponen Pascal juga sepenuhnya sampah yang dikumpulkan.
Tidak seperti Java, Komponen Pascal tidak memiliki atau membutuhkan penerjemah atau mesin virtual.
Contoh ketiga adalah NET Common Language Runtime (CLR) Microsoft.. CLR juga menggunakan akhir
kompilasi dan menghindari interpretasi, menghilangkan gagasan tentang mesin virtual. Ini
mendefinisikan bahasa perantara yang telah dirancang untuk mendukung berbagai macam bahasa
pemrograman dan masih memetakan efisien untuk berbagai prosesor. Beberapa 15 sampai 20 bahasa
telah diteliti dan banyak dari mereka diimplementasikan (dalam upaya kolaborasi internasional yang
besar yang disebut "Project 7") untuk memvalidasi klaim dukungan untuk banyak bahasa.
Ketiga contoh berbagi satu fitur, yaitu bahwa sifat keselamatan yang kuat dapat dibentuk pada waktu
kompilasi, diperiksa di install, beban, atau JIT kompilasi-waktu, dan kemudian diandalkan tanpa
memeriksa lebih lanjut ketika menjalankan kode efisien yang dihasilkan.

6.7.1 keselamatan Modul
Namun, jenis keselamatan dan penghapusan kesalahan memori tidak cukup, meskipun diasumsikan
bahwa hal bahasa objek enkapsulasi. Tanpa langkah-langkah tambahan, masih akan mungkin bagi
sebuah program untuk memanggil layanan sewenang-wenang hadir dalam atau loadable ke dalam
sistem. Ini akan menjadi semua yang diperlukan untuk mendapatkan referensi ke objek sewenang-
wenang dalam sistem dan dengan demikian "secara hukum" (sejauh sistem tipe yang bersangkutan)
untuk melakukan manipulasi sewenang-wenang. Misalnya, ada kontrol ActiveX yang menutup Windows.
Satu persyaratan tambahan, juga dipenuhi oleh Java, Komponen Pascal, dan CLR adalah keselamatan
modul (Szyperski dan Gough, 1995). Sebuah komponen harus menentukan secara eksplisit yang layanan
- dari sistem atau komponen lain - perlu mengakses. Hal ini dilakukan dalam bentuk modul (atau paket)
daftar impor.
Bahasa dan sistem tidak mengizinkan akses ke modul non-impor. Oleh karena itu, jika daftar yang hanya
berisi modul diperbolehkan, maka aman untuk memuat dan mengeksekusi komponen baru. Ini seperti
kontrol akses dalam sistem file, namun pada per modul (atau per kelas) dasar, bukan per objek dasar.
Obyek terlalu dinamis untuk diidentifikasi secara eksplisit untuk tujuan kontrol akses statis.
Dengan modul keselamatan di tempat, abstraksi dari seluruh layanan multiobject dapat dibentuk. Tidak
seperti kelas, modul dapat menegakkan invariants di erat berinteraksi benda (Szyperski, 1992a). Dalam
bahasa tidak mendukung setiap granularity yang lebih tinggi daripada kelas kemasan, perlindungan
akses harus menjadi per kelas, yang menawarkan keamanan kelas bukan modul keamanan.
Keselamatan modul ini tidak sesederhana kedengarannya. Dalam sistem komponen penting bahwa
komponen lain (dan jasa) dapat diambil oleh nama. Nama itu sendiri dapat dibuat tersedia untuk
komponen setelah komponen yang telah disusun, diperiksa, dan dimuat - yaitu, pada saat runtime.
Sebuah cara yang bersih dan populer untuk mendukung pengambilan komponen dengan nama adalah
layanan refleksi. Java, Komponen Pascal, dan. NET CLR semua menawarkan layanan tersebut. Dimana
akses ke komponen harus dibatasi, layanan refleksi memerlukan perhatian khusus agar tidak
menciptakan celah keamanan.

6.7.2 Modul keselamatan dan metaprogramming
Ini harus mungkin untuk komponen untuk mengambil referensi ke komponen lain yang belum diberikan
akses. Sebagai contoh, di Jawa, khusus
object manager keamanan digunakan untuk memeriksa apakah pemanggil dari fungsi kritis memiliki
otorisasi yang tepat. Untuk melakukannya, panggilan stack dilalui dan diperiksa untuk setiap record
aktivasi dipercaya. Jika tidak ada, panggilan dapat melanjutkan karena tidak dapat melayani setiap
komponen yang tidak dipercaya. Panggilan untuk manajer keamanan dilakukan oleh operasi kritis
sendiri untuk melindungi diri terhadap panggilan yang tidak diinginkan. Manajer keamanan melempar
pengecualian keamanan jika tidak mengotorisasi akses untuk langsung atau salah satu dari penelepon
tidak langsung.
Seperti diakui dalam JavaBeans dokumen standar (Sun, 1996), pendekatan ini dapat dirusak oleh
layanan sembarangan diprogram tapi terpercaya yang melakukan permintaan asynchronous atas nama
klien (disebut event adapter). Dalam kasus seperti itu, klien sejati tidak akan aktif pada saat panggilan
keamanan-kritis, hanya layanan terpercaya akan. Jalan lain kalau benda penting yang terdaftar dalam
registri yang tidak dilindungi. Dalam hal ini, siapa pun menebak tombol akses atau nama, atau, jika
didukung, siapa pun menyebutkan semua benda yang terdaftar, bisa mengambil objek kritis di bawah
supertype generik, seperti Object. Ini kemudian akan hanya masalah uji tipe dan cor untuk mendapatkan
kembali akses ke objek kritis.
Bahkan jika komponen mengakses secara hukum beberapa modul, tidak harus mendapatkan akses ke
swasta (non-diekspor) bagian dari modul tersebut. Untuk akses langsung, hal ini dijamin oleh semantik
bahasa. Namun, di mana pemrograman meta-interface ada, ini perlu secara eksplisit dibatasi sedemikian
rupa sehingga layanan ini tidak melanggar enkapsulasi. Hal ini bertentangan dengan beberapa
penggunaan khas meta-programming, seperti debugging atau struktur data serialisasi jasa. Memang,
sistem mungkin menawarkan dua antarmuka metaprogramming - satu yang modul aman dan terbuka
untuk penggunaan umum dan lain yang modul tidak aman dan terbatas pada komponen dipercaya.
The BlackBox Kerangka Komponen (Component digunakan dengan Pascal) saat ini menjadi contoh yang
unik dari sistem yang menawarkan layanan ganda metaprogramming. Jenis-dan layanan modul-aman
terbuka untuk penggunaan umum, sedangkan layanan modul-aman digunakan oleh komponen-
komponen yang terpercaya, seperti BlackBox debugger portabel. The Java JDK mencakup fasilitas
metaprogramming yang biasanya modul safe (paket aman). Beberapa modul-aman operasi terbatas
yang tersedia untuk penelepon terpercaya, tunduk pada validasi manager keamanan.
Twist yang menarik ditambah dengan. NET CLR. Ini adalah kemungkinan penambahan kustom meta-
atribut dengan metode yang membatasi set penelepon berdasarkan lingkup (memanggil kode dari
produsen tertentu atau dari komponen lainnya tertentu) atau tuntutan keamanan (kode panggilan harus
memberikan mandat diterima). Beberapa tuntutan ini diperiksa pada beban-time, beberapa hanya
dapat diperiksa saat runtime. Pemeriksaan load-waktu yang sangat menarik dan unik.

6.7.3 Keamanan dalam lingkungan multilanguage
Komponen teknologi memungkinkan pemilihan bahasa pemrograman yang berbeda untuk pelaksanaan
komponen yang berbeda. Perlindungan bersama komponen dalam domain perlindungan perangkat
keras yang sama sehingga memerlukan jenis dan sifat keselamatan modul yang umum untuk semua
bahasa yang digunakan dalam konfigurasi tersebut. Bahasa definisi antarmuka yang cukup kuat (IDLs)
dapat memecahkan masalah ini. Oleh karena itu tidak perlu untuk membatasi sistem untuk pendekatan
bahasa pemrograman tunggal hanya untuk mendapatkan keuntungan dari jenis bahasa tingkat dan
keamanan modul. Namun, kekuatan dari pendekatan secara keseluruhan akan tergantung pada
kekuatan bagian terlemah - yaitu, yang paling lemah dari bahasa yang digunakan, termasuk IDL.
Ketentuan CLR untuk membangun keselamatan jenis, keamanan modul, dan integritas keamanan di
semua bahasa yang didukung menunjukkan bahwa pilihan bahasa untuk kedua pembentukan prinsip-
prinsip perusahaan yang mendasari kompatibel dengan banyak bahasa. Catatan, bagaimanapun, bahwa
yang membutuhkan sifat keamanan CLR kuat membatasi bahasa yang digunakan untuk subset aman
mereka. Sebagai contoh, C # mendukung metode yang tidak aman, yang adalah mereka yang tidak dapat
secara otomatis diperiksa untuk keselamatan mereka. Sebuah komponen yang ditulis menggunakan C #
's metode tidak aman (atau fasilitas serupa dalam bahasa CLR-pendukung lainnya) akan ditolak oleh
pemeriksaan keamanan otomatis kecuali komponen yang dilengkapi dengan mandat yang menyatakan
sebagai dapat dipercaya. Berbeda dengan pendekatan ActiveX Authenticode, di mana komponen baik
sepenuhnya dipercaya atau tidak dijalankan sama sekali, dan seperti komponen Java, komponen CLR
lebih disukai digunakan tanpa memerlukan tingkat seperti kepercayaan.


6.8 Keselamatan, keamanan, kepercayaan
Jenis keselamatan, keamanan modul, dan tidak adanya kesalahan memori - apa yang membuat
pendekatan ini bahasa-semantik berbasis dipercaya? Jawabannya tergantung pada keadaan. Jika target
adalah seperangkat komponen, terinstal secara lokal, berinteraksi pada komputer pribadi, maka
pendekatan ini mungkin sudah dekat dengan memuaskan. Jika target adalah tingkat keamanan tertinggi,
maka pendekatan ini akan benar-benar tidak dapat diterima. Jika target adalah sistem rendah ke
menengah-keamanan yang bergerak komponen di internet, pendekatan ini mungkin pada batas-
batasnya.
Apa yang salah? Pertama, dan di atas semua, pendekatan ini sepenuhnya bergantung pada semantik
yang ketat dari bahasa pemrograman yang digunakan. Untuk sepenuhnya dapat dipercaya, semantik
formal bahasa bersama-sama dengan bukti-bukti formal sifat keamanan diklaim akan diperlukan. Juga,
tentu saja, metode yang formal itu sendiri perlu dipercaya, termasuk alat-alat yang dapat digunakan
untuk membangun bukti panjang semiautomatically. Sangat sedikit bahasa pemrograman memenuhi
persyaratan ini dan tidak ada arus utama bahasa berorientasi objek.
Bahkan jika bahasa sepenuhnya memenuhi kriteria ini, pelaksanaannya masih bisa mematahkan setiap
properti terbukti. Oleh karena itu, untuk pergi jauh-jauh, prosesor bahasa dan sistem runtime bahasa
lagi perlu secara resmi ditetapkan dan diverifikasi. Ini cukup prestasi untuk mencapai. Pertimbangkan
bahwa pemrosesan bahasa meliputi alat-alat seperti compiler, penerjemah, atau verifier kode byte.
Runtime bahasa meliputi mekanisme seperti mesin virtual, pengumpul sampah, atau manajer
keamanan. Jelas, ini dapat menyebabkan masalah bootstrap mana alat yang digunakan untuk
membangun alat yang digunakan lagi perlu diverifikasi secara formal, dan sebagainya. Tak satu pun dari
implementasi bahasa tersedia secara luas memenuhi kriteria tersebut, bahkan tidak dalam kasus di
mana bahasa itu sendiri dilaksanakan memenuhi kriteria keamanan.
Pada akhirnya, kepercayaan adalah masalah mengurangi diketahui oleh dikenal dan dipercaya, dan
melakukannya dengan cara yang dipercaya. Hal ini jelas terutama proses sosiologis. Misalnya, cara
mekanisme keamanan Unix diperkenalkan memainkan peran utama di dalamnya dipercaya. Para
desainer dari mekanisme pub-diterbitkan rinciannya secara penuh dan mendorong semua orang untuk
mencoba untuk memecahkannya. Setelah bertahun-tahun, mekanisme yang diperoleh (atau, lebih baik,
memperoleh) kepercayaan itu saat ini menerima. Kepercayaan ini dapat dibenarkan secara probabilistik.
Hal ini sangat tidak mungkin bahwa celah masih belum ditemukan di bawah tidak terkoordinasi
(stochastic) evaluasi oleh banyak selama jangka waktu.
Para desainer Java juga dipublikasikan strategi keamanan mereka sejak dini dan mendorong kelompok
penelitian yang serius (McGraw dan Felten, 1997) untuk menantang pendekatan. Dengan cara ini, celah
yang dikenal diterbitkan dan tetap (lihat "Pertanyaan yang sering diajukan - keamanan Java,"
www.java.sun.com / sfaq). Setelah bertahun-tahun terus berkurang laporan masalah yang ditemukan,
orang akan semakin percaya pendekatan. Hari ini, pembatasan kepercayaan yang tepat, apa pun pro-
komponen klaim, dan bahkan jika mereka benar.

6.9 Dimensi diperpanjang independen
Dalam kerangka kelas tradisional, ekstensi terjadi berdasarkan spesialisasi: kelas kerangka yang
subclassed untuk menambahkan perilaku yang diperlukan. Jika kerangka tidak menawarkan abstraksi
yang tepat, spesialisasi tersebut mungkin tidak dapat dilakukan. Namun, gagasan warisan pelaksanaan,
sebagaimana ditafsirkan dalam kebanyakan bahasa berorientasi obyek, memungkinkan untuk
perubahan yang cukup radikal untuk kelas diperkenalkan oleh framework. Cukup sering, fungsi yang
diperlukan dapat dipaksakan pada kerangka.
Kerangka kelas tradisional mengkhususkan diri pada aplikasi waktu konstruksi dan selanjutnya
menghilang karena tidak ada lagi bagian terpisah dari aplikasi yang dihasilkan. Satu-satunya konflik
akibat "dipaksa" spesialisasi adalah bahwa migrasi aplikasi untuk rilis berikutnya dari kerangka
independen berevolusi mungkin sulit atau tidak mungkin.
Situasi ini sangat berbeda untuk sistem mandiri extensible. Menggunakan kerangka komponen tunggal,
ekstensi dari sumber-sumber independen dapat dikombinasikan. Memaksa spesialisasi akan
membahayakan interoperabilitas ekstensi independen. Jadi, bahkan lebih daripada untuk kerangka
kelas, sistem mandiri extensible membutuhkan pernyataan yang jelas tentang apa yang dapat
diperpanjang. Setiap fitur tertentu dari sistem independen extensible yang terbuka untuk perpanjangan
terpisah disebut dimensi (independent) diperpanjang (misalnya, Weck, 1997).
Perhatikan bahwa dimensi diperpanjang tidak selalu orthogonal - efek yang sama dapat dicapai dengan
memperluas sepanjang salah satu dari beberapa dimensi yang mungkin. Hal ini biasanya tidak
diinginkan, karena menawarkan desainer ekstensi pilihan yang tidak diinginkan. Orthogonality
Sempurna dimensi sulit untuk mencapai dan pengecualian total kemungkinan tumpang tindih mungkin
terlalu membatasi dimensi individual. Hasilnya akan menjadi sebuah sistem yang orthogonal tapi tidak
lengkap. Akibatnya, ekstensi penting menjadi mustahil. Cita-cita teoritis akan membentuk dimensi
ortogonal diperpanjang independen yang bersama-sama membentuk sebuah ruang ekstensi yang
lengkap sehubungan dengan persyaratan diperpanjang.
Dalam prakteknya, sistem extensible jarang memiliki dimensi ortogonal diperpanjang. Sebagai contoh,
sistem yang sama dapat mendukung abstraksi extensible untuk serialisasi objek dan objek ketekunan.
Meskipun tidak identik, dua layanan ini tentu tumpang tindih. Beberapa dimensi diperpanjang
membentuk ruang hasil (himpunan semua kombinasi ekstensi sepanjang dimensi individual). Dimana
dimensi ortogonal, ruang yang dihasilkan adalah produk Cartesian. (Sebuah produk Cartesian, juga
disebut cross-product, dari nsets adalah himpunan n-tupel yang berisi semua kemungkinan permutasi
dari unsur-unsur nsets. Banyaknya permutasi berbeda secara efektif berkurang jika set asli tumpang
tindih dan kemudian dimensi yang sesuai adalah non-orthogonal.)

6.9.1 Bottleneck interface
Jika sistem itu secara independen extensible "dari awal" - yaitu, tidak ada infrastruktur tetap akan ada,
maka ekstensi independen tidak bisa beroperasi sama sekali. Tak akan ada landasan bersama bagi
mereka untuk berinteraksi. Sebuah kesamaan setelah fakta tidak bisa umumnya diberikan sebagai
ekstensi berasal dari sumber-sumber independen dan saling menyadari. Kerangka komponen
memberikan pemahaman bersama yang diperlukan bahwa pasangan ekstensi. Sebuah kerangka
komponen membuka sejumlah dimensi untuk memperluas komponen. Juga, kerangka komponen dapat
memberlakukan beberapa aturan interaksi antara ekstensi.
Antarmuka diperkenalkan untuk memungkinkan interoperation antara abstraksi mandiri diperpanjang
kadang-kadang disebut interface bottleneck (misalnya, Szyperski, 1992b). Sebuah antarmuka bottleneck
adalah kontrak self-berdiri. Sebagai pasangan antarmuka bottleneck independen keluarga ekstensi, itu
tidak sendiri diperpanjang. Ini adalah salah satu argumen di balik klaim bahwa seperti interface, setelah
diterbitkan, hanya dapat ditarik atau diganti tetapi tidak diperpanjang.
Interface Bottleneck, setelah diterbitkan, yang berubah (lihat juga bagian berikutnya). Jelas, komponen
dapat saling menyadari ekstensi mereka dan terlibat dalam interaksi khusus. Dalam kerangka komponen
dirancang buruk, kesadaran bersama tersebut kadang-kadang diperlukan untuk dua komponen untuk
berinteraksi dengan baik. Dengan kata lain, kerangka komponen seperti ini membutuhkan komponen
tampaknya independen untuk masuk ke dalam "konspirasi."

6.9.2 Singleton konfigurasi
Sebuah kerangka komponen dapat membuka dimensi diperpanjang tetapi memerlukan konfigurasi
tunggal untuk beberapa dimensi. Konfigurasi adalah konfigurasi tunggal, mengenai dimensi wajib
tertentu, jika memberikan tepat satu komponen yang memperluas dimensi itu. Untuk dimensi opsional,
konfigurasi tunggal menyediakan paling banyak satu komponen. Sebagai contoh, sistem memungkinkan
untuk instalasi manajer keamanan, tetapi mungkin berusaha keras untuk memiliki paling banyak satu
manajer tersebut dalam konfigurasi pada satu waktu.

6.9.3 Paralel, orthogonal, dan rekursif ekstensi
Biasanya, untuk sebagian atau bahkan seluruh dimensinya, kerangka komponen akan tidak memerlukan
konfigurasi tunggal. Dengan demikian, konfigurasi dapat berisi banyak komponen yang semua
memperpanjang sepanjang dimensi yang sama. Ini disebut ekstensi paralel (Weck, 1997). Masalah
utama dari sistem yang memungkinkan untuk perpanjangan paralel hidup berdampingan secara damai.
Dua komponen yang membentang sepanjang dimensi yang sama berada dalam bahaya meminta
sumber daya yang sama. Sebuah kerangka komponen yang memungkinkan untuk perpanjangan paralel
memiliki untuk menentukan aturan dan menyediakan sarana untuk arbitrase. Contohnya adalah
seperangkat beberapa kontrol tertanam ke dalam wadah yang sama dari sistem dokumen majemuk.
Seharusnya sumber daya yang unik, seperti fokus saat ini untuk input keyboard, perlu penengah ketika
permintaan dari beberapa kontrol bertabrakan.
Komponen memperluas terpisah juga dapat mengatasi dimensi ortogonal dari kerangka komponen. Ini
disebut ekstensi orthogonal (Weck, 1997). Masalah utama dengan ekstensi orthogonal adalah
penyediaan interface bottleneck yang tepat untuk memungkinkan interaksi antara ekstensi orthogonal.
Sekali lagi, dengan menggunakan contoh kontrol dan wadah dalam dokumen majemuk, kontrol dan
kontainer yang menangani dimensi orthogonal. Sebuah komponen tunggal dapat mengatasi kedua
dimensi secara bersamaan, sehingga, misalnya, bisa jadi kontrol dan kontainer pada saat yang sama.
Sebuah kerangka komponen untuk dokumen senyawa harus mendefinisikan dan mendukung antarmuka
bottleneck yang memungkinkan kontrol sewenang-wenang untuk berbicara dengan wadah sewenang-
wenang dan sebaliknya. Sebuah antarmuka khas semacam ini digunakan oleh kontrol dan wadah untuk
bernegosiasi untuk ruang layar.
Kedua ekstensi paralel dan ortogonal datar - yaitu, komponen memperluas saling independen. Ekstensi
Rekursif juga mungkin. Sebuah komponen dapat sendiri memperkenalkan kerangka komponen.
Komponen memperluas kerangka baru ini jelas tergantung pada komponen kerangka-memperkenalkan
atau setidaknya abstraksi diperkenalkan oleh komponen ini. Perhatikan bahwa ekstensi rekursif tidak
selalu menciptakan arsitektur yang berlapis.
Ada kemungkinan bahwa komponen secara bersamaan memperluas dimensi diperkenalkan oleh
ekstensi rekursif pada tingkat yang berbeda. Sebagai contoh, sebuah sistem mungkin memiliki kerangka
komponen untuk pengelolaan sumber daya didistribusikan. Salah satu komponen memperluas kerangka
kerja ini mungkin sendiri menjadi kerangka kerja untuk dokumen majemuk. Ada kemungkinan bahwa,
katakanlah, komponen wadah meluas dimensi dari kedua manajemen sumber daya dan kerangka
dokumen majemuk.

6.10 Evolusi vs kekekalan interface dan kontrak
Sebuah kontrak - antarmuka bersama dengan spesifikasi - menengahi antara independen berkembang
klien dan penyedia layanan antarmuka membuat dapat diakses. Segera setelah kontrak telah
dipublikasikan ke dunia, itu (antarmuka dan spesifikasi) tidak bisa lagi diubah. Hal ini berlaku untuk klien
dan penyedia terikat kontrak tertentu.
Provider A selalu dapat berhenti menyediakan antarmuka tertentu. Ini kemudian akan berpotensi
kehilangan sebagian dari basis kliennya - bagian yang belum bermigrasi ke beberapa antarmuka yang
lebih baru. Namun, penyedia tidak pernah dapat mengubah spesifikasi kontrak yang ada seperti yang
akan mematahkan klien tanpa indikasi yang jelas. Juga, klien tidak dapat mengubah pemahamannya
kontrak tanpa risiko melanggar dengan beberapa penyedia yang ada.
Landasan bahkan berdebat tentang kontrak dan mengubah kontrak adalah cara untuk nama unik
kontrak bahwa klien dan penyedia lihat. Sebagai kontrak, dengan semua peraturan informal, itu sendiri
cukup sulit untuk menangkap, nama antarmuka yang terkait yang umum digunakan.

6.10.1 Sintaksis dibandingkan perubahan kontrak semantik
Perubahan kontrak dapat mengambil dua bentuk . Entah interface atau spesifikasi berubah . Jika
antarmuka berubah , ini disebut sebagai perubahan sintaksis . Jika spesifikasi berubah , ini disebut
perubahan semantik . Sebagai penyedia sering " bertanggung jawab " dari kontrak , dan penyedia khas
dalam pengaturan objek - ori - ented adalah kelas , masalah yang disebabkan oleh perubahan kontrak
kadang-kadang disebut sebagai rapuh masalah kelas dasar . Variasi sintaksis dan semantik rapuh
masalah kelas dasar dibahas secara rinci dalam bagian 7.4 .
Sebuah cara sederhana untuk menghindari masalah ini adalah untuk menahan diri dari perubahan
kontrak setelah mereka telah dipublikasikan . Tentu saja, tidak ada masalah dengan mengubah kontrak (
sintaksis atau semantik ) , asalkan semua penyedia terikat dan klien berada di bawah pengendalian .
Dengan demikian , evolusi kontrak dalam organisasi yang ketat biasanya tidak menjadi masalah .
Namun, dengan melepaskan klien atau penyedia layanan untuk pasar terbuka , kontrak yang terlibat
menjadi tidak terkendali . Kemudian , perubahan harus berhenti dan kontrak harus dibekukan , dibuat
berubah .
Hal ini membantu untuk mempertimbangkan lagi analogi kontrak tradisional . Tidak ada klausul dalam
kontrak , setelah ditandatangani , dapat diubah tanpa persetujuan dari semua pihak yang terlibat . Tentu
saja, setelah ada jumlah tak terkendali partai , mendapatkan persetujuan bisa menjadi sulit atau tidak
mungkin . Contohnya adalah kontrak antara semua pengusaha dan karyawan ditutupi oleh beberapa
serikat tarif . Namun, kontrak tersebut memiliki mekanisme yang memungkinkan untuk perubahan . Dua
mekanisme dasar adalah : mengakui keberadaan hukum utama dan contoh dan pernyataan waktu
terminasi . ( Terima kasih kepada Wolfgang Weck untuk menunjukkan analogi ini . )
Perlu dicatat bahwa , saat ini , hanya Microsoft COM menyatakan semua antarmuka diterbitkan untuk
menjadi abadi . Bahkan Microsoft sendiri menganut prinsip dan memperkenalkan antarmuka baru,
bukan memodifikasi yang sudah ada bahwa hampir fit .
Dukungan untuk antarmuka yang lebih tua ditegakkan untuk sementara waktu untuk menjaga
kompatibilitas mundur , tapi akhirnya interface yang lebih tua seperti itu dapat dan harus pergi . IBM
SOM melakukan sesuatu yang berbeda . Dengan eksplisit mendukung perintah pembebasan , klien dari
rilis yang berbeda ( versi ) dari sebuah antarmuka dapat hidup berdampingan . Pada dasarnya , perintah
pelepasan jaminan eksplisit untuk setiap metode indeks tetap menjadi tabel . Untuk bekerja , rilis baru
hanya dapat menambah sebuah antarmuka , tidak dapat mengambil fungsi pergi . Sebuah diskusi yang
lebih rinci dari dua pendekatan dapat ditemukan dalam Bab 13 ( SOM ) dan Bab 15 ( COM ) . SOM sejak
itu telah usang . Ironisnya , banyak pendekatan baru yang dibahas dalam buku ini , termasuk EJB J2EE
dan CCM CORBA 3 , ikuti pendekatan SOM mendukung model kompatibilitas release -to -release biner . .
NET CLR mendukung kedua - pendekatan COM sisi -by-side adanya antarmuka ( dan kelas ) , versi yang
karenanya dapat disimpan berubah , serta pendekatan SOM kompatibilitas release -to -release .
6.10.2 Kontrak kadaluwarsa
Beberapa infrastruktur komponen arus menawarkan layanan perizinan dan itu adalah properti alami
lisensi yang mereka berakhir setelah tanggal ditetapkan . Oleh karena itu , tampaknya mudah untuk
penyediaan layanan beberapa di bawah kontrak tertentu dengan perjanjian lisensi dan tanggal jatuh.
Hasilnya akan memungkinkan untuk evolusi dikendalikan di mana klien dan penyedia membabi buta bisa
mempercayai keabsahan dan keberadaan layanan di bawah kontrak tertentu sampai tanggal
berakhirnya kontrak tercapai . Setelah itu , produsen klien dan penyedia harus negosiasi ulang : seumur
hidup kontrak bisa diperpanjang atau kontrak bisa diganti atau disempurnakan .
Menggunakan kontrak dengan " menggunakan - oleh tanggal " memiliki efek pada pengguna . sistem
perangkat lunak
tidak lagi dapat digunakan tanpa batas waktu - atau setidaknya selama yang usang PC dapat tetap hidup
. Namun, ada juga keuntungan . Alih-alih mendukung kontrak warisan selamanya , menambahkan lebih
banyak beban untuk penyedia dan klien , ada cara yang bersih untuk memotong masa lalu . Seperti
disebutkan di atas , selalu mungkin untuk menghentikan dukungan untuk kontrak usia . Namun, tanpa
tanggal kadaluwarsa yang disepakati bersama, ini akan selalu datang sebagai kejutan bagi beberapa
pengguna .
6.10.3 hukum Overriding
Bagaimana dengan mekanisme lain dalam kontrak tradisional , mengesampingkan hukum ? Melebihi
hukum dalam arti ini dapat berarti depresiasi klien atau penyedia sesuai dengan interpretasi lama
kontrak . Dalam tindakan self- keadilan , perusahaan kuat atau organisasi sering menerapkan prinsip ini .
Cara yang lebih moral untuk mencapai hal yang sama adalah intersepsi oleh organisasi independen
diterima . Contoh umum adalah Organisasi Standar Internasional ( ISO ) , American National Standards
Institute ( ANSI ) , Asosiasi Produsen Komputer Eropa ( ECMA ) , British Standards Institution ( BSI ) ,
lembaga Jerman untuk standar industri ( DIN ) , dan sebagainya .

6.11 Bentuk lain dari polimorfisme
Ada bentuk lain dari polimorfisme selain subtipe ( atau inklusi ) polimorfisme diperkenalkan di atas (
bagian 6.2 ) . Bentuk-bentuk lainnya dibahas secara singkat di bawah ini. Untuk cakupan menyeluruh ,
lihat Abadi dan Cardelli ( 1996) .
Meskipun subtipe polimorfisme adalah skema yang dinamis , bentuk-bentuk lain yang statis dan diatasi
oleh sebuah compiler . Ada sistem jenis tingkat tinggi , di mana beberapa dari bentuk-bentuk lain juga
mungkin memerlukan resolusi yang dinamis . Sistem jenis tersebut belum mencapai bahasa mainstream.
Overloading , karena didukung oleh bahasa seperti C + + , Java , dan C # , adalah bentuk polimorfisme
bahwa kelompok-kelompok operasi tidak berhubungan dengan nama yang sama . Overloading kadang-
kadang disebut polimorfisme ad hoc karena menetapkan hanya kesamaan dangkal yang didasarkan
pada tidak mengetik atau implementasi bersama.
Bentuk ketiga polimorfisme berfokus pada menggunakan implementasi yang sama
untuk melayani berbagai jenis . Sebagai contoh, implementasi daftar dapat parametrized dengan jenis
elemen daftar . Salah satu contoh dari daftar akan melayani
satu jenis tertentu, tapi pelaksanaan daftar itu sendiri adalah generik dan disediakan hanya sekali . Ini
disebut polimorfisme parametrik dan mirip dengan obat generik di Ada . Benar dilaksanakan ,
polimorfisme parametrik tidak menyebabkan ledakan kode yang dihasilkan . Varian terutama ringan
yang selalu menghasilkan tepat satu salinan kode telah diusulkan untuk Oberon ( Roe dan Szyperski ,
1997 ) dan mungkin di masa depan akan didukung oleh Komponen Pascal . Perhatikan bahwa
polimorfisme parametrik juga mirip dengan C + + template . Namun, C + + template menyebabkan
ledakan kode sebagai template yang harus dikompilasi menjadi kode yang berbeda untuk setiap
Instansiasi . Juga , template tidak bisa statis mengetik diperiksa sebagai jenis pemeriksaan tidak dapat
terjadi sebelum parameter yang disediakan .
Kadang-kadang berguna untuk menentukan batasan pada jenis parameter . Polimorfisme parametrik
tidak memungkinkan hal ini - semua jenis dapat digunakan untuk parameterisasi abstraksi parametrik .
Misalnya, daftar parametrik dapat digunakan untuk membentuk daftar lebih dari jenis sewenang-
wenang . Untuk daftar , yang baik-baik saja . Pertimbangkan komponen kontainer parametrik . Ia
menerima kontrol dari jenis tertentu , ditentukan oleh jenis parameter . Namun, apapun jenis parameter
akan , itu harus menjadi sub - tipe Control, yaitu , hanya mengontrol jenis dapat diterima .
Suatu bentuk polimorfik kuat yang menerima batas dalam bentuk supertypes minimal disebut
polimorfisme dibatasi . Polimorfisme Bounded menggabungkan subtipe dan polimorfisme parametrik .
Sebagai contoh, menggunakan subtipe polimorfisme , daftar objek kontrol dapat dibangun , tetapi
pelaksanaan daftar yang sama tidak dapat lebih dibatasi berisi kontrol teks saja .
Menggunakan polimorfisme parametrik , yang terakhir dapat dicapai , tetapi daftar juga bisa
parametrized hanya berisi model ( atau jenis lain dari objek ) - properti subtyping bahwa setiap elemen
setidaknya kontrol hilang .
Dalam kontrol contohnya kontainer , operasi khusus kontrol perlu diterapkan untuk semua elemen
daftar . Untuk operasi tersebut menjadi statis aman , kombinasi dari subtipe dan polimorfisme
parametrik akan diperlukan dan dibatasi polimorfisme dapat digunakan . Daftar ini akan parametrized
dengan tipe yang harus menjadi subtipe dari tipe kontrol. Jenis control menempatkan terikat pada jenis
parameter yang dapat diterima . Sebuah tantangan yang menarik untuk integrasi akhir ke dalam bahasa
yang ada adalah kebutuhan untuk hidup berdampingan dengan kode yang sudah ada yang tidak tahu
tentang polimorfisme dibatasi . Tantangan selanjutnya adalah keinginan untuk sepenuhnya mendukung
refleksi runtime informasi jenis bahkan melalui variabel jenis polimorfik dibatasi . Proposal untuk
mengintegrasikan polimorfisme dibatasi ke Jawa ( Myers et al , 1997; . Odersky dan Wadler , 1997; .
Bracha et al , 1998; Cartwright dan Steele Jr , 1998; JCP , 2001) dan ke CLR dan C # ( Sime dan Kennedy
2001 ) ada dan sebagian besar tantangan sekarang ditangani dengan cara yang praktis , menunjukkan
bahwa konsep-konsep ini akan membuatnya menjadi bahasa utama segera . Sebuah kesempatan yang
menarik untuk bahasa JIT dikompilasi seperti Java dan C # adalah kemungkinan ekspansi kode selektif
pada jenis tertentu . Alih-alih kembung kode parametrik dengan template mengembangkannya pada
saat kompilasi , kode yang sama dapat selektif diperluas di JIT kompilasi - waktu , mungkin
mempertimbangkan run-time informasi profil untuk menyempurnakan kinerja .