Java 8'in İsteğe Bağlı neden bağımsız değişkenlerde kullanılmamalıdır?

Birçok Web sitesinde okudum İsteğe bağlı bir dönüş türü olarak kullanılmalı ve yöntem bağımsız değişkenlerinde kullanılmamalıdır. Bunun mantıklı bir nedenini bulmak için uğraşıyorum. Örneğin, 2 isteğe bağlı parametreye sahip bir mantık parçam var. Bu nedenle yöntem imzamı bu şekilde yazmanın mantıklı olacağını düşünüyorum (çözüm 1):

public int calculateSomething(Optional<String> p1, Optional<BigDecimal> p2 {
    // my logic
}

Birçok web sayfası, isteğe bağlı olarak belirtilen yöntem bağımsız değişkenleri olarak kullanılmamalıdır. Bunu göz önünde bulundurarak, aşağıdaki yöntem imzasını kullanabilir ve argümanların boş olabileceğini belirtmek için açık bir Javadoc yorumu ekleyebilirim, gelecekteki koruyucular Javadoc'u okuyacak ve bu nedenle argümanları kullanmadan önce her zaman boş denetimler gerçekleştireceğini umarak :

public int calculateSomething(String p1, BigDecimal p2) {
    // my logic
}

Alternatif olarak, daha güzel bir arayüz sağlamak ve daha belirgin p1 ve p2'nin isteğe bağlı olmasını sağlamak için yöntemimi dört genel yöntemle değiştirebilirim (çözüm 3):

public int calculateSomething() {
    calculateSomething(null, null);
}

public int calculateSomething(String p1) {
    calculateSomething(p1, null);
}

public int calculateSomething(BigDecimal p2) {
    calculateSomething(null, p2);
}

public int calculateSomething(String p1, BigDecimal p2) {
    // my logic
}

Şimdi her yaklaşım için bu mantık parçasını çağıran sınıfın kodunu yazmaya çalışıyorum. Önce iki giriş parametresini Optionals döndüren başka bir nesneden alıyorum ve sonra çağırıyorum calculateSomething. Bu nedenle, çözüm 1 kullanılırsa, çağrı kodu şöyle görünecektir:

Optional<String> p1 = otherObject.getP1();
Optional<BigInteger> p2 = otherObject.getP2();
int result = myObject.calculateSomething(p1, p2);

çözüm 2 kullanılırsa, çağıran kod şöyle görünür:

Optional<String> p1 = otherObject.getP1();
Optional<BigInteger> p2 = otherObject.getP2();
int result = myObject.calculateSomething(p1.orElse(null), p2.orElse(null));

çözüm 3 uygulanırsa, yukarıdaki kodu kullanabilir veya aşağıdakileri kullanabilirim (ancak önemli ölçüde daha fazla kod):

Optional<String> p1 = otherObject.getP1();
Optional<BigInteger> p2 = otherObject.getP2();
int result;
if (p1.isPresent()) {
    if (p2.isPresent()) {
        result = myObject.calculateSomething(p1, p2);
    } else {
        result = myObject.calculateSomething(p1);
    }
} else {
    if (p2.isPresent()) {
        result = myObject.calculateSomething(p2);
    } else {
        result = myObject.calculateSomething();
    }
}

Öyleyse sorum: Optionals'yi yöntem argümanları olarak kullanmak neden kötü uygulama olarak değerlendiriliyor (bkz. Çözüm 1)? Benim için en okunabilir çözüm gibi görünüyor ve parametrelerin gelecekteki koruyucular için boş / boş olabileceğini en açık hale getiriyor. (Tasarımcıların Optionalyalnızca bir dönüş türü olarak kullanılması amaçlandığını biliyorum, ancak bu senaryoda kullanmamak için mantıklı nedenler bulamıyorum).

Oh, bu kodlama stilleri biraz tuzla alınmalı.

1. (+) İsteğe bağlı bir sonucun herhangi bir anlamsal analiz yapılmadan başka bir yönteme geçirilmesi; bunu yönteme bırakmak oldukça iyidir.
2. (-) Yöntemlerin içinde koşullu mantığa neden olan isteğe bağlı parametrelerin kullanılması, kelimenin tam anlamıyla kontra-üretkentir.
3. (-) İsteğe bağlı bir argümanı paketlemenin gerekmesi derleyici için yetersizdir ve gereksiz bir kaydırma yapar.
4. (-) Sıfırlanabilir parametrelerle karşılaştırıldığında İsteğe bağlı daha pahalıdır.

Genel olarak: İsteğe bağlı, çözülmesi gereken iki durumu birleştirir. Bu nedenle, veri akışının karmaşıklığı için girişten, sonuçtan daha uygundur.

Bu konuda gördüğüm en iyi gönderi Daniel Olszewski tarafından yazılmıştır :

Zorunlu olmayan yöntem parametreleri için isteğe bağlı olarak düşünmek cazip gelse de, böyle bir çözüm diğer olası alternatiflerle karşılaştırıldığında soluklaşır. Sorunu göstermek için aşağıdaki yapıcı bildirimini inceleyin:

public SystemMessage(String title, String content, Optional<Attachment> attachment) {
    // assigning field values
}

İlk bakışta doğru bir tasarım kararı gibi görünebilir. Sonuçta, attachment parametresini açıkça isteğe bağlı olarak işaretledik. Ancak, yapıcı çağrıldığında, istemci kodu biraz sakar hale gelebilir.

SystemMessage withoutAttachment = new SystemMessage("title", "content", Optional.empty());
Attachment attachment = new Attachment();
SystemMessage withAttachment = new SystemMessage("title", "content", Optional.ofNullable(attachment));

Netlik sağlamak yerine, İsteğe bağlı sınıfın fabrika yöntemleri yalnızca okuyucuyu dağıtır. Sadece bir isteğe bağlı parametre olduğunu unutmayın, ancak iki veya üç tane olduğunu düşünün. Bob Amca kesinlikle böyle bir kodla gurur duymazdı 😉

Bir yöntem isteğe bağlı parametreleri kabul edebildiğinde, kanıtlanmış yaklaşımı benimsemek ve yöntem aşırı yüklemesi kullanarak böyle bir durumu tasarlamak tercih edilir. SystemMessage sınıfı örneğinde, iki ayrı kurucunun bildirilmesi, İsteğe bağlı kullanımından daha üstündür.

public SystemMessage(String title, String content) {
    this(title, content, null);
}

public SystemMessage(String title, String content, Attachment attachment) {
    // assigning field values
}

Bu değişiklik, istemci kodunu daha basit ve okunmasını kolaylaştırır.

SystemMessage withoutAttachment = new SystemMessage("title", "content");
Attachment attachment = new Attachment();
SystemMessage withAttachment = new SystemMessage("title", "content", attachment);

OptionalParametre olarak kullanmamanın neredeyse hiçbir nedeni yoktur . Buna karşı olan argümanlar otoriteden gelen argümanlara dayanır (bkz. Brian Goetz - argümanı boş olmayan opsiyonları uygulayamamamızdır) ya da Optionalargümanların boş olabileceğidir (aslında aynı argüman). Elbette, Java'daki herhangi bir referans boş olabilir, programcıların belleğini değil (sorunlu ve ölçeksiz) kuralları derleyici tarafından uygulanmasını teşvik etmeliyiz.

Fonksiyonel programlama dilleri Optionalparametreleri teşvik eder . Bunu kullanmanın en iyi yollarından biri, birden fazla isteğe bağlı parametreye sahip olmak liftM2ve parametrelerin boş olmadığını ve isteğe bağlı olarak dönen bir işlevi kullanmaktır (bkz. Http://www.functionaljava.org/javadoc/4.4/functionaljava/fj/ data / Option.html # liftM2-fj.F- ). Java 8, maalesef isteğe bağlı destekleyen çok sınırlı bir kütüphane uygulamıştır.

Java programcıları olarak yalnızca eski kitaplıklarla etkileşim kurmak için null kullanmalıyız.

Bu tavsiye, "girdiler hakkında olabildiğince belirsiz ve çıktılar hakkında mümkün olduğunca spesifik" kuralının bir çeşitidir.

Genellikle düz null olmayan bir değer alan bir yönteminiz varsa, üzerinde eşleştirebilirsiniz Optional, böylece düz sürüm girdilerle ilgili olarak daha spesifik değildir. Bununla birlikte, Optionalyine de bir tartışmaya ihtiyaç duymanızın bir takım olası nedenleri vardır :

• işlevinizin bir döndüren başka bir API ile birlikte kullanılmasını istiyorsanız Optional
• OptionalVerilen değer boşsa işleviniz boş dışında bir şey döndürmelidir
• OptionalAPI'nızı kullanan her şey hakkında bilgi edinmek için o kadar harika olduğunu düşünüyorsunuz ;-)

İle desen geri dönmekOptional için biri içindir . Bir yönteme geçmek hala mükemmel bir şekilde mümkündür . nullnull

Bunlar henüz resmi olmasa da, işleve değerleri kabul edip etmediğinizi belirtmek için JSR-308 stil ek açıklamalarını kullanabilirsiniz null. Bunu gerçekten tanımlamak için doğru araçlara sahip olmanız gerektiğini ve uygulanabilir bir çalışma zamanı politikasından daha statik bir kontrol sağlayacağını unutmayın, ancak bu yardımcı olacaktır.

public int calculateSomething(@NotNull final String p1, @NotNull final String p2) {}

Bu benim için biraz aptalca görünüyor, ama düşünebilmemin tek nedeni, yöntem parametrelerindeki nesne argümanlarının zaten bir şekilde isteğe bağlı olması - boş olabilirler. Bu nedenle, birini mevcut bir nesneyi alıp isteğe bağlı olarak sarmaya zorlamak anlamsızdır.

Bununla birlikte, alma / iade opsiyonellerini bir araya getirme yöntemlerinin birlikte yapılması makul bir şeydir, örneğin Belki monad.

JDK10'da JavaDoc'a bakın, https://docs.oracle.com/javase/10/docs/api/java/util/Optional.html , bir API notu eklendi:

API Notu: İsteğe bağlı olarak öncelikle "sonuç yok" u temsil etmenin açık bir şekilde ihtiyaç duyulduğu ve null kullanmanın hatalara yol açabileceği bir yöntem döndürme türü olarak kullanılmak üzere tasarlanmıştır.

Benim almam, İsteğe bağlı bir Monad olmalı ve bunlar Java'da düşünülemez.

Fonksiyonel programlamada, argümanlarını yalnızca "işletme alanı türlerine" göre alan ve oluşturan saf ve daha üst düzey işlevlerle ilgilenirsiniz. Gerçek dünyayı (yan etkiler olarak adlandırılan) beslenen veya hesaplanması gereken işlevler oluşturmak için, dış dünyayı temsil eden monad'lardan değerleri otomatik olarak açmaya özen gösteren işlevlerin uygulanması gerekir (Devlet, Yapılandırma, Futures, Belki, Ya Yazar, vb ...); buna kaldırma denir. Bunu bir tür endişelerin ayrılması olarak düşünebilirsiniz.

Bu iki soyutlama düzeyini karıştırmak okunabilirliği kolaylaştırmaz, böylece bundan kaçınmanız daha iyi olur.

Bir Optionalas parametresini geçirirken dikkatli olmanın bir başka nedeni , bir yöntemin bir şey yapması gerektiğidir ... Bir Optionalparam geçirirseniz, birden fazla şey yapmayı tercih edebilirsiniz, boolean bir param geçirmeye benzer.

public void method(Optional<MyClass> param) {
     if(param.isPresent()) {
         //do something
     } else {
         //do some other
     }
 }

İsteğe bağlı olarak parametre olarak kabul etmek, arayan düzeyinde gereksiz sarmaya neden olur.

Örneğin:

public int calculateSomething(Optional<String> p1, Optional<BigDecimal> p2 {}

İki boş olmayan dizeniz olduğunu varsayalım (başka bir yöntemden döndürülen):

String p1 = "p1"; 
String p2 = "p2";

Boş olmadıklarını bilseniz bile onları İsteğe Bağlı olarak sarmak zorundasınız.

Diğer "eşlenebilir" yapılarla, yani. Eithers :

Either<Error, String> value = compute().right().map((s) -> calculateSomething(
< here you have to wrap the parameter in a Optional even if you know it's a 
  string >));

ref:

yöntemler parametre olarak seçenek beklememelidir, bu neredeyse her zaman arayandan arayan kişiye kontrol akışının sızıntısını gösteren bir kod kokusudur, bir opsiyonun içeriğini kontrol etmek arayanın sorumluluğunda olmalıdır.

ref. https://github.com/teamdigitale/digital-citizenship-functions/pull/148#discussion_r170862749

Ben genellikle verileri işlemek için Fonksiyonlarınızı yazmak ve sonra onu kaldırın çünkü olduğunu düşünüyorum Optionalkullanarak mapve benzeri fonksiyonlar. Bu, varsayılan Optionaldavranışı ekler . Tabii ki, üzerinde çalışan kendi yardımcı fonksiyonunuzu yazmanız gerektiğinde durumlar olabilir Optional.

Varlığın yankısı ilk önce İsteğe bağlı null olup olmadığını kontrol etmek ve sonra sardığı değeri değerlendirmek zorunda olduğuna inanıyorum. Çok fazla gereksiz doğrulama var.

Brian Goetz tarafından güzel açıklandığı gibi opsiyoneller bu amaç için tasarlanmamıştır .

Bir yöntem bağımsız değişkeninin boş olabileceğini göstermek için her zaman @Nullable öğesini kullanabilirsiniz . İsteğe bağlı bir yöntem kullanmak, yöntem mantığınızı daha düzgün yazmanıza olanak tanımaz.

Bir yaklaşım daha, yapabileceğiniz şey

// get your optionals first
Optional<String> p1 = otherObject.getP1();
Optional<BigInteger> p2 = otherObject.getP2();

// bind values to a function
Supplier<Integer> calculatedValueSupplier = () -> { // your logic here using both optional as state}

Bir işlev (bu durumda tedarikçi) oluşturduktan sonra, bunu başka bir değişken olarak aktarabilir ve kullanarak bu işlevi çağırabilirsiniz.

calculatedValueSupplier.apply();

Buradaki fikir, isteğe bağlı değere sahip olup olmamanız, işlevinizin dahili detayı olacak ve parametrede olmayacaktır. İsteğe bağlı olarak parametre olarak düşünürken düşünme işlevleri aslında bulduğum çok kullanışlı bir tekniktir.

Sorunuzla ilgili olarak gerçekten yapmanız gerekip gerekmemesi tercihinize bağlıdır, ancak diğerlerinin söylediği gibi API'nızı en az söylemek çirkin hale getirir.

İlk başta, Optionals'ı parametre olarak iletmeyi tercih ettim, ancak API-Designer perspektifinden API-User perspektifine geçerseniz, dezavantajları görürsünüz.

Her parametrenin isteğe bağlı olduğu örneğin, hesaplama yöntemini aşağıdaki gibi kendi sınıfına değiştirmenizi öneririm:

Optional<String> p1 = otherObject.getP1();
Optional<BigInteger> p2 = otherObject.getP2();

MyCalculator mc = new MyCalculator();
p1.map(mc::setP1);
p2.map(mc::setP2);
int result = mc.calculate();

Bu sorunun zor gerçeklerden ziyade fikirle ilgili olduğunu biliyorum. Ancak son zamanlarda bir .net geliştiricisi olmaktan çıkarak bir java geliştiricisine geçtim. Ayrıca, bunu bir yorum olarak belirtmeyi tercih ederim, ancak puan seviyem yorum yapmama izin vermediğinden, bunun yerine bir cevap olarak koymak zorunda kalıyorum.

Yaptığım şey, bana bir kural olarak iyi hizmet etti. Dönüş türleri için Optionals kullanmak ve parametreler olarak Optionals kullanmak, isteğe bağlı hem de hava durumu gerekir veya isteğe bağlı değil isteğe bağlı yöntem içinde bir değer vardı.

Ben sadece değer umurumda, ben yöntemi çağırmadan önce isPresent kontrol, eğer değer varsa bağlıdır yöntemi içinde günlük veya farklı bir mantık varsa, o zaman ben mutlu Opsiyonel geçer.

Bunun nedeni, bir API kullanıcısı ve bir API geliştiricisi için farklı gereksinimlerimiz olmasıdır.

Bir geliştirici kesin bir şartname ve doğru bir uygulama sağlamaktan sorumludur. Bu nedenle, geliştirici bir argümanın isteğe bağlı olduğunu zaten biliyorsa, uygulama null veya İsteğe bağlı olsun, bununla doğru bir şekilde ilgilenmelidir. API kullanıcı için olabildiğince basit olmalıdır ve null en basitidir.

Öte yandan, sonuç API geliştiricisinden kullanıcıya geçirilir. Şartname eksiksiz ve ayrıntılı olsa da, kullanıcının hala farkında olmadığından veya onunla başa çıkmak için tembel olma ihtimali vardır. Bu durumda, İsteğe bağlı sonuç kullanıcıyı olası boş bir sonuçla başa çıkmak için ekstra kod yazmaya zorlar.

Her şeyden önce, yöntem 3'ü kullanıyorsanız, son 14 kod satırını bununla değiştirebilirsiniz:

int result = myObject.calculateSomething(p1.orElse(null), p2.orElse(null));

Yazdığınız dört varyasyon kolaylık yöntemleridir. Bunları yalnızca daha uygun olduklarında kullanmalısınız. Bu da en iyi yaklaşım. Bu şekilde, API hangi üyelerin gerekli ve hangilerinin gerekli olmadığı çok açıktır. Dört yöntem yazmak istemiyorsanız, parametrelerinize nasıl ad verdiğinizi açıklığa kavuşturabilirsiniz:

public int calculateSomething(String p1OrNull, BigDecimal p2OrNull)

Bu şekilde, null değerlere izin verildiği açıktır.

Kullanımınız, p1.orElse(null)İsteğe Bağlı kullanırken kodumuzun ne kadar ayrıntılı olduğunu gösterir, bu da neden kaçındığımın bir parçasıdır. Fonksiyonel programlama için opsiyonel yazılmıştır. Akışların buna ihtiyacı var. Fonksiyonel programlamada kullanmanız gerekmedikçe yöntemleriniz muhtemelen asla İsteğe Bağlı döndürmemelidir. Optional.flatMap()İsteğe bağlı döndüren bir işleve başvuru gerektiren yöntem gibi yöntemler vardır . İşte imzası:

public <U> Optional<U> flatMap(Function<? super T, ? extends Optional<? extends U>> mapper)

Bu nedenle, genellikle İsteğe Bağlı döndüren bir yöntem yazmanın tek iyi nedeni budur. Ama orada bile, önlenebilir. İsteğe bağlı olmayan bir alıcıyı flatMap () gibi bir yönteme, işlevi doğru türe dönüştüren başka bir yöntemle sararak iletebilirsiniz. Sarma yöntemi şuna benzer:

public static <T, U> Function<? super T, Optional<U>> optFun(Function<T, U> function) {
    return t -> Optional.ofNullable(function.apply(t));
}

Diyelim ki böyle bir alıcıya sahipsin: String getName()

Bunun gibi flatMap'e geçiremezsiniz:

opt.flatMap(Widget::getName) // Won't work!

Ancak şu şekilde iletebilirsiniz:

opt.flatMap(optFun(Widget::getName)) // Works great!

Fonksiyonel programlama dışında Seçeneklerden kaçınılmalıdır.

Brian Goetz bunu söylediğinde en iyisini söyledi:

İsteğe Bağlı Java'nın eklenmesinin nedeni şudur:

return Arrays.asList(enclosingInfo.getEnclosingClass().getDeclaredMethods())
    .stream()
    .filter(m -> Objects.equals(m.getName(), enclosingInfo.getName())
    .filter(m ->  Arrays.equals(m.getParameterTypes(), parameterClasses))
    .filter(m -> Objects.equals(m.getReturnType(), returnType))
    .findFirst()
    .getOrThrow(() -> new InternalError(...));

bundan daha temiz:

Method matching =
    Arrays.asList(enclosingInfo.getEnclosingClass().getDeclaredMethods())
    .stream()
    .filter(m -> Objects.equals(m.getName(), enclosingInfo.getName())
    .filter(m ->  Arrays.equals(m.getParameterTypes(), parameterClasses))
    .filter(m -> Objects.equals(m.getReturnType(), returnType))
    .getFirst();
if (matching == null)
  throw new InternalError("Enclosing method not found");
return matching;