Banyak orang di Cina menganggap Delphi sebagai alat pengembangan pilihan mereka. Alasannya tentu saja karena Delphi menyediakan banyak fitur bagi pengembang: pengembangan berorientasi objek, desain antarmuka visual, komponen yang kaya, dan portabilitas multi-platform (fitur baru Delphi6).
Namun bagi pemula, pemikiran berorientasi objek mungkin bukan perasaan terbesar yang Delphi berikan kepada mereka. Desain antarmuka visual dan komponen yang tersedia kaya dan beragam meninggalkan kesan paling mendalam dan tak terlupakan. Akibat serius dari hal ini adalah para pemula seringkali hanya fokus pada penggunaan komponen VCL yang sudah ada yang disediakan oleh Delphi dalam waktu yang lama, sedangkan mengabaikan memikirkan dampak pemikiran berorientasi objek pada keseluruhan Delphi. Makna yang terkandung dalam arsitektur komponen sistem.
Potongan kode berikut berisi salah satu kesalahan paling umum yang sering dilakukan pemula. Meskipun kesalahan ini bukan kesalahan tata bahasa, hal ini menunjukkan bahwa pemikiran berorientasi objek pengguna perlu diperkuat:
var
Formulir1: TForm1;
pelaksanaan
{$R *.dfm}
Prosedur TForm1.Button1Click(Pengirim: TObject);
mulai
ShowMessage(Form1.Caption); // <-- Ada beberapa masalah dengan penggunaan Form1 di sini.
akhir;
Sekilas sepertinya tidak ada yang salah dengan kode semacam ini. Namun kemunculan Form1 di sini agak tidak masuk akal. Jelas sekali kode di sini ditulis untuk mengimplementasikan metode ButtonClick dari TForm1, dan Form1, sebagai turunan dari kelas TForm1, sebenarnya ditulis ke dalam implementasi kelas tersebut. Bukankah ada kebingungan konseptual? untuk berpikir berorientasi objek. Ini juga sangat sederhana dan dapat ditulis dalam dua cara:
1. ShowMessage(Self.Caption); // <-- Cara penulisan ini sangat jelas. Informasi yang akan ditampilkan adalah Caption dari instance kelas saat ini.
2. ShowMessage(Caption); // <-- Cara penulisan disini sama seperti di atas, namun kata kunci Self dihilangkan;
Tiga isi inti pemikiran berorientasi objek adalah enkapsulasi, pewarisan, dan polimorfisme. Masalah yang dipaparkan pada contoh di atas adalah masalah enkapsulasi. Contoh serupa meliputi:
var
Formulir1: TForm1;
...
var
Formulir2: TForm2;
prosedur TForm1.Button1Click(Pengirim: TObject);
mulai
Form2.Show; // <-- Sebagai variabel global, penggunaan Form2 di sini juga membingungkan.
akhir;
Contoh di atas mungkin lebih umum. Dalam kebanyakan kasus, dalam sebuah proyek, TForm1 dan TForm2 masing-masing hanya boleh memiliki satu instance, sehingga kode tersebut dapat dianggap lumayan. Namun dalam arti sempit, ini tidak memenuhi persyaratan enkapsulasi. Lihat kode berikut:
jenis
TForm1 = kelas(TForm)
Tombol1: Tombol T;
prosedur Button1Click(Pengirim: TObject);
pribadi
{Deklarasi pribadi}
FBerikutnya: TForm;
publik
{Pernyataan publik}
properti NextForm: TForm baca FNext tulis FNext;
akhir;
var
Formulir1: TForm1;
pelaksanaan
menggunakan Unit2;
{$R *.dfm}
prosedur TForm1.Button1Click(Pengirim: TObject);
mulai
jika Ditugaskan(FBerikutnya) lalu
TForm2(FBerikutnya).Tampilkan;
akhir;
akhir.
//Berikut isi file proyek:
program Proyek1;
kegunaan
Formulir,
Unit1 di 'Unit1.pas' {Form1},
Unit2 di 'Unit2.pas' {Form2};
{$R *.res}
mulai
aplikasi.Inisialisasi;
Aplikasi.CreateForm(TForm1, Form1);
Aplikasi.CreateForm(TForm2, Form2);
Form1.NextForm := Form2; // <-- Tambahkan kalimat ini untuk membuat kode memenuhi persyaratan enkapsulasi
Aplikasi.Jalankan;
akhir.
Berikan penunjuk Form2 ke Form1 sebagai atribut Form1 Dengan cara ini, Form1 mematuhi prinsip enkapsulasi saat menelepon! Tentu saja, kode-kode ini hanya untuk mencerminkan gagasan enkapsulasi. Dalam praktiknya, Anda dapat memutuskan apakah Anda benar-benar ingin menerapkannya secara menyeluruh sesuai dengan kebiasaan pribadi Anda. Namun pemikiran seperti ini harusnya mengakar di benak... (Belum selesai, bersambung).
Lebih banyak artikel