Mengapa kita tidak awalan Enums, kelas dan Structs Abstrak?


11

Komunitas C # telah di mana-mana menggunakan awalan "I" untuk menunjukkan sebuah antarmuka yang bahkan para programmer yang paling tidak berpengalaman pun tahu untuk menggunakannya.

Mengapa kemudian kita tidak awalan enums, kelas abstrak atau struct (mungkin masing-masing dengan "E", "A" dan "S")?

Sebagai contoh, jika kita menandai semua kelas abstrak dengan "A", itu akan memberikan informasi berharga tentang jenis itu yang, meskipun dapat disimpulkan, tidak segera jelas.

Harap dicatat bahwa saya tidak mendukung perubahan ini, saya hanya mencoba memahami mengapa kita tidak melakukan hal-hal seperti ini.

Utas ini menjawab mengapa kami menggunakan awalan "I" tetapi tidak menjawab mengapa kami tidak menggunakan awalan lain.


3
Saya akan memilih duplikat dekat, tetapi jawabannya ada pada SO stackoverflow.com/questions/111933/...
Euphoric

1
@ Euphoric: Pertanyaan ini jauh lebih spesifik.
reinierpost


IMO Enums harus dihindari (diganti dengan anggota baca statis publik (pola enum)), kelas abstrak harus memiliki akhiran "basis", dan struct harus memiliki huruf kecil sebagai konvensi penamaan, tetapi karena .NET tidak melakukan itu, itu hanya akan membingungkan jika Anda membuat struct huruf kecil, karena itu tidak akan pernah konsisten.
Dave Cousineau

Mengapa Anda menghindari menggunakan enum demi menciptakan enued psuedo?
Stephen

Jawaban:


27

Inti dari konvensi penamaan untuk antarmuka adalah untuk memberikan keputusan yang cepat dan tanpa-otak tentang apa yang disebut antarmuka yang diimplementasikan oleh kelas Anda. Jika Anda memiliki Frobnicator, tetapi harus mendeklarasikan antarmuka untuk decoupling atau alasan apa pun, maka keputusan untuk memanggilnya tidak IFrobnicatormemerlukan pemikiran sadar, dan ini bagus.

Masalah yang sama tidak berlaku untuk konstruksi lain yang Anda sebutkan. Enums dan struct berguna, tetapi tidak perlu mencari nama kedua , pendek, transparan, yang jelas terkait selain nama itu sendiri. Oleh karena itu, tidak ada tekanan untuk menampar 'E' pada nama enum atau struct.

(Kelas abstrak agak mirip dengan antarmuka, karena Anda harus menyediakan kelas kedua yang konkret untuk menyelesaikan sesuatu, sehingga mereka mungkin telah memperoleh konvensi mulai dengan 'A', tetapi untuk alasan apa pun, mereka tidak. Jika Saya boleh berspekulasi, saya pikir 'saya' menjadi huruf yang sangat sempit mungkin ada hubungannya dengan itu.)


5
+1 Ini adalah jawaban yang saya tulis. Saya akan menunjukkan bahwa kelas abstrak sudah memiliki konvensi penamaan cromulent sempurna, di mana kelas abstrak bernama AnimalBasedan rasa yang berbeda AnimalGiraffe, AnimalLiondll
Binary Worrier

Mungkin layak disebutkan banyak antarmuka Java tidak menggunakan 'I', seperti List, karena sangat teknis bernama ArrayListdan LinkedListnama-nama implementasi. (C #, saya percaya, memiliki IListsebagai antarmuka, dan Listsebagai daftar array)
Katana314

Saya bertanya-tanya apakah itu mungkin telah membantu, jauh ketika, bagi Microsoft untuk merekomendasikan bahwa variabel tipe struktur "yang dapat berubah" diberi awalan tertentu, untuk menghindari kebingungan tentang apakah Point p = myPoints[3]; p.X += 3;akan mempengaruhi myPoints[3].X. Secara retrospektif, saya lebih suka menggunakan C # var->fielduntuk akses bidang-kelas dan var.fielduntuk akses bidang-bidang, tetapi jelas tidak. Namun, tampaknya cara sekilas untuk membedakan mereka akan sangat membantu.
supercat

1

Saya pikir itu tidak banyak digunakan karena:

  • sebagian besar waktu itu tidak mater banyak jika itu adalah enum, atau kelas abstrak atau struct
  • jika itu mater saya mungkin bisa melihatnya dari penggunaan dan jika tidak cukup cepat mencari tahu
  • jika saya mengubahnya menjadi enum, kelas abstrak atau struct, saya juga harus mengganti nama itu
  • untuk orang-orang yang tidak tahu konvensi itu adalah kebisingan murni.
  • orang mungkin hanya menolak seluruh gagasan karena mereka telah diajarkan untuk tidak menggunakan notasi Hongaria. Ada dan masih ada orang yang mengatakan Anda tidak boleh menggunakan notasi Hungarion, tanpa membuat perbedaan antara Aplikasi Hungaria dan Sistem Hungaria. Diskusi yang bagus dapat ditemukan dalam pertanyaan SO ini . Bukan hanya jawaban pertama yang menarik tetapi ada jawaban dan komentar yang bagus. Dari pertanyaan yang sama muncul artikel ini oleh Joel Spolsky (gulir ke paragraf "Saya Hongaria")

Singkatnya: Secara umum nilai tambah tidak menambah biaya.

Dari poin terakhir dan beberapa interpretasi Anda bisa menyimpulkan. Sistem Hongaria (tipe awalan) buruk dan tidak boleh digunakan. Aplikasi Hungaria (jenis awalan) telah digunakannya.

Mengambil kembali pertanyaan Anda, saya pikir notasi yang Anda usulkan adalah bentuk Aplikasi Hungaria dan jika Anda merasa bahwa nilai tambahnya menambah biaya dan Anda menerapkannya secara konsisten dalam basis kode Anda, itu baik-baik saja. Tetapi karena Anda harus mempertimbangkannya berdasarkan proyek, itu seharusnya tidak menjadi aturan umum.

Saya kira orang-orang memperhatikan bahwa itu memang untuk antarmuka lebih sering dan itulah sebabnya itu telah menjadi aturan umum untuk antarmuka.


-1

Hanya pemikiran (semoga berlaku):

Ada kecenderungan yang jelas menuju 'coding to interfaces' daripada kelas-kelas yang konkret. "Saat ini" tampaknya lebih bermanfaat untuk memiliki konvensi penamaan untuk kelas-kelas, seperti memulai mereka dengan 'C', daripada memiliki huruf 'I' untuk antarmuka.

Saya baru saja mengakhiri proyek Java di mana semua Antarmuka benar-benar disebut Model .. Yap, konvensi nama antarmuka adalah untuk mengakhiri nama dengan 'Model' ... kemudian minta semacam 'DataTransferObject / DTO' mengimplementasikan antarmuka sebagai :

public interface SomethingModel{
}

public class Something implements SomethingModel{
    //lets not line up braces and make it hard to read
    //at least it saves one line
}

sedangkan di C #

public interface ISomething{}

public class SomethingModel : ISomething
{
   //i can read this
}

Memberi rewiring otak saya untuk menjaga agar tetap lurus, tetapi saya bisa melihat bagaimana hal itu mungkin membantu untuk berpikir tentang pemrograman ke antarmuka.

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.