Veri aktarım nesneleri için arayüzler oluşturmalı mıyım?

Veri aktarım nesneleri için bir arayüz oluşturmak iyi bir fikir mi yoksa kötü bir fikir mi? Nesnenin genellikle değiştirilebilir olduğunu varsayarsak.

Örneğim Java'da olmasına rağmen, benzer kavramlara sahip diğer diller için geçerli olmalıdır.

interface DataTransferObject  {
    String getName();
    void setName(String name);
}

class RealDataTransferObject  implements DataTransferObject {

    String name;
    String getName() {
        return name;
    } 
    void setName(String name) {
        this.name = name;
    }
}

Tabii ki, bu basitleştirilmiş bir örnektir, gerçek hayatta daha fazla alan olabilir.

Genel cevap hayırdır , çünkü bunun için somut, somut bir neden olmadan hiçbir zaman kod eklememelisiniz ve böyle bir arayüzün genel bir nedeni yoktur.

Bununla birlikte, bazen iyi bir neden olabilir. Ancak gördüğüm tüm durumlarda, bu arayüzler kısmi idi, birden fazla sınıfın paylaştığı sadece bir veya birkaç özelliği kapsıyordu ve ortak bir üst sınıf vermeden polimorfik olarak kullanmak istedim. Tipik adaylar, bir Idtür kayıt defterinde kullanılacak bir Nameözellik veya kullanıcıya görüntülenecek bir özelliktir. Ancak, bazı kodların X XSourceiçeren her şeyi işlemesini istediğiniz her durumda yararlı olabilir - sadece getX(ve yalnızca gerekirse setX) yöntemlerini içeren bir arayüz oluşturun .

Ancak her model sınıfı için tüm özellikleri içeren ayrı bir arayüz? Bunu yapmak için iyi bir neden düşünemiyorum. Kötü bir neden, onu gerektiren kötü tasarlanmış bir çerçeve olabilir; Varlık EJB'leri doğru hatırlıyorsam, bunu yaptı. Neyse ki onlar asla çok fazla çekişme elde etmediler ve EJB 3.0'dan beri kullanımdan kaldırıldılar

Sidenote: Java değerlerini sadece önemsiz alıcılar ve ayarlayıcılarla tanımlamak için lütfen "değer nesnesi" terimini kullanmaktan kaçının - genellikle değiştirilemez kimliğe sahip olmayan bir kimlik olarak değer nesnesinin daha yaygın tanımıyla çakışır. Daha iyi bir terim DTO veya model sınıfı olacaktır - ikinci durumda anemik alan modellerinin bir karşıtlık olarak kabul edildiğine dikkat edin .

Arayüz oluşturma tamam, ancak örneğinizin çalışma şekli DEĞİL. Ayarlayıcıyı arayüzden kaldırmanız gerekir ve sorun olmaz:

interface ValueObject {
  String getName();
};

Bu, adın veritabanından alınabilmesi gibi birçok farklı uygulamaya izin verir ... Setter farklı arayüzde olmalıdır.

Arayüzler, arayüzleri uygulayan sınıflar ve müşterileri arasında bir sözleşme tanımlar. Bunlar, istemcilerin "belirli bir davranışı olan şeyleri" manipüle edebilmeleri için bir soyutlama mekanizması olarak kullanılır.

Yani "bu arayüzü oluşturmalı ve kullanmalı mıyım?" Sorusunun genel cevabı. : Evet, müşterilerinizle anlamsal olarak alakalı (tek bir kavram) kavramını ilişkilendirebiliyorsanız.

Örneğin, Karşılaştırılabilir iyi bir arayüzdür, çünkü yöntemlerden biri sayesinde şeylerin karşılaştırılabileceğini açıklar ve bir müşteri olarak karşılaştırılabilir nesnelerle (örneğin bunları sıralamak için) ilgilenmek isterim. Bir aksine, CoolStuff , serin nesnelerin belirli bir davranışa sahip olmadığını itiraf ederseniz iyi bir arayüz değildir (aslında, serin nesnelerle uğraşmanın mantıklı olduğu bir yazılım hayal edebilirsiniz, çünkü beCool gibi ortak bir davranışa sahiptirler. yöntem).

Sizin durumunuzda, arayüzünüzün yararsız olduğuna inanıyorum. Kim kullanacak, nasıl ve ne zaman? Değiştirilebilir değerlerin her biri için bir arabirim oluşturamazsınız. Öyleyse kendinize yöntemlerinizin ardındaki ilgili ve ilginç özelliklerin ne olduğunu sorun.

İstediğiniz tüm değişken değerleri birkaç yöntemle erişilebilen nesnelerle uğraşıyorsanız, Java fasulyesi kavramına ve sınıflarınızı sözleşmelerini benimsemeye nasıl zorlayabileceğinize bir göz atın.

Michael'ın dediği gibi, özel bir gereksiniminiz yoksa bir arayüz eklemeyin.

Test etmek iyi bir nedene bir örnektir. Aradığınızda sadece "değer nesneleri" iseler gerçek ortak çalışanlar kullanmayı tercih etsem de, gerçek birim testi yalıtımı için test için sahte bir nesne oluşturmanız gerekebilir, bu durumda bir arayüz oldukça yararlıdır.

Gelecekte bu nesnenin bir tür alan doğrulamasına sahip olmasını istiyorsanız, bunları erken aşamalarda kapsamına almalısınız.

'Değer nesnesi için arabirim' bir erişimci çağırmak için kullanılan şeydir.

Erişimcilerin ihtiyacına ilişkin farklı politikalar yaşadım. Bazı insanlar mümkün olduğu kadar savunurlar, bazıları ise yazılması gereken kod miktarını azaltmayı yasaklar.

Erişimciler için bazı gerekçeler (veya doğrudan değer kullanımı) şunlardır:

• Erişimciler daha sonra değerin depolanma şeklini değiştirmeye izin verir
• Accessors, yazılımınızda hata ayıklamak istediğinizde erişim günlüğü eklemenize izin verir (tek bir yöntemle bir günlük çağrısı eklerken, her değer değişikliğini yakalarsınız)
• Erişimciler nesne programlama ile daha uyumludur, her değişken yöntemlerle kapsüllenmiştir
• Erişimciler kod ifadesini azaltır (aynı sonuç için daha fazla SLOC)
• Erişimciler biraz CPU alıyor

Şahsen erişimci sayısını azaltmayı ve ayarlayıcının (setName) daha sonra basit bir şefkatten daha fazla olmasını beklediğinizde onları kullanmasını savunuyorum.

Bu tür bir değer nesnesi oldukça düşük seviyededir. Bunu iki yönden birine itmeyi öneririm: (1) değer nesnesini değişmez kılar, yani gerçek bir değer gibi , ya da (2) değişebilirliği daha üst düzey bir etki alanına yönelik iş işlevine yükseltiriz, yani açığa çıkarmalıyız etki alanı ile ilgili işlevsellik birimleri açısından arabirimler.