Mengapa ini dianggap sebagai praktik terbaik untuk mengemas kode program dan kode antarmuka grafis di kelas yang berbeda?

Jadi guru saya memberi tahu saya bahwa sangat penting untuk tidak merangkum kode program dan kode antarmuka grafis di kelas yang sama, Tetapi untuk menjaga mereka tetap independen. Saat ini saya sedang menulis game iphone dengan kisi di dalamnya. bagi saya itu jauh lebih masuk akal untuk Membuat grid grafis dan kode teknis di kelas "Grid" yang sama. Akankah programmer lain menyukai ini? Apakah memang sangat penting untuk menjaga antarmuka grafis dan kode independen. Masalah apa yang akan muncul jika saya tidak melakukannya?

Terima kasih!

Sunting: terima kasih kawan! Apakah saya boleh menulis proyek terlebih dahulu dan kemudian menyalin kode sekitar untuk membentuk desain pemisahan kekhawatiran. Saya tahu bahwa ini mungkin benar-benar mengalahkan tujuan, tetapi hanya sebagai latihan ... Sehingga lain kali saya dapat menerapkan pola desain ini sejak awal?

Konsep guru Anda mengacu pada sesuatu yang disebut Pemisahan Kekhawatiran.

Untuk mengilustrasikannya dalam konteks Anda, jika Anda menyelesaikan program Anda dan kemudian memutuskan ingin porting ke Android; Anda harus menulis ulang lebih banyak kode daripada jika Anda membiarkan logika grid tetap terpisah.

Kontrol antarmuka hanya harus peduli dengan menggambar apa yang diperintahkan, logika grid hanya harus peduli dengan apa yang ada di grid, bukan cara menggambarnya.

Apakah ini membantu ?

Untuk membuatnya lebih mudah untuk mengubah kode Anda . Bagaimana jika besok Anda tidak ingin menggunakan kisi tetapi daftar? Ketika GUI Anda terpisah dari logika Anda, itu mudah dilakukan.

Selain itu Anda akan menulis kode yang lebih dapat digunakan kembali . Jika GUI Anda tidak mengandung kode teknis, Anda juga dapat menggunakannya kembali. Buat kisi-kisi mewah dengan semua opsi sekaligus dan Anda dapat menggunakannya di proyek lain. Memadukan GUI dan kode teknis Anda akan mencegah Anda melakukan ini.

Ini juga memberi Anda kode yang lebih mudah dibaca. Jika kisi Anda hanya melakukan fungsi GUI, lebih mudah untuk memahami atau mengubah kode Anda.

Pendekatan umum pemrograman berorientasi objek untuk memisahkan masalah , di mana kode dipisahkan menjadi tugas logis. Awalnya, ini mungkin tampak seperti pekerjaan yang lebih banyak. Tetapi seiring proyek Anda tumbuh, itu membuatnya lebih mudah untuk melacak dan mengelola kode Anda.

Karena alasan itu, akan lebih baik memisahkan kode yang bertanggung jawab untuk menampilkan kisi dan kode yang berhubungan dengan data yang mungkin ditampilkan dalam kisi itu.

Ketika Separation of Concerns diterapkan pada struktur aplikasi, hasilnya adalah arsitektur multi-tier (atau arsitektur N-Tier) http://en.wikipedia.org/wiki/Multitier_architecture .

Untuk membangun jawaban lain dan memberi Anda contoh, Anda harus membiarkan diri Anda menyuntikkan logika / data ke dalam kisi Anda atau sebaliknya.

Kontrol kisi Anda dapat memaparkan Rendermetode atau DataBindmetode.

class GridControl
{
    public Render(GridData data) { ... }
}

atau

class GridControl
{
    public DataBind(GridData data) { ... }
}

Kemudian unit logis Anda dapat mengambil GridControl dan mengikat objek data ke sana atau secara manual memanggil render dengan objek data setiap kali ada perubahan.

GridLogic Anda juga harus memiliki referensi ke GridControl sehingga dapat mengikat setiap input / peristiwa yang terjadi.

Gagasan di balik pengikatan data adalah bahwa kontrol kisi Anda mengawasi data untuk setiap perubahan dan membuat ulang dirinya sendiri ketika mengekspos fungsi render berarti unit logika Anda secara manual membuat ulang kontrol.

Apa pun cara memisahkan logika dan kisi-kisi Anda seperti ini memungkinkan Anda untuk lebih mudah mengubah salah satu dari yang lain tanpa merusak apa pun. Anda juga dapat menulis kontrol baru seperti ListControluntuk menampilkan data Anda sebagai daftar alih-alih kisi tanpa harus menulis ulang semua logika Anda.

Saya sangat menyarankan Anda melihat arsitektur MVC .

Ini adalah penyempurnaan konsep yang telah Anda sebutkan (pemisahan kode program dan antarmuka grafis). MVC adalah singkatan dari Model-View-Controller. Di sini Model adalah datanya, View adalah kode antarmuka grafis dan COntroller adalah kode yang memproses data.

Dengan cara ini Anda telah membuat tiga bagian dari program Anda. Setiap bagian dapat diganti tanpa memerlukan perubahan di dua bagian lainnya.

Itu tergantung pada jenis perubahan di masa depan yang dapat Anda harapkan terjadi. Yang ingin Anda perkecil adalah jumlah perubahan kode manual yang diperlukan untuk mengimplementasikan setiap perubahan fungsional tunggal dengan benar.

Di mana MVC menang adalah jika perubahan terbatas pada bagian V, atau "Lihat".

Dalam pengalaman saya, kemungkinan besar perubahan itu mempengaruhi ketiga bagian, jadi lebih baik jika tidak dipisahkan. Untuk menunjukkan apa yang saya maksud, saya telah lama menggunakan teknik yang saya kembangkan yang disebut Dialog Dinamis , di mana persyaratan baru, seperti "izinkan pengguna untuk mengedit nama, dan ketika selesai melakukan XYZ" dimasukkan ke dalam kode sumber sebagai satu blok teks:

if(deTextEdit(&sName)){
  // do XYZ
}

alih-alih beberapa pengeditan terpisah, untuk menentukan bahwa bidang edit ada, untuk membuat pengidentifikasi unik untuknya, untuk mengikatnya ke variabel model, dan untuk menautkannya ke pengendali event yang kehilangan fokus.

Jika Anda membuka tautan itu, Anda akan melihat contoh yang lebih kompleks.

Pada dasarnya idenya adalah mengubah kode menjadi bahasa khusus domain, sehingga dapat meminimalkan jumlah pengeditan untuk mencapai tujuan. Alasan Anda ingin melakukan itu bukan hanya untuk mengurangi upaya, tetapi untuk mengurangi kesempatan untuk memperkenalkan bug, dengan melupakan atau salah mengode satu atau lebih suntingan. Ini juga mengurangi ukuran kode sumber secara kasar urutan besarnya.

Ini tidak gratis. Ini memperkenalkan kurva belajar satu kali untuk programmer.

Antarmuka grafis bergantung pada sistem, sedangkan inti permainan adalah suatu algoritma yang sepenuhnya independen dari sistem yang dijalankannya. Menjaga dua appart akan membuat program lebih mudah untuk mempertahankan, menguji dan men-debug karena perubahan dalam satu subsistem tidak mempengaruhi cara kerja yang lain. Bahkan jika Anda tidak peduli tentang portabilitas, saya yakin Anda peduli tentang ketahanan dan pemeliharaan program Anda.