Yaratma sırasında değişken olan ancak daha sonra değiştirilemez olan üyelerle sınıf

Nesnelerin bir koleksiyonunu oluşturan bir algoritmaya sahibim. Bu nesneler yaratma sırasında değişkendir, çünkü çok az ile başlarlar, ancak algoritma içindeki farklı yerlerde verilerle doldurulurlar.

Algoritma tamamlandıktan sonra nesneler asla değiştirilmemelidir - ancak yazılımın diğer bölümleri tarafından tüketilirler.

Bu senaryolarda, aşağıda açıklandığı gibi sınıfın iki versiyonunun olması iyi bir uygulama olarak kabul edilir mi?

• Değişken bir algoritma tarafından oluşturulur, sonra
• Algoritmanın tamamlanmasından sonra, veriler döndürülen değişmez nesnelere kopyalanır.

Oluşturucu desenini belki de kullanabilirsiniz . Gerekli verileri toplamak amacıyla ayrı bir 'oluşturucu' nesne kullanır ve tüm veriler toplandığında gerçek nesneyi oluşturur. Oluşturulan nesne değişmez olabilir.

Bunu başarmanın basit bir yolu, birinin özellikleri okumasını ve sadece salt okunur yöntemleri çağırmasını sağlayan bir arayüze ve o sınıfı yazmanıza izin veren bu arayüzü uygulayan bir sınıfa sahip olmaktır.

Onu yaratan yönteminiz, öncekilerle ilgilenir ve daha sonra etkileşime girmesi için salt okunur bir arayüz sağlayan ikinciyi döndürür. Bu, kopyalamaya gerek duymaz ve arayan kişiye, yaratıcının aksine kolayca kullanmak istediğiniz davranışları kolayca ayarlamanıza olanak tanır.

Bu örneği ele alalım:

public interface IPerson 
{
    public String FirstName 
    {
        get;
    }

    public String LastName 
    {
        get;
    }
} 

public class PersonImpl : IPerson 
{
    private String firstName, lastName;

    public String FirstName 
    {
        get { return firstName; }
        set { firstName = value; }
    }

    public String LastName 
    {
        get { return lastName; }
        set { lastName = value; }
    }
}

class Factory 
{
    public IPerson MakePerson() 
    {
        PersonImpl person = new PersonImpl();
        person.FirstName = 'Joe';
        person.LastName = 'Schmoe';
        return person;
    }
}

Bu yaklaşımın tek dezavantajı, onu uygulayıcı sınıfa basitçe aktarmasıdır. Güvenlik meselesiyse, bu yaklaşımı kullanmak yeterli değildir. Bunun için bir geçici çözüm , arayanın çalıştığı ve iç nesneye erişemediği bir arayüz sunan değişken sınıfı sarmak için bir cephe sınıfı oluşturabilmenizdir .

Bu sayede oyuncu seçimi bile size yardımcı olmaz. Her ikisi de aynı salt okunur arayüzden türetilebilir, ancak döndürülen nesnenin dökülmesi yalnızca size sarılmış değiştirilebilir sınıfın temel durumunu değiştirmediğinden değiştirilemez olan Facade sınıfını verir.

Bunun, değişmez bir nesnenin bir kez ve herkes için kurucu aracılığıyla yapıldığı tipik eğilimi takip etmediğinden bahsetmeye değer. Anlaşılır, birçok parametreyle uğraşmak zorunda kalabilirsiniz, ancak kendinize tüm bu parametrelerin önceden tanımlanması gerekip gerekmediğini veya bazılarının daha sonra verilip verilmeyeceğini sormalısınız. Bu durumda, sadece gerekli parametreleri olan basit bir kurucu kullanılmalıdır. Başka bir deyişle, programınızdaki başka bir sorunu ele alıyorsa bu deseni kullanmayın.

Sen @JacquesB söylediği gibi Oluşturucu desen kullanmak veya alternatif seninkilerden bu nesneler aslında neden düşünebiliriz sahip oluşturulması sırasında değişken olması?

Başka bir deyişle, gerekli tüm değerleri kurucuya aktarmak ve bir seferde örnekler yaratmak yerine neden onları yaratma sürecinin zamana yayılması gerekiyor?

Çünkü Oluşturucu yanlış sorun için iyi bir çözüm olabilir.

Sorun, 10 parametre uzunluğundaki bir kurucu ile bitiyorsanız ve nesneyi azar azar oluşturarak hafifletmek istiyorsanız, tasarımın berbat olduğunu ve bu 10 değerin "olması gerektiğini gösterebilir" torbalanmış "/ birkaç nesneye gruplanmış ... veya ana nesne birkaç küçük parçaya bölünmüş ...

Bu durumda - tamamen değişmezliğe sadık kalın, tasarımı geliştirin.