Static Buat metode - pro dan kontra dibandingkan dengan konstruktor

Apa pro dan kontra dari memiliki metode pembuatan objek statis di atas konstruktor?

class Foo {
  private Foo(object arg) { }

  public static Foo Create(object arg) {
    if (!ValidateParam(arg)) { return null; }
    return new Foo(arg);
  }
}

Beberapa yang bisa saya pikirkan:

Pro:

Kembalikan nol alih-alih melempar pengecualian (beri nama TryCreate). Ini dapat membuat kode lebih singkat dan bersih di sisi klien. Klien jarang mengharapkan konstruktor gagal.
Buat berbagai jenis objek dengan semantik yang jelas, misalnya CreatFromName(String name)danCreateFromCsvLine(String csvLine)
Dapat mengembalikan objek yang di-cache jika perlu, atau implementasi yang diturunkan.

Cons:

Kurang dapat ditemukan, lebih sulit untuk membaca skim.
Beberapa pola, seperti serialisasi atau refleksi lebih sulit (misalnya Activator<Foo>.CreateInstance())

design-patterns

— dbkk
sumber

Lebih lambat. Anda harus tetap menangani referensi nol.

— Amir Rezaei

@Amir Menangani null adalah ( Foo x = Foo.TryCreate(); if (x == null) { ... }). Menangani pengecualian ctor adalah ( Foo x; try { x = new Foo(); } catch (SomeException e) { ... }). Saat memanggil metode normal, saya lebih suka pengecualian untuk kode kesalahan, tetapi dengan pembuatan objek, TryCreatetampaknya lebih bersih.

— dbkk

Apakah Anda dalam validasi Anda akan melakukan pengecekan tipe apa saja?

— Amir Rezaei

Sehubungan dengan Pro kedua, "Buat berbagai jenis objek dengan semantik yang jelas, misalnya CreatFromName (nama String) dan CreateFromCsvLine (String csvLine)", Anda mungkin lebih baik untuk membuat Namedan CsvLinemengetik, daripada mengungkapkan persyaratan melalui nama metode. Ini akan memungkinkan Anda untuk membuat berlebihan. Menggunakan string untuk keduanya dapat dianggap sebagai "obsesi primitif" (dengan asumsi Anda tidak membuat pilihan ini karena alasan kinerja yang diketahui). Lihatlah Object Calisthenics untuk mengetahui cara yang menyenangkan untuk menjelajahi ini.

— bentayloruk

Jawaban:

Kelemahan terbesar dengan ' pembuat ' statis mungkin membatasi pewarisan. Jika Anda atau pengguna perpustakaan Anda mendapatkan kelas dari Anda Foo, maka Foo::Create()menjadi sangat tidak berguna. Semua logika yang didefinisikan di sana harus ditulis ulang lagi di dalam warisan Create().

Saya akan menyarankan kompromi: mendefinisikan konstruktor dengan logika inisialisasi objek trivial yang tidak pernah gagal / melempar, kemudian mendefinisikan pencipta (s) dengan caching, konstruksi alternatif dll. Itu meninggalkan kemungkinan derivasi dan Anda mendapat manfaat dari memiliki pencipta untuk kelas tertentu .

— Mojuba
sumber

Dalam praktiknya itu sebenarnya bukan masalah, karena sebagian besar kelas tidak dirancang untuk diwarisi dari (dan karenanya harus disegel / final). Jika nanti ternyata Anda ingin membuka kelas ke pewarisan, Anda selalu dapat memindahkan logika inisialisasi ke konstruktor yang dilindungi.

— Doval

Buat adalah metode Pabrik. Ketika saya merasa perlu untuk ini, saya menerapkan pola Pabrik, dan mendefinisikan antarmuka untuk mewakili kontrak untuk membuat objek serta kelas pelaksana, yang kemudian akan disuntikkan di mana diperlukan. Ini mempertahankan keuntungan dari memindahkan tanggung jawab penciptaan keluar dari kelas, tetapi menghindari (atau setidaknya membuat lebih jelas) keterbatasan melakukan penciptaan objek di luar konstruktor kelas.

— quentin-starin
sumber