Açık döküm işleç kullanımı benim için makul mü yoksa kötü bir saldırı mıdır?

Büyük bir nesnem var:

class BigObject{
    public int Id {get;set;}
    public string FieldA {get;set;}
    // ...
    public string FieldZ {get;set;}
}

ve özel, DTO benzeri bir nesne:

class SmallObject{
    public int Id {get;set;}
    public EnumType Type {get;set;}
    public string FieldC {get;set;}
    public string FieldN {get;set;}
}

Kişisel olarak açıkça BigObject'i SmallObject'e dökerek bir kavram buluyorum - bunun tek yönlü, veri kaybeden bir işlem olduğunu bilerek - çok sezgisel ve okunabilir:

var small = (SmallObject) bigOne;
passSmallObjectToSomeone(small);

Açık operatör kullanılarak uygulanır:

public static explicit operator SmallObject(BigObject big){
    return new SmallObject{
        Id = big.Id,
        FieldC = big.FieldC,
        FieldN = big.FieldN,
        EnumType = MyEnum.BigObjectSpecific
    };
}

Şimdi, bir yaratabilecek SmallObjectFactoryile sınıf FromBigObject(BigObject big), aynı şeyi bağımlılık enjeksiyon eklemek ve gerektiğinde çağırır yöntemi ... ama bana daha da fazla karmaşık ve gereksiz görünüyor.

PS Bunun konuyla alakalı olup olmadığından emin değilim, ancak bunun OtherBigObjectda SmallObjectfarklı bir hale getirilerek dönüştürülebileceği de olacaktır EnumType.

Diğer cevapların hiçbiri alçakgönüllü görüşüme göre doğru değil. Bu yığın akışı sorusunda en yüksek oyu alan cevap, eşleme kodunun etki alanının dışında tutulması gerektiğini savunuyor. Sorunuzu cevaplamak için, hayır - cast operatörünü kullanmanız iyi değildir. DTO'nuz ile etki alanı nesnesinin arasına oturan bir eşleme hizmeti yapmanızı öneririm, ya da bunun için otomatikleştirici kullanabilirsiniz.

Bu ... Harika değil. Bu akıllıca numarayı yapan ve kargaşaya yol açan kodla çalıştım. Ne de olsa, nesneler onları yayınlayacak kadar ilişkiliyse , sadece BigObjectbir SmallObjectdeğişkene atayabileceğinizi umuyorsunuz. Yine de çalışmaz - tip sistemi söz konusu olduğunda denendiyseniz derleyici hataları alırsınız, ilgisizler. Ayrıca, döküm operatörünün yeni nesneler üretmesi de hafif derecede dengesizdir.

Bunun .ToSmallObject()yerine bir yöntem tavsiye ederim . Aslında neler olup bittiği ve ayrıntılı olarak ne olduğu daha açık.

Neden bir ihtiyaç duyduğunuzu SmallObjectanlayabilsem de, soruna farklı bir yaklaşımla yaklaşırım. Bu tür meselelere yaklaşımım Cephe kullanmak . Tek amacı, kapsüllemek BigObjectve sadece belirli üyeleri mümkün kılmaktır. Bu şekilde, aynı durumda yeni bir arayüzdür, bir kopya değildir. Elbette bir kopyasını da yapmak isteyebilirsiniz, ancak bunu Cephe ile birlikte (örneğin return new SmallObject(instance.Clone())) bu amaçla oluşturulan bir yöntemle yapmanızı tavsiye ederim .

Cephe, bir takım başka avantajlara sahiptir; yani, programınızın belirli bölümlerinin yalnızca kendi cephenizde bulunan üyelerden faydalanabilmesini sağlayarak etkin bir şekilde bilmemesi gerekenleri kullanamayacağının garantisidir. Buna ek olarak BigObject, programınız boyunca nasıl kullanıldığı hakkında çok fazla endişelenmenize gerek kalmadan gelecekteki bakımda değişiklik yapma konusunda daha fazla esnekliğe sahip olmanız da büyük bir avantaja sahiptir . Eski davranışı herhangi bir şekilde veya başka şekilde taklit edebildiğiniz sürece, SmallObjecther yerde BigObjectkullanılmış olan programınızı değiştirmek zorunda kalmadan daha önce olduğu gibi çalışabilirsiniz .

Not, bu araç BigObjectbağlı SmallObjectdeğil, aksine başka bir yol bağlıdır (benim düşünceme göre olması gerektiği gibi).

Değişken referans türleri üzerindeki atmaların kimlik koruyucu olduğu konusunda çok güçlü bir kural vardır. Sistem genellikle kullanıcı tanımlı döküm operatörlerine, kaynak türünde bir nesnenin hedef tip referansına atanabileceği durumlarda izin vermediğinden, kullanıcı tanımlı döküm işlemlerinin değişken referans için makul olacağı birkaç durum vardır. türleri.

Söz konusu nesne iki yayın arasında değiştirilse bile, her ikisi de aynı nesneye uygulandığında, bir x=(SomeType)foo;süre sonra da takip edildiğinde y=(SomeType)foo;, x.Equals(y)her zaman ve her zaman doğru olması gerektiğini bir şart olarak önerebilirim . Böyle bir durum, örneğin birinin, her biri diğerine değişmez bir referansı olan ve her iki nesneyi diğer türüne çevirmek, eşleştirilmiş örneğini döndürürse, farklı türlerde bir çift nesneye sahipse uygulanabilir. Aynı zamanda, sarılmış nesnelerin kimlikleri değişmez olması koşuluyla değişken nesnelere sarıcı olarak hizmet veren türlerle de uygulanabilir ve aynı türde iki sarıcı, aynı koleksiyonu sarmaları durumunda kendilerini eşit olarak bildirir.

Özel örneğiniz değişken sınıflar kullanıyor, ancak hiçbir kimlik biçimini korumuyor; Bu nedenle, bir döküm operatörünün uygun bir kullanımı olmadığını söyleyebilirim.

Tamam olabilir.

Örneğinizle ilgili bir sorun, böyle örnek-ish isimleri kullanmanızdır. Düşünmek:

SomeMethod(long longNum)
{
  int num = (int)longNum;
  /* ... */

Eğer iyi bir fikrin olmasa da bunu Şimdi, neyi uzun ve int araçlar, daha sonra örtülü cast hem intetmek longve müstehcen dökme longiçin intoldukça anlaşılabilir. Ayrıca nasıl anlaşılır 3hale gelir 3ve birlikte çalışmak için sadece başka bir yoludur 3. Kontrollü int.MaxValue + 1bir bağlamda bunun nasıl başarısız olacağı anlaşılabilir . int.MaxValue + 1Sonuç olarak kontrol edilmeyen bir bağlamda nasıl çalışacağını bilmek bile int.MinValuezorlanacak en zor şey değil.

Benzer şekilde, açıkça bir temel türe veya açıkça türetilmiş bir türe attığınızda, mirasın nasıl olduğunu ve sonucun ne olacağını (veya nasıl başarısız olacağını) bilen herkes için anlaşılabilir.

Şimdi, BigObject ve SmallObject ile bu ilişkinin nasıl çalıştığı hakkında hiçbir fikrim yok. Döküm ilişkisinin açık olduğu yerlerde gerçek tipleriniz varsa, o zaman döküm gerçekten iyi bir fikir olabilir, ancak çoğu zaman, belki de büyük çoğunluğu, eğer durum buysa, o zaman sınıf hiyerarşisine ve kalıtım esaslı normal döküm yeterli olacaktır.