Doğrudan nesne yapımı yerine neden fabrika sınıfı kullanmalıyım?

GitHub ve CodePlex'te birçok С # ve Java sınıfı kütüphane projesinin tarihini gördüm ve doğrudan nesne örneklemesinin aksine fabrika sınıflarına geçme eğiliminde olduğumu görüyorum.

Fabrika sınıflarını neden yoğun kullanmalıyım? Nesnelerin eski moda yöntemlerle yaratıldığı oldukça iyi bir kütüphanem var - sınıfların kurucularını çağırarak. Son olarak, yazarlar binlerce sınıfın bütün kamu kurucularını içselliğe çabucak değiştirdi ve ayrıca CreateXXXsınıfların iç yapıcılarını çağırarak yeni nesneler döndüren binlerce statik yöntemle büyük bir fabrika sınıfı yarattı . Dış proje API'si bozuldu, aferin.

Neden böyle bir değişiklik faydalı olabilir? Bu şekilde yeniden yapılanmanın amacı nedir? Çağrıları genel sınıf kurucularına statik fabrika yöntemi çağrılarıyla değiştirmenin yararları nelerdir?

Kamu yapıcılarını ne zaman kullanmalıyım ve fabrikaları ne zaman kullanmalıyım?

Fabrika sınıfları, genellikle projenin SOLID ilkelerini daha yakından takip etmesine izin verdiği için uygulanır . Özellikle, arayüz ayrımı ve bağımlılık inversiyon ilkeleri.

Fabrikalar ve arayüzler çok daha uzun süreli esneklik sağlar. Daha dekuplajlı ve bu nedenle daha fazla test edilebilir - tasarıma izin verir. Bu yolda neden aşağıya inebileceğinizin ayrıntılı bir listesi:

• Kolayca bir Inversion of Control (IoC) konteyneri eklemenizi sağlar
• Arayüzlerle dalga geçebileceğinizden kodunuzu daha test edilebilir kılar
• Uygulamayı değiştirme zamanı geldiğinde size daha fazla esneklik kazandırır (yani bağımlı kodu değiştirmeden yeni uygulamalar oluşturabilirsiniz)

Bu durumu düşünün.

Meclis A (-> anlamına gelir):

Class A -> Class B
Class A -> Class C
Class B -> Class D

B Sınıfını Meclis A'ya bağlı olan B Meclisine taşımak istiyorum. Bu somut bağımlılıklarla tüm sınıf hiyerarşimin çoğunu taşımak zorundayım. Arabirimler kullanırsam, acıdan çok kaçınabilirim.

Meclis A:

Class A -> Interface IB
Class A -> Interface IC
Class B -> Interface IB
Class C -> Interface IC
Class B -> Interface ID
Class D -> Interface ID

Artık B sınıfını, hiçbir ağrısız olarak B montajına taşıyabilirim. Hala montaj A'daki arayüzlere bağlı.

Bağımlılıklarınızı çözmek için bir IoC kabı kullanmak size daha fazla esneklik sağlar. Sınıfın bağımlılıklarını değiştirdiğinizde her çağrıyı kurucuya güncellemeye gerek yoktur.

Arabirim ayrıştırma ilkesini ve bağımlılık inversiyon ilkesini izleyerek, son derece esnek, ayrıştırılmış uygulamalar oluşturmamızı sağlar. Bu tür uygulamalardan biri üzerinde çalıştıktan sonra, newanahtar kelimeyi tekrar kullanmak istemeyeceksiniz .

Gibi whatsisname dedi, ben bunun böyle olduğuna inanıyorum kargo kült yazılım tasarımı. Fabrikalar, özellikle de soyut tür, yalnızca modülünüz bir sınıfın birden çok örneğini oluşturduğunda ve bu modülün kullanıcısına hangi türün yaratılacağını belirleme yeteneği vermek istediğinizde kullanılabilir. Bu gereksinim aslında oldukça nadirdir, çünkü çoğu zaman sadece bir örneğe ihtiyacınız vardır ve bu örneği doğrudan açık bir fabrika oluşturmak yerine doğrudan geçebilirsiniz.

Mesele şu ki, fabrikaların (ve tektonların) uygulanması son derece kolaydır ve bu yüzden insanlar gerekmediği yerlerde bile onları çok kullanırlar. Peki programcı "Bu kodda hangi tasarım desenlerini kullanmalıyım?" Fabrika ilk akla gelen şey.

Pek çok fabrika kuruldu çünkü "Belki bir gün, bu sınıfları farklı şekilde yaratmam gerekecek". Bu YAGNI'nın açık bir ihlalidir .

IoC çerçevesini tanıttığınızda fabrikalar modası geçmiş oluyor, çünkü IoC sadece bir tür fabrika. Ve birçok IoC çerçevesi, belirli fabrikaların uygulamalarını oluşturabilir.

Ayrıca, CreateXXXyalnızca yapıcı olarak adlandırılan yöntemlerle devasa statik sınıflar oluşturduğunu söyleyen bir tasarım deseni yoktur . Ve özellikle bir Fabrika (ne de Soyut Fabrika) olarak adlandırılmaz.

Factory pattern vogue, "C-style" dillerinde (C / C ++, C #, Java) kodlayıcılar arasında "yeni" anahtar kelimenin kullanımının kötü olduğu ve her ne pahasına (veya en az merkezileşmiş). Bu da, Tek Sorumluluk İlkesinin (SOLID'in “S” si) ve ayrıca Bağımlılık İnversiyon İlkesinin (“D”) ultra katı bir yorumundan kaynaklanmaktadır. Basitçe ifade etmek gerekirse, SRP ideal olarak bir kod nesnesinin bir "değişim sebebi" ve bir tanesinin olması gerektiğini söyler; Bu "değişim nedeni", bu nesnenin temel amacı, kod tabanında "sorumluluğu" ve kodda değişiklik gerektiren başka bir şey, bu sınıf dosyasını açmayı gerektirmemelidir. DIP daha da basittir; Bir kod nesnesi asla başka bir somut nesneye bağlı olmamalıdır,

"Yeni" ve bir kamu kurucusu kullanarak, çağrı kodunu belirli bir somut sınıfın belirli bir yapım yöntemine bağlıyorsunuz. Kodunuz artık bir MyFooObject sınıfının var olduğunu bilmeli ve bir dize ve int alan bir yapıcıya sahip olmalıdır. Eğer bu kurucu daha fazla bilgiye ihtiyaç duyuyorsa, şu anda yazdığınız bilgiler de dahil olmak üzere bu bilgileri aktarmak için kurucunun tüm kullanımlarının güncellenmesi gerekir ve bu nedenle geçmek için geçerli bir şeyleri olması gerekir. onu almak için veya değiştirilerek (tüketen nesnelere daha fazla sorumluluk eklenmesi). Ayrıca, eğer MyFooObject, daha önce BetterFooObject tarafından kod tabanında değiştirilirse, eski sınıfın tüm kullanımlarının eskisinin yerine yeni nesneyi oluşturmak için değişmesi gerekir.

Bu nedenle, MyFooObject'in tüm tüketicileri, MyFooObject dahil sınıfları uygulama davranışını tanımlayan "IFooObject" e doğrudan bağlı olmalıdır. Şimdi, IFooObjects tüketicileri sadece bir IFooObject inşa edemezler (belirli bir somut sınıfın bir IFooObject olduğunu, ihtiyaç duymadıkları bir IFooObject olduğu bilgisine sahip olmadan), bu nedenle bunun yerine bir IFooObject-uygulayan sınıf veya yöntem örneği verilmelidir Dışarıdan, bizim durumumuzda genellikle bir Fabrika olarak bilinen durum için doğru IFooObject'in nasıl yaratılacağını bilmek sorumluluğuna sahip başka bir nesne tarafından.

Şimdi, işte teori gerçeği buluştuğu yer; bir nesne, her zaman her türlü değişikliğe asla kapatılamaz. İddiaya bakıldığında, IFooObject artık tüketicilerin talep ettiği arayüz veya IFooObjects uygulamaları değiştiğinde değişmesi gereken kod tabanındaki ek bir kod nesnesidir. Bu, nesnelerin bu soyutlama boyunca birbirleriyle etkileşimlerini değiştirme biçimiyle ilgili yeni bir karmaşıklık düzeyi ortaya koyuyor. Ayrıca, arayüzün kendisi yenisiyle değiştirilirse, tüketiciler hala değişmek zorunda kalacaklardır.

İyi bir kodlayıcı, YAGNI'yi ("İhtiyacınız Olmayacak") SOLID ile nasıl dengeleyeceğini, tasarımı analiz ederek ve belirli bir şekilde değişmesi muhtemel olan yerleri bularak ve onları daha hoşgörülü hale getirerek bilir. değişimin bu tip bu durumda çünkü "sen olan edeceksin gerek."

Yapıcılar kısa, basit kod içerdiklerinde iyidirler.

Başlatma, alanlara birkaç değişken atamaktan daha fazlası olduğunda, bir fabrika mantıklı olur. İşte faydalarından bazıları:

• Uzun, karmaşık kod adanmış bir sınıfta (bir fabrika) daha anlamlı olur. Aynı kod, bir grup statik yöntemi çağıran bir yapıcıya verilirse, bu ana sınıfı kirletir.

• Bazı dillerde ve bazı durumlarda, yapıcılara istisnalar atmak , hataya neden olabileceği için gerçekten kötü bir fikirdir .

• Bir yapıcı çağırdığınızda, arayan kişi, oluşturmak istediğiniz örneğin türünü bilmeniz gerekir. Bu (a olarak her zaman böyle değildir Feeder, sadece inşa gerekir Animal; bu bir olması umurumda değil beslemek amacıyla Dogveya Cat).

Arayüzlerle çalışıyorsanız, gerçek uygulamadan bağımsız kalabilirsiniz. Bir fabrika, çeşitli uygulamalardan birini örneklemek için (özellikler, parametreler veya başka bir yöntemle) yapılandırılabilir.

Basit bir örnek: bir cihazla iletişim kurmak istiyorsunuz ancak bunun Ethernet, COM veya USB üzerinden olup olmayacağını bilmiyorsunuz. Bir arayüz ve 3 uygulama tanımladınız. Çalışma zamanında, istediğiniz yöntemi seçebilir ve fabrika size uygun uygulamayı verecektir.

Sık kullan ...

Java / C # modül sistemlerinde bir sınırlama belirtisidir.

Prensip olarak, aynı kurucu ve yöntem imzalarıyla bir sınıfın bir uygulamasını bir başkasıyla değiştirememeniz için hiçbir neden yoktur. Orada olan buna izin dilleri. Bununla birlikte, Java ve C #, her sınıfın benzersiz bir tanımlayıcıya (tam nitelikli ad) sahip olması konusunda ısrarcıdır ve istemci kodu, üzerinde kodlanmış bir bağımlılıkla sona erer.

Sen edebilirsiniz çeşit dosya sistemi ve derleyici seçenekleri böylece kurcalıyor bu sorunu olsun com.example.Foofarklı bir dosyaya eşler, ancak bu şaşırtıcı ve unintuitive olduğunu. Bunu bile, kod edilir hala sınıfın tek uygulanmasına bağladılar. Yani, sınıfa Foobağlı bir sınıf MySetyazarsanız MySet, derleme zamanında bir uygulama seçebilirsiniz, ancak Fooiki farklı uygulama kullanarak bunları başlatamazsınız MySet.

Bu talihsiz tasarım kararı, insanları interfacedaha sonra farklı bir uygulamaya ihtiyaç duyma ihtimaline karşı veya kodlarını test etmek için gelecekteki kanıtlarını sağlamak için gereksiz yere kullanmaya zorlar . Bu her zaman mümkün değildir; Sınıfın iki örneğinin özel alanlarına bakan herhangi bir yönteminiz varsa, bunları bir arabirimde uygulayamazsınız. Bu yüzden, örneğin, unionJava'nın Setarayüzünde görmüyorsunuz . Yine de, sayısal türlerin ve koleksiyonların dışında, ikili yöntemler yaygın değildir, bu yüzden genellikle ondan kurtulabilirsiniz.

Tabii ki, eğer sizi ararsanız, new Foo(...)hala sınıfa bağımlısınızdır , bu yüzden bir sınıfın doğrudan bir arayüzü başlatabilmesini istiyorsanız bir fabrikaya ihtiyacınız vardır. Bununla birlikte, kurucudaki örneği kabul etmek ve hangi uygulamanın kullanılacağına başka birinin karar vermesine izin vermek genellikle daha iyi bir fikirdir.

Kod tabanınızı arabirimler ve fabrikalarla şişirmeye değip değmeyeceğine karar vermek size bağlıdır. Bir yandan, söz konusu sınıf kod tabanınızın içindeyse, kodu farklı bir sınıf veya arabirim kullanacak şekilde yeniden düzenlemek önemsizdir; Durum ortaya çıkarsa YAGNI ve refactor'ü daha sonra çağırabilirsin . Ancak, sınıf yayınladığınız bir kütüphanenin genel API'sinin bir parçasıysa, müşteri kodunu düzeltme seçeneğiniz yoktur. Eğer kullanmazsanız interfaceve daha sonra birden fazla uygulamaya ihtiyacınız varsa, bir kaya ile sert bir yer arasında sıkışıp kalacaksınız.

Benim düşünceme göre, sadece uygun bir tasarım deseni olmayan Basit Fabrikayı kullanıyorlar ve Soyut Fabrika veya Fabrika Yöntemi ile karıştırılmamalıdırlar.

Ve “binlerce CreateXXX statik yöntemiyle devasa bir kumaş sınıfı” yarattıklarından, bu bir anti-paterne (belki de bir Tanrı sınıfı olabilir) geliyor.

Simple Factory ve statik yaratıcı yöntemlerinin (harici bir sınıf gerektirmeyen) bazı durumlarda yararlı olabileceğini düşünüyorum. Örneğin, bir nesnenin inşası, diğer nesnelerin yerleştirilmesi gibi çeşitli adımlar gerektirdiğinde (örneğin kompozisyonu tercih etme).

Buna Fabrika demeyi bile söyleyemem, ancak rastgele bir sınıfta "Fabrika" ekiyle kapsanan birkaç yöntem.

Bir kütüphanenin kullanıcısı olarak, kütüphanenin fabrika yöntemleri varsa, bunları kullanmalısınız. Fabrika yönteminin kütüphane yazarına kodunuzu etkilemeden belirli değişiklikler yapma esnekliği sağladığını varsayıyorsunuz. Örneğin, basit bir kurucu ile çalışmayan bir fabrika yönteminde bazı alt sınıfların bir örneğini iade edebilirler.

Bir kütüphanenin yaratıcısı olarak, bu esnekliği kendiniz kullanmak istiyorsanız, fabrika yöntemlerini kullanırsınız.

Tarif ettiğiniz durumda, yapıcıları fabrika yöntemleriyle değiştirmenin sadece anlamsız olduğu izlenimini uyandırıyor gibi görünüyorsunuz. Bu, katılan herkes için kesinlikle bir acıydı; Bir kütüphane, API'sından hiçbir şeyi çok iyi bir sebep olmadan silmemelidir. Bu yüzden eğer fabrika metotları ekleseydim, bir fabrika metodu artık bu kurucuyu çağırmayacak ve mevcut düz kurucuyu kullanması gerektiğinden daha az işe yaramayacak şekilde kodlanıncaya kadar mevcut yapımcıları müsait bırakmayacaktım . İzleniminiz çok iyi olabilir.

Bu Scala ve fonksiyonel programlama çağında modası geçmiş gibi görünüyor. Sağlam bir fonksiyon temeli, bir gazillion sınıfının yerini almaktadır.

Ayrıca {{bir fabrika kullanırken Java'nın çiftinin artık çalışmadığını unutmayın.

someFunction(new someObject() {{
    setSomeParam(...);
    etc..
}})

Bu, anonim bir sınıf oluşturmanıza ve özelleştirmenize izin verebilir.

Zaman alanı ikileminde, zaman faktörü artık çok fazla küçülüyor, hızlı CPU'lar sayesinde, alanın küçülmesini sağlayan işlevsel programlama yani kod boyutu artık pratik.