Yapımcılar ve Fabrika Yöntemleri [kapalı]

Sınıfları modellerken, başlangıç ​​durumuna getirmenin tercih edilen yolu nedir:

1. Yapıcılar, veya
2. Fabrika Yöntemleri

Her ikisini de kullanmak için dikkat edilmesi gereken noktalar nelerdir?

Bazı durumlarda, nesne oluşturulamazsa null döndüren bir fabrika yöntemine sahip olmayı tercih ederim. Bu kodu düzgün yapar. Yapıcıdan bir istisna atmanın aksine, alternatif eylem yapmadan önce döndürülen değerin boş olup olmadığını kontrol edebilirim. (Şahsen istisnaları sevmiyorum)

Diyelim ki, bir sınıf üzerinde bir id değeri bekleyen bir yapıcı var. Yapıcı sınıfı veritabanından doldurmak için bu değeri kullanır. Belirtilen kimliğe sahip bir kaydın bulunmaması durumunda, yapıcı bir RecordNotFoundException oluşturur. Bu durumda tüm bu sınıfların yapımını bir try..catch bloğu içine almam gerekecek.

Bunun aksine, kayıt bulunmazsa null döndürecek olan bu sınıflar üzerinde statik bir fabrika yöntemi olabilir.

Bu durumda, yapıcı veya fabrika yönteminde hangi yaklaşım daha iyidir?

Tasarım Desenleri sayfa 108 : Gamma, Helm, Johnson ve Vlissides'in Yeniden Kullanılabilir Nesneye Yönelik Yazılım Öğeleri.

Aşağıdaki durumlarda Fabrika Yöntemi desenini kullanın

• bir sınıf yaratması gereken nesne sınıfını tahmin edemez
• bir sınıf alt sınıflarının oluşturduğu nesneleri belirtmesini ister
• sınıflar sorumluluğu birkaç yardımcı alt sınıftan birine devreder ve hangi yardımcı alt sınıfın temsilci olduğu bilgisini yerelleştirmek istersiniz

Kendinize ne olduklarını ve neden onlara sahip olduğumuzu sorun. İkisi de bir nesne örneği oluşturmak için oradalar.

ElementarySchool school = new ElementarySchool();
ElementarySchool school = SchoolFactory.Construct(); // new ElementarySchool() inside

Farkı yok. Şimdi çeşitli okul türlerimiz olduğunu ve ElementarySchool'u kullanmaktan Lise'ye (bir ElementarySchool'dan türetilen veya ElementarySchool ile aynı arayüzü uygulayan) geçmek istediğimizi düşünün. Kod değişikliği şöyle olur:

HighSchool school = new HighSchool();
HighSchool school = SchoolFactory.Construct(); // new HighSchool() inside

Bir arayüz durumunda:

ISchool school = new HighSchool();
ISchool school = SchoolFactory.Construct(); // new HighSchool() inside

Şimdi bu kodu birden fazla yerde varsa, fabrika yöntemini kullanmanın oldukça ucuz olabileceğini görebilirsiniz, çünkü fabrika yöntemini değiştirdikten sonra (ikinci örneği arayüzlerle kullanırsak).

Ve bu ana fark ve avantaj. Karmaşık bir sınıf hiyerarşileriyle uğraşmaya başladığınızda ve böyle bir hiyerarşiden dinamik olarak bir sınıf örneği oluşturmak istediğinizde aşağıdaki kodu alırsınız. Fabrika yöntemleri daha sonra yönteme hangi somut örneğin somutlaştırılacağını söyleyen bir parametre alabilir. Diyelim ki bir MyStudent sınıfınız var ve öğrencinizin o okulun bir üyesi olması için ilgili ISchool nesnesini başlatmanız gerekiyor.

ISchool school = SchoolFactory.ConstructForStudent(myStudent);

Artık uygulamanızda, farklı IStudent nesneleri için hangi ISchool nesnesinin somutlaştırılacağını belirleyen iş mantığını içeren bir yer var.

Yani - basit sınıflar için (değer nesneleri vb.) Yapıcı gayet iyi (uygulamanızı incelemek istemezsiniz) ancak karmaşık sınıf hiyerarşileri için fabrika yöntemi tercih edilen bir yoldur.

Bu şekilde dört tasarım çetesinden "Program bir uygulamaya değil, bir arayüze" ilk tasarım ilkesini takip edersiniz .

Etkili Java 2'yi (erişiminiz varsa) okumanız gerekir Öğe 1: Yapıcılar yerine statik fabrika yöntemlerini göz önünde bulundurun .

Statik fabrika yöntemleri avantajları:

1. İsimleri var.
2. Her çağrıldıklarında yeni bir nesne oluşturmaları gerekmez.
3. Dönüş türlerinin herhangi bir alt türündeki bir nesneyi döndürebilirler.
4. Parametreli tip örnekleri yaratmanın ayrıntı düzeyini azaltırlar.

Statik fabrika yöntemleri dezavantajları:

1. Yalnızca statik fabrika yöntemleri sağlanırken, genel veya korumalı kurucuları olmayan sınıflar alt sınıflara ayrılamaz.
2. Diğer statik yöntemlerden kolayca ayırt edilemezler

Varsayılan olarak yapıcılar tercih edilmelidir, çünkü anlaşılması ve yazılması daha kolaydır. Ancak, bir nesnenin yapım özelliklerini özellikle istemci kodu tarafından anlaşıldığı gibi anlamsal anlamından ayırmanız gerekiyorsa, fabrikaları kullanmak daha iyi olur.

Yapıcılar ve fabrikalar arasındaki fark, örneğin bir değişkene ve bir değişkene bir işaretçiye benzerdir. Bir dezavantaj olan başka bir dolaylama seviyesi daha vardır; ama başka bir esneklik seviyesi daha var, bu bir avantaj. Bu nedenle, bir seçim yaparken, fayda maliyetine karşı bu maliyeti yapmanız önerilir.

Bir fabrikayı yalnızca nesne oluşturma ile ekstra kontrole ihtiyaç duyduğunuzda, yapıcılarla yapılamayacak şekilde kullanın.

Örneğin fabrikaların önbellekleme olasılığı vardır.

Fabrikaları kullanmanın başka bir yolu, inşa etmek istediğiniz türü bilmediğiniz bir senaryodur. Genellikle, her eklentinin bir taban sınıfından türemesi veya bir tür arabirim uygulaması gereken eklenti fabrika senaryolarında bu tür bir kullanım görürsünüz. Fabrika, taban sınıftan türetilen veya arabirimi uygulayan sınıf örnekleri oluşturur.

"Etkili Java" dan bir alıntı, 2. baskı, Madde 1: Yapıcılar yerine statik fabrika yöntemlerini düşünün, s. 5:

" Statik bir fabrika yönteminin, Tasarım Desenlerindeki Fabrika Yöntemi ile aynı olmadığını unutmayın [Gamma95, s. 107]. Bu öğede açıklanan statik fabrika yönteminin Tasarım Desenlerinde doğrudan eşdeğeri yoktur."

Ek olarak "etkili java" (başka cevapta belirtildiği gibi), başka bir klasik kitap da öneriyor:

Aşırı yüklenmiş kurucular için statik fabrika yöntemlerini (bağımsız değişkenleri tanımlayan adlarla) tercih edin.

Örneğin. yazma

Complex complex = new Complex(23.0);

ama onun yerine yaz

Complex complex = Complex.fromRealNumber(23.0);

Kitap Complex(float), kullanıcıyı statik fabrika yöntemini çağırmaya zorlamak için yapıcıyı özel yapmayı önerecek kadar ileri gider .

CAD / CAM uygulamasından somut bir örnek.

Bir yapıcı kullanılarak bir kesme yolu yapılır. Kesim yolunu tanımlayan bir dizi çizgi ve yaydır. Çizgiler ve yaylar farklı olabilir ve farklı koordinatlara sahip olsa da, bir liste yapıcıya iletilerek kolayca ele alınabilir.

Bir fabrika kullanılarak bir şekil yapılır. Çünkü bir şekil sınıfı varken, her şekil, ne tür bir şekle bağlı olarak farklı şekilde ayarlanır. Kullanıcı bir seçim yapana kadar hangi şekli başlatacağımızı bilmiyoruz.

Diyelim ki, bir sınıf üzerinde bir id değeri bekleyen bir yapıcı var. Yapıcı sınıfı veritabanından doldurmak için bu değeri kullanır.

Bu süreç kesinlikle bir kurucu dışında olmalıdır.

1. Yapıcı veritabanına erişmemelidir.

2. Bir kurucunun görevi ve nedeni, veri üyelerini başlatmak ve kurucuya iletilen değerleri kullanarak sınıf değişmezi oluşturmaktır.

3. Her şey için daha iyi bir yaklaşım, statik fabrika yöntemini veya daha karmaşık durumlarda ayrı bir fabrika veya üretici sınıfını kullanmaktır.

Microsoft'tan bazı oluşturucu kılavuz satırları :

Yapıcıda çok az iş yapın. Yapıcılar, yapıcı parametrelerini yakalamak dışında çok fazla iş yapmamalıdır. Diğer işlemlerin maliyeti gerekene kadar ertelenmelidir.

Ve

İstenen işlemin anlambilimi doğrudan yeni bir örneğin yapısıyla eşleşmiyorsa, yapıcı yerine statik bir fabrika yöntemi kullanmayı düşünün.

Bazen bir nesne oluştururken bazı değerleri / koşulları kontrol etmeniz / hesaplamanız gerekir. Ve bir İstisna fırlatabilirse - constructro çok kötü bir yoldur. Yani böyle bir şey yapmanız gerekiyor:

var value = new Instance(1, 2).init()
public function init() {
    try {
        doSome()
    }
    catch (e) {
        soAnotherSome()
    }
}

Tüm ek hesaplamaların init () olduğu yerlerde. Ancak sadece geliştirici olarak bu init () hakkında bilgi sahibi olursunuz. Ve tabii ki, aylar sonra sadece unutuyorsun. Ancak bir fabrikanız varsa - bu init () öğesini doğrudan çağrıdan gizleyerek tek bir yöntemle yapmanız yeterlidir - bu yüzden sorun yok. Bu yaklaşımla, yaratılış ve hafıza sızıntısı ile ilgili hiçbir sorun yoktur.

Birisi size önbelleklemeden bahsetti. Bu iyi. Ama aynı zamanda Fabrika yolu ile kullanmak güzel Flyweight desen hakkında hatırlamak zorunda.