Bagaimana Anda biasanya tata letak wilayah kelas?


17

Saya bertanya-tanya apakah ada standar untuk meletakkan daerah kelas.

Saat ini saya gunakan

Fields
Constructor
Properties
Public Methods
Private Methods

Fieldsmenjadi Properti Pribadi dan Propertiesmenjadi milik umum. Saya biasanya akan menggunakan subregional di dalamnya jika diperlukan, atau sesekali akan menambahkan daerah lain di bawah ini (seperti anggota antarmuka atau baseClass).


1
Apakah Anda berbicara tentang tata letak secara umum atau menggunakan "#regions"?
snmcdonald

1
@ snmcdonald Saya menggunakan #regiontag untuk mendefinisikan bagian
Rachel

Bukankah ini seharusnya menjadi pertanyaan wiki komunitas? Saya tidak percaya ada satu standar, dan jawabannya bisa berubah tergantung pada bahasa.
Raveline

7
Saya mulai dengan menghapus semua #regions
Ed S.

3
@ Ed S. +1 karena daerah adalah iblis. Semua yang mereka izinkan Anda lakukan adalah mengaburkan fakta bahwa file kode Anda terlalu besar dan perlu di refactored.
MattDavey

Jawaban:


4

Enum yang Berhubungan Dengan Kelas atau kadang-kadang struct / kelas data murni (di atas definisi kelas aktual)

--- Definisi kelas ---

Anggota pribadi

CTORs / DTORs jika bahasa tersebut memiliki DTORs

Properti publik

Metode utilitas (metode pribadi atau terlindungi dengan cakupan kecil)

Fungsionalitas kelas (Dapat dibagi menjadi beberapa wilayah tergantung pada ruang lingkup kelas).


17

Sub Wilayah? Apakah kelas Anda memiliki Tanggung Jawab Tunggal ? (tersirat dalam itu ... jawaban saya adalah "Jarang ada daerah, kecuali mungkin untuk mengelompokkan properti, konstruktor dan metode" ... tetapi meskipun begitu, saya tidak menggunakannya sebanyak itu)


2
Saya sedang memprogram dalam WPF sekarang dan contoh dari beberapa subregional yang akan saya gunakan adalah ViewModel yang memiliki properti publik yang dipecah menjadi properti terkait UI, Perintah, Data, dll. Ini membuatnya lebih mudah untuk menemukan apa yang saya mencari dengan cepat
Rachel

2
Mengapa tidak menggunakan spanduk komentar besar alih-alih wilayah? // ----------ViewModel Properties---------- Dengan begitu Anda masih dapat melihat kode (atau menciutkannya dengan menjabarkan dan melihat anggota). Daerah adalah untuk menyembunyikan sesuatu. Kode tidak boleh disembunyikan, kecuali jika dibuat otomatis atau apalah.
Kyralessa

1
@Rachel mendukung komposisi.
MattDavey

10

Saya hanya ingin mengkonfirmasi bahwa Anda bermaksud "#regions" dan bukan tata letak kelas secara umum.

Saya terkejut tidak ada yang disebutkan untuk menghindari penggunaan daerah. Saya mengerti OP ingin mengambil jajak pendapat tentang meletakkan wilayah, tapi saya ingin meningkatkan sudut pandang alternatif.

Saya menghindari daerah. Saya suka melihat kode yang saya kerjakan. Jika Anda merasa sulit untuk menemukan apa yang Anda cari maka gunakan kode lipat dan kelompok konstruksi kelas yang sama bersama-sama.

Mengapa saya membenci daerah? CTRL+M,Ldan CTRL+M,Oakan beralih kode lipat. Namun, ketika runtuh menyembunyikan seluruh wilayah. Saya hanya perlu menutup metode / properti / komentar.

Jika ada terlalu banyak daerah mungkin itu bau kode dan kelas Anda melakukan terlalu banyak pekerjaan. Jeff Atwood menyediakan pos yang bagus tentang daerah yang layak dibaca

Kutipan favorit saya di #regions:

Tidak, saya tidak akan menggunakan #regions. Dan tidak, AKU TIDAK NEGOSIASI DENGAN TERORIS. Diam.

- Jeff Atwood

Yang sedang berkata, saya tahu banyak programmer bersikeras menggunakannya. Pertanyaan ini subyektif. Saya hanya berpikir saya akan menawarkan alternatif.


1
Berikut ini adalah makro untuk runtuh-ke-definisi tetapi perluas wilayah, jika Anda terjebak bekerja dengan orang-orang yang terpikat pada daerah: stackoverflow.com/questions/523220/awesome-visual-studio-macros/… Ini berfungsi dengan baik kecuali Anda bekerja dengan orang yang benar-benar sakit yang menempatkan daerah dalam metode .
Kyralessa

Makro yang sangat berguna! Saya tidak yakin mengapa mereka tidak membangunnya menjadi studio visual, tidak terkecuali, terima kasih.
snmcdonald

Bos saya suka daerah, looooves mereka. Dia juga menyukai kelas batin pribadi dan metode besar. Kode kami memiliki satu kelas dengan sekitar selusin wilayah yang membaginya, 3 kelas dalam, dan beberapa metode selama mereka memiliki selusin daerah tingkat atas di dalamnya, dengan sub-wilayah di dalamnya.
CodexArcanum

4

Ini bervariasi dari bahasa ke bahasa. Karena saya seorang pembuat kode Delphi, saya cenderung mengikuti konvensi standar Delphi, yang terlihat seperti ini:

type
  TMyClass = class(TBaseClass)
  private
    private fields
    private methods
  protected
    protected fields
    protected methods
    protected properties
  public
    constructor(s)
    destructor
    public methods
    public properties
  end;

Saya menemukan cara yang bagus untuk mengatur informasi yang mudah dibaca dan dipahami.


3
Saya merasa sangat luar biasa bahwa pribadi, dilindungi, publik dan diterbitkan keduanya dipesan berdasarkan abjad dan enkapsulasi dan semuanya dimulai dengan P!
Peter Turner

lucu, saya tidak. Saya selalu menemukan bahwa lebih alami untuk mendaftar publicterlebih dahulu, karena sebagian besar pengguna hanya peduli tentang publichal - hal.
Matthieu M.

Saya selalu menemukan konvensi ini sebagai ide yang sangat konyol. Apa hubungan visibilitas dengan fungsionalitas? Bagaimanapun, saya selalu menggunakan Antarmuka untuk mendefinisikan fungsi publik, tetapi mengimplementasikan Antarmuka sebagai yang dilindungi di kelas. Satu-satunya item yang akan saya kelompokkan secara konsisten adalah metode dan properti yang dipublikasikan untuk komponen, dan jika tidak, saya selalu dikelompokkan berdasarkan Antarmuka dan pewarisan, menggunakan beberapa kata kunci visibilitas sesuai kebutuhan. Item-item yang unik untuk implementasi kelas (Yaitu: tidak menimpa) harus benar-benar didaftar terlebih dahulu.
S.Robins

3

Saya cenderung mengungkapkannya dengan cara berikut:

Public fields (usually static constants)
Constructors
Public methods
Private methods
Private fields

Belum menggunakan bahasa yang menggunakan Propertiesjadi itu sebabnya mereka tidak ditata. Saya menempatkan metode dan bidang pribadi di bagian bawah karena jika orang lain menggunakan file ini dalam kode mereka, mereka hanya perlu memusatkan perhatian pada API, yang merupakan barang publik. Dan semua editor teks yang saya tahu, dan bahkan IDE, menetapkan kursor di bagian atas saat membuka file.


+1 untuk menempatkan bidang pribadi di bagian bawah. Saya mengelompokkan metode publik dengan antarmuka yang mereka implementasikan, dan menempatkan mereka yang tidak mengimplementasikan antarmuka apa pun di atas, tepat setelah konstruktor / destruktor.
Sjoerd

2

Ini panggilan penghakiman bagi saya. Saya menggunakan daerah saat dibutuhkan untuk keterbacaan.

Saya juga menggunakan warna yang berbeda dalam skema warna Visual Studio saya (saat ini merah tua) untuk membuatnya menonjol dari sisa kode.


Contoh di mana saya mungkin menggunakan #region: Jika saya menulis metode pengujian untuk unit test yang membutuhkan potongan multi-baris XML, string XML akan mematahkan lekukan yang biasa (karena mulai sepanjang margin kiri dari jendela kode. Untuk menyembunyikan kejelekan, saya akan membungkusnya dalam #region, sehingga saya bisa menutupnya.


2

Buku Kode Bersih Bob Martin mendedikasikan seluruh bab ke 5 untuk memformat. Ada beberapa poin penting yang saya rangkum dengan baik.

  • Sebagian besar upaya untuk mengelompokkan variabel dan metode berdasarkan visibilitas dan kebersihan. Tidak masuk akal, dan menyebabkan Anda sering menavigasi kode.
  • Menjaga metode yang memanggil satu sama lain secara vertikal tertutup mengurangi jumlah navigasi yang perlu Anda lakukan, dan membuatnya lebih mudah untuk menemukan sesuatu.
  • Kereta pikiran Anda tidak akan rusak jika Anda harus berhenti dan berpikir "di wilayah mana kode ini termasuk?" setiap beberapa menit.
  • Variabel instan biasanya harus sedikit, dan kemungkinan akan digunakan di mana-mana, oleh karena itu mereka berada di bagian atas kelas di mana mereka akan lebih mudah untuk ditemukan. Variabel dan deklarasi yang hanya akan digunakan oleh satu metode harus ada di dalam metode itu. Jika hanya digunakan oleh beberapa metode, maka mereka harus ditutup secara vertikal tetapi di atas beberapa metode yang menggunakannya.

Menjaga kode Anda tersusun dengan elemen-elemen yang biasanya berinteraksi secara vertikal berdekatan bersama-sama secara efektif menghilangkan segala kebutuhan untuk membuat wilayah tertentu. Jika kode Anda terlalu panjang sehingga memerlukan daerah untuk menyembunyikan banyak kode, maka mungkin itu adalah bau kode yang menunjukkan bahwa kelas berusaha melakukan terlalu banyak. Mungkin beberapa fungsi dapat dipindahkan ke kelas utilitas, atau didorong ke leluhur.

Jika Anda perlu "menyembunyikan" kode karena terlalu lama atau terlalu "jelek", maka Anda mungkin memiliki masalah yang lebih besar untuk dikhawatirkan daripada menggunakan daerah atau tidak. Secara pribadi saya tidak perlu menggunakannya, dan ketika mengerjakan kode orang lain, saya merasa saya selalu harus membukanya semuanya, jadi mengapa repot-repot?


1
+1 - Saya terkejut bahwa ini tidak disebutkan secara lebih jelas. Prinsip kohesi juga berlaku pada cara Anda mengeluarkan kode, dan pengelompokan berdasarkan pengubah akses (lebih sering daripada tidak) kontra produktif.
Daniel B

0

Saat ini saya kelas tata letak seperti ini:

class types
constructors
destructor
accessors
methods
properties (where properties are present in the language)
member variables

dan kemudian awali level akses ke setiap deklarasi (semacam, terkadang dikelompokkan berdasarkan akses). Saya biasa melakukan pengelompokan tingkat atas dengan akses, tetapi pada suatu saat, saya tidak tahu kapan, itu tidak berfungsi sebaik di atas. Sebagai contoh di C ++ / CLI (yang saya terpaksa gunakan saat ini :-() Anda dapat melakukan ini, yang mengacaukan pengelompokan-oleh-akses:

public: property int SomeProperty
{
private: void set (int value) { ... }
public: int get () { ... }
}

Apa itu "anggota" di bagian bawah? Bagi saya itu istilah umum untuk semua bagian kelas.
Mason Wheeler

@ Alasan: harus menjadi "variabel anggota" untuk menghindari kebingungan.
Skizz

Saya benar-benar tidak mendapatkan pengelompokan berdasarkan jenis seperti itu. Apa perbedaan sebenarnya antara metode dan properti? Saya tidak pernah pergi mencari properti kelas, namun saya akan mencari kode yang terkait secara logis, apakah itu properti, metode, apa pun.
Ed S.

0

Jawaban orang gila: Saya tidak, paling tidak dalam soal C #. Antara Visual Studio dan R # saya secara ajaib dapat menavigasi ke anggota atau implementasi sehingga tidak ada gunanya terobsesi tentang hal ini; mulailah mengetik di mana kursor berada.


0

Seperti Wyatt dan beberapa jawaban lainnya, saya juga umumnya menghindari penggunaan wilayah. Daerah memiliki satu tujuan; untuk menyembunyikan kode yang tidak ingin Anda lihat. Jika Anda memiliki banyak kode dalam suatu kelas yang tidak ingin Anda lihat, dan karenanya Anda membutuhkan banyak daerah untuk memungkinkan Anda menutup kode tersebut, maka Anda mungkin memiliki terlalu banyak kode di dalam kelas. ReSharper tidak menghormati wilayah ketika memutuskan di mana menempatkan kode baru, kecuali jika itu menciptakan wilayah (yang dilakukannya untuk implementasi antarmuka).

Satu-satunya penggunaan daerah yang saya anggap dapat diterima adalah menyembunyikan kode "tidak dapat dihindari jelek"; kode yang berkaitan dengan detail implementasi spesifik yang tidak dapat dirancang dengan baik secara internal dengan standar saat ini. Ini biasanya canggih, kode esoterik yang umumnya tidak boleh dipusingkan oleh rata-rata programmer junior yang pernah ditulis. Ini adalah hal-hal seperti:

  • Implementasi antarmuka built-in tertentu (IDisposable, IConvertible, terkadang IEnumerable atau IComparable karena mereka membutuhkan implementasi generik dan non-generik)
  • Eksternal P / Aktifkan eksternal dan struktur terkait.
  • Finalizers / destructors (biasanya sesuai dengan IDisposable)
  • Kait ke kode memori / pointer / "tidak aman" yang tidak dikelola.
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.