Aşağıdaki (anti) desenin adı nedir? Avantajları ve dezavantajları nelerdir?

Son birkaç ay boyunca, aşağıdaki tekniği / kalıbı birkaç kez tökezledim. Ancak, belirli bir isim bulamıyorum, ne de tüm avantaj ve dezavantajlarından% 100 emin değilim.

Desen aşağıdaki gibi gider:

Bir Java arayüzünde, her zamanki gibi bir dizi ortak yöntem tanımlanır. Bununla birlikte, bir iç sınıf kullanıldığında, arabirimden varsayılan bir örnek sızdırılır.

public interface Vehicle {
    public void accelerate();
    public void decelerate();

    public static class Default {
         public static Vehicle getInstance() {
             return new Car(); // or use Spring to retrieve an instance
         }
    }
 }

Benim için en büyük avantaj, bir geliştiricinin sadece bir örnek oluşturmak istediği durumlarda, örneğin arayüzü hakkında değil uygulamaları hakkında bilmesi gerektiği gerçeğinde görünüyor.

 Vehicle someVehicle = Vehicle.Default.getInstance();
 someVehicle.accelerate();

Ayrıca, bu tekniğin, yapılandırmaya bağlı olarak dinamik olarak örnekler sağlamak amacıyla Spring ile birlikte kullanıldığını gördüm. Bu bakımdan, modülerleşmeye de yardımcı olabileceği gözüküyor.

Yine de, arayüzü uygulamalardan biriyle eşleştirdiği için bunun arayüzün kötüye kullanımı olduğu hissini sallayamıyorum. (Bağımlılık inversiyon ilkesi vb.) Herhangi biri bana bu tekniğin nasıl adlandırıldığını, avantajlarını ve dezavantajlarını açıklayabilir mi?

Güncelleştirme:

Bir süre göz önünde bulundurulduktan sonra, desenin aşağıdaki singleton versiyonunun çok daha sık kullanıldığını tekrar kontrol ettim ve fark ettim. Bu versiyonda, genel statik bir örnek yalnızca bir kez başlatılan arayüzden (alanın nihai olması nedeniyle) ortaya çıkar. Buna ek olarak, örnek hemen hemen her zaman Bahar veya uygulamadan arayüzü ayıran jenerik bir fabrika kullanılarak alınır.

public interface Vehicle {
      public void accelerate();
      public void decelerate();

      public static class Default {
           public static final Vehicle INSTANCE = getInstance();

           private static Vehicle getInstance() {
                return new Car(); // or use Spring/factory here
           }
      }
 }

 // Which allows to retrieve a singleton instance using...
 Vehicle someVehicle = Vehicle.Default.INSTANCE;

Özetle: Bunun temelde bir örneği veya bir singletonu arayüzü aracılığıyla göstermesini sağlayan özel bir singleton / fabrika modeli olduğu görülüyor. Dezavantajları ile ilgili olarak, aşağıdaki cevap ve yorumlarda birkaç kişi isimlendirilmiştir. Şimdiye kadar, avantaj kolaylık olarak görünüyor.

Default.getInstanceIMHO , singleton düzeninden alınan bir adlandırma kuralına uydurulmuş (ancak sonuncunun bir uygulaması olmadan), sadece çok özel bir fabrika yöntem biçimidir . Mevcut formda bu, " tek sorumluluk ilkesi " nin ihlalidir , çünkü arayüz (zaten bir sınıf API bildirme amacına hizmet eden), ayrı bir durumda çok daha iyi olacak olan varsayılan bir örnek sağlama sorumluluğunu üstlenir. sınıf.VehicleFactory

Bu yapının neden olduğu asıl sorun, Vehicleve arasında döngüsel bir bağımlılığa neden olmasıdır Car. Örneğin, şu anki biçimde Vehiclebir kütüphaneye ve Cardiğerine yerleştirmek mümkün olmayacak . Ayrı bir fabrika sınıfı kullanmak ve Default.getInstanceyöntemi oraya yerleştirmek bu sorunu çözecektir. Singleton ile ilgili herhangi bir karışıklığı önlemek için bu yönteme farklı bir ad vermek de iyi bir fikir olabilir. Yani sonuç gibi bir şey olabilir

VehicleFactory.createDefaultInstance()

Bu bana Null Object pattern benziyor .

Ancak bu, Carsınıfın nasıl uygulandığına büyük ölçüde bağlıdır . Eğer "nötr" şekilde uygulanırsa, kesinlikle bir Null nesnesidir. Bu, arabirimdeki tüm boş denetimleri kaldırabilir ve her biri yerine bu sınıfın örneğini koyabiliyorsanız null, kodun yine de düzgün çalışması gerekir.

Ayrıca, eğer bu modelse, arayüzün kendisi ile boş nesnenin uygulanması arasında sıkı bir bağlantı oluşturma problemi yoktur. Çünkü null nesne, bahsedilen arayüzün kullanıldığı her yerde olabilir.