Davranışı belirlemek için bir boolean parametresi kullanmak yanlış mı?

Zaman zaman "yanlış" hisseden "bir uygulama gördüm, ama yanlış olanı açıkça ifade edemiyorum. Ya da belki de sadece önyargım. İşte gidiyor:

Bir geliştirici, bir boole yöntemini parametrelerinden biri olarak tanımlar ve bu yöntem başkalarını çağırır ve böyle devam eder ve nihayetinde boole yalnızca belirli bir işlem yapılıp yapılmayacağını belirlemek için kullanılır. Bu, örneğin, yalnızca kullanıcının belirli haklara sahip olması durumunda veya belki de test modunda veya toplu modunda veya canlı modda olduğumuzda (ya da olmadığımızda) ya da belki sadece sistemdeyken harekete izin vermek için kullanılabilir. belirli bir devlet.

Peki, bunu yapmak için her zaman başka bir yol vardır, ister eylemin zamanı geldiğinde sorgulayarak (parametreyi geçmek yerine), ya da yöntemin birden çok versiyonuna veya sınıfın birden fazla uygulamasına sahip olarak, vs. Bunun nasıl geliştirileceği çok fazla değil, bunun yerine gerçekten yanlış olup olmadığına bakalım (şüphelendiğim gibi) ve eğer öyleyse, bu konuda yanlış olan ne?

Evet, bu muhtemelen bir kod kokusudur, anlaşılması zor olan ve kolayca yeniden kullanılma şansı daha düşük olan ve sürdürülemez bir koda yol açacaktır.

Diğer afişlerin de belirttiği gibi , her şey ( her şeyden önce kapalıysa ya da uygulamanın kasıtlı olarak yapılmış teknik borç olarak kabul edildiyse kabul edildiyse ağır elden gitme), ancak daha sonra geçirilmiş bir parametre varsa genel olarak konuşun yürütülecek spesifik davranışı seçen bir fonksiyonun içine daha sonra adım adım iyileştirme yapılması gerekir; Bu işlevi daha küçük işlevlere bölmek, daha yüksek yapılı işlevler üretecektir.

Peki yüksek yapışma işlevi nedir?

Bir şeyi ve sadece bir şeyi yapan bir işlev.

Tanımladığınız gibi girilen bir parametreyle ilgili sorun, işlevin ikiden fazla şey yapmasıdır; Boolean parametresinin durumuna bağlı olarak kullanıcıların erişim haklarını kontrol edebilir veya etmeyebilir, daha sonra bu karar ağacına bağlı olarak bir işlevsellik gerçekleştirir.

Erişim Kontrolü endişelerini Görev, Eylem veya Komuta endişelerinden ayırmak daha iyi olacaktır.

Daha önce not ettiğiniz gibi, bu kaygıların iç içe geçmesi görünmektedir.

Bu nedenle, Yapışkanlık kavramı, söz konusu işlevin yüksek düzeyde yapışma olmadığını ve daha fazla sayıda yapışma işlevi üretmek için kodu yeniden düzenleyebileceğimizi belirlememize yardımcı olur.

Böylece soru yeniden ifade edilebilir; Hepimizin davranış seçimi seçiminden geçmek konusunda hemfikir olduğumuz göz önüne alındığında, en iyi şekilde kaçınılması durumunda sorunları nasıl geliştiririz?

Parametreden tamamen kurtulurdum. Test için bile erişim kontrolünü kapatma yeteneğine sahip olmak, potansiyel bir güvenlik riskidir. Test amacıyla , hem izin verilen erişimi hem de erişim reddedilen senaryoları test etmek için erişim kontrolünü saplayın veya alay edin.

Ref: Uyum (bilgisayar bilimi)

Çok basit bir nedenden ötürü bu kalıbı uzun süre önce kullanmayı bıraktım; bakım maliyeti. Birkaç kez frobnicate(something, forwards_flag), kodumda birçok kez çağrılan ve değerin değeri falseolarak iletilen koddaki tüm yerleri bulmam gerektiğini söyleyen bazı işlevler olduğunu öğrendim forwards_flag. Bunları kolayca arayamazsınız, bu da bakım baş ağrısına dönüşür. Ve bu sitelerin her birinde bir hata düzeltmeniz gerekiyorsa, birini kaçırırsanız talihsiz bir sorunla karşılaşabilirsiniz.

Ancak bu spesifik sorun, yaklaşımı temelden değiştirmeden kolayca çözülebilir:

enum FrobnicationDirection {
  FrobnicateForwards,
  FrobnicateBackwards;
};

void frobnicate(Object what, FrobnicationDirection direction);

Bu kodla, yalnızca bir örneğini aramanız gerekir FrobnicateBackwards. Bunu bir değişkene atayan bazı kodlar olması mümkün olsa da, birkaç kontrol dizisini izlemeniz gerekir, pratikte bu alternatifin işe yarayacak kadar nadir olduğunu gördüm.

Ancak, bayrağı bu şekilde, en azından prensipte geçirirken başka bir sorun var. Bu, bu tasarıma sahip bazı (sadece bazı) sistemlerin, kodun iç içe geçmiş bölümlerinin (bayrağı kullanan) dış katmanlara (bayrağını kullanan) dış katmanlara (hangi değeri geçeceğini bilmesi gereken) uygulama detayları hakkında çok fazla bilgi açığa çıkarabileceğidir. Bu bayrakta). Larry Constantine'nin terminolojisini kullanmak için, bu tasarım belirleyici ve Boole bayrağının kullanıcısı arasında aşırı güçlü bir bağlantıya sahip olabilir . Franky, kod temeli hakkında daha fazla bir şey bilmeden bu konuda herhangi bir kesinlikte kesin olarak söylemesi zor olsa da.

Verdiğiniz belirli örnekleri ele almak için, her ikisinde de bir dereceye kadar kaygı duyuyorum ancak esas olarak risk / doğruluk nedenleriyle. Diğer bir deyişle, sisteminizin hangi durumda olduğunu gösteren bayrakların etrafından geçmesi gerekiyorsa, bunu hesaba katması gereken, ancak parametreyi kontrol etmeyen kodunu aldığınızı görebilirsiniz (çünkü bu işlev). Demek ki bir hata var çünkü birisi parametreyi geçemez.

Neredeyse her işleve geçirilmesi gereken bir sistem durumu göstergesinin aslında küresel bir değişken olduğunu kabul etmek de önemlidir. Küresel bir değişkenin olumsuz taraflarının çoğu geçerli olacaktır. Birçok durumda, sistem durumu bilgisini (veya kullanıcının kimlik bilgilerini veya sistemin kimliğini) bu verilere dayanarak doğru hareket etmekten sorumlu olan bir nesne içinde saklamak daha iyi olur. Sonra ham verinin tersine o nesneye yapılan bir referansı iletirsiniz. Buradaki anahtar kavram kapsüllemedir .

Bu mutlaka yanlış değildir, ancak bir kod kokusunu temsil edebilir .

Boole parametreleriyle ilgili olarak kaçınılması gereken temel senaryo şöyledir:

public void foo(boolean flag) {
    doThis();
    if (flag)
        doThat();
}

Sonra aradığınızda genellikle arayacak foo(false)ve foo(true)istediğiniz tam davranışa bağlı olarak.

Bu gerçekten bir sorun çünkü kötü bir uyum durumu. Gerçekten gerekli olmayan yöntemler arasında bir bağımlılık yaratıyorsunuz.

Ne bu durumda yapması gereken ayrılıyor doThisve doThatayrı ve kamu yöntemleri gibi daha sonra yapıyor:

doThis();
doThat();

veya

doThis();

Bu şekilde arayana doğru bir karar bırakırsınız (aynen bir boole parametresini geçiyormuşsunuz gibi).

Tabii ki tüm boolean parametreler o kadar kötü bir şekilde kullanılmıyor, ancak kesinlikle bir kod kokusu ve kaynak kodunda çok şey görürseniz şüphelenmekte haklısınız.

Bu, yazdığım örneklere dayanarak bu sorunun nasıl çözüleceğine sadece bir örnektir. Farklı bir yaklaşımın gerekli olacağı başka durumlar da vardır.

Martin Fowler'tan aynı fikri daha ayrıntılı olarak açıklayan iyi bir makale var .

Not: Eğer fooiki basit yöntemi çağırmak yerine yöntem daha karmaşık bir uygulamaya sahipse, yapmanız gereken tek şey küçük bir yeniden düzenleme yöntemini kullanmaktır; böylece ortaya çıkan kod fooyazdığımın uygulamasına benzer .

Öncelikle: programlama, bir sanat olduğu kadar bir bilim değildir. Bu nedenle programın nadiren "yanlış" ve "doğru" bir yolu vardır. Çoğu kodlama standardı, yalnızca bazı programcıların faydalı olduğunu düşündüğü “tercihler” dir; ama sonuçta onlar keyfi. Bu yüzden, hiçbir zaman kendi içinde "yanlış" olacak bir parametre seçimini etiketlemem - kesinlikle bir boolean parametresi kadar genel ve kullanışlı bir şey değildir. Bir durumu boolean(veya bir intmaddenin bu durumu kapsüllemek için) kullanımı, çoğu durumda mükemmel bir şekilde haklı gösterilebilir.

Kodlama kararları, genel olarak performans ve sürdürülebilirliğe dayanmalıdır. Performans tehlikede değilse (ve örneklerinizde nasıl olabileceğini hayal bile edemiyorum), bir sonraki düşünceniz şu şekilde olmalı: bu benim (veya gelecekteki bir redaktörün) bakımı için ne kadar kolay olacak? Sezgisel ve anlaşılır mı? İzole edilmiş mi? Zincirleme işlev çağrılarının Kişisel örneği aslında bu açıdan potansiyel olarak kırılgan görünüyor yapar: Eğer değiştirmeye karar verirseniz sizin bIsUpiçin bIsDown, kaç başka yerlerde kodunda çok değişti gerekir? Ayrıca, paramater listeniz balon mu? İşlevinizde 17 parametre varsa, okunabilirlik bir sorundur ve nesne yönelimli mimarinin faydalarını takdir edip etmediğinizi yeniden düşünmeniz gerekir.

Bence Robert C Martins Clean kodu makalesi , bir yöntemin birden fazla şey yaptığını gösterdiklerinde mümkün olduğunda boolean argümanlarını ortadan kaldırmanız gerektiğini belirtir. Bir yöntem bir şey yapmalı ve sadece bence onun sloganlarından biri.

Bence buradaki en önemli şey pratik olmak.

Boolean davranışın tamamını belirlediğinde, sadece ikinci bir yöntem yapın.

Boole ortada yalnızca biraz davranış belirlediğinde, kod çoğaltmayı azaltmak için bir tanesinde tutmak isteyebilirsiniz. Mümkün olduğunda, yöntemi üçe bölebilirsiniz: Her iki boolean seçeneği için iki çağrı yöntemi ve biri işin büyük kısmını yapan.

Örneğin:

private void FooInternal(bool flag)
{
  //do work
}

public void Foo1()
{
  FooInternal(true);
}

public void Foo2()
{
  FooInternal(false);
}

Tabii ki, pratikte bu aşırı uçlar arasında her zaman bir noktaya sahip olacaksınız. Genelde sadece doğru olanı giderim, ama daha az kod çoğaltmanın yanında hata yapmayı tercih ederim.

Değişmez örnekleri döndüren oluşturucu yöntemlerle davranış özelleştirme yaklaşımını seviyorum. İşte GuavaSplitter bunu nasıl kullanıyor:

private static final Splitter MY_SPLITTER = Splitter.on(',')
       .trimResults()
       .omitEmptyStrings();

MY_SPLITTER.split("one,,,,  two,three");

Bunun faydaları:

• Üstün okunabilirlik
• Yapılandırma ve eylem yöntemlerinin açık bir şekilde ayrılması
• Sizi, nesnenin ne olduğu, ne yapması ve yapmaması gerektiği hakkında düşünmeye zorlayarak uyumu arttırır. Bu durumda bir Splitter. Asla someVaguelyStringRelatedOperation(List<Entity> myEntities)denilen bir sınıfa girmediniz Splitter, ancak bunu StringUtilssınıfa statik bir yöntem olarak koymayı düşünürdünüz .
• Örnekler önceden yapılandırılmıştır, bu nedenle kolayca bağımlılık enjekte edilebilir. Müşterinin doğru davranışı elde etmek için geçip geçmemek trueya falseda bir yöntem hakkında endişelenmesi gerekmez .

Kesinlikle bir kod kokusu . O ihlal etmiyorsa tek sorumluluk prensibi o zaman muhtemelen ihlal Do not Ask, söyle . Düşünmek:

• Yönteminizin kombinasyonları (ve, ama, vb.) Kullanmadan ne yaptığını özetleyebilir misiniz?
• Yöntemin alt bölümleri kolayca başka bir küçük yönteme gruplandırılabilir mi? (Bu, yerel bir değişkenin karmaşık oluşturulmasını içerir .)
• Bayrağınız bir parametrede hangi yöntemi çağıracağını belirlerse, parametreniz çok mu fazla yapıyor ?
• Bu yöntem parametrelerinizden birine mi ait? ( Alıcılar / ayarlayıcılar kullanarak parametrenizdeki örnek değişkenleri ayırıp ayırmadığını fark edebilirsiniz .)

Bu iki ilkeden birini ihlal etmediği ortaya çıkarsa, yine de enum kullanmalısınız. Boolean bayrakları, sihirli sayıların boolean karşılığıdır . foo(false)kadar mantıklı bar(42). Enums, Strateji Deseni için faydalı olabilir ve başka bir strateji eklemenize izin verme esnekliğine sahip olabilir. (Sadece onları uygun şekilde adlandırmayı unutmayın .)

Özel örneğiniz özellikle beni rahatsız ediyor. Bu bayrak neden bu kadar çok yöntemden geçiyor? Bu , parametrenizi alt sınıflara ayırmanız gerektiği gibi geliyor .

TL; DR: boolean argümanlarını kullanmayın.

Neden kötü olduklarını ve nasıl değiştirileceğini (koyu renkte) aşağıya bakın .

Boolean argümanlarının okunması çok zor ve bu nedenle de sürdürülmesi zor. Asıl sorun, argümanın isimlendirildiği yöntem imzasını okuduğunuzda, amaç genellikle açıktır. Bununla birlikte, çoğu dilde bir parametrenin adlandırılması genellikle gerekli değildir. Böylece RSACryptoServiceProvider#encrypt(Byte[], Boolean), boolean parametresinin, fonksiyonda ne tür şifreleme kullanılacağını belirlediği gibi anti-paternlere sahip olacaksınız .

Böylece şöyle bir çağrı alacaksınız:

rsaProvider.encrypt(data, true);

Okuyucunun, sadece cehennemin ne trueanlama gelebileceğini belirlemek için yöntemin imzasını araması gerekir . Bir tamsayı geçmek elbette ki kötü:

rsaProvider.encrypt(data, 1);

size söyleyeceğim kadar çok - daha doğrusu: çok az. Tamsayı için kullanılacak sabitleri tanımlasanız bile, işlevin kullanıcıları basitçe bunları görmezden gelebilir ve değişmez değerleri kullanmaya devam edebilir.

Bunu çözmenin en iyi yolu bir numaralandırma kullanmaktır . RSAPaddingİki değeri olan bir enum geçmek zorunda kalırsanız : OAEPveya PKCS1_V1_5hemen kodu okuyabilirsiniz:

rsaProvider.encrypt(data, RSAPadding.OAEP);

Booleanların yalnızca iki değeri olabilir. Bu, üçüncü bir seçeneğiniz varsa, imzanızı yeniden düzenlemek zorunda kalacağınız anlamına gelir. Genel olarak, geriye dönük uyumluluk bir sorunsa, bu kolayca gerçekleştirilemez, bu nedenle herhangi bir genel sınıfı başka bir genel yöntemle genişletmeniz gerekir. Microsoft RSACryptoServiceProvider#encrypt(Byte[], RSAEncryptionPadding), bir boole yerine bir numaralandırma (veya en azından bir numaralandırmayı taklit eden bir sınıf) kullandıkları yeri tanıttıklarında nihayet yaptıkları buydu .

Parametrenin kendisinin parametrelenmesi gerektiğinde parametre olarak tam bir nesne veya arayüz kullanmak daha kolay olabilir . Yukarıdaki örnekte OAEP dolgusunun kendisi dahili olarak kullanılacak karma değerle parametrelendirilebilir. Şimdi 6 SHA-2 karma algoritması ve 4 SHA-3 karma algoritması olduğunu unutmayın; bu nedenle, parametreler yerine yalnızca tek bir sayma kullanırsanız sayma değerlerinin sayısı artabilir (bu, Microsoft'un öğreneceği bir sonraki şeydir. ).

Boolean parametreleri ayrıca yöntemin veya sınıfın iyi tasarlanmadığını gösterebilir. Yukarıdaki örnekte olduğu gibi: .NET dışındaki herhangi bir şifreleme kitaplığı, yöntem imzasında bir doldurma bayrağı kullanmaz.

Neredeyse tüm sevdiğim yazılım guruları boolean argümanlara karşı uyarıyorlar. Mesela Joshua Bloch, çok beğenilen kitabı "Effective Java" ile onlara karşı uyardı. Genelde onlar kullanılmamalıdır. Anlaşılması kolay bir parametre olması durumunda kullanılabileceğini iddia edebilirsiniz. Ancak o zaman bile: Bit.set(boolean)Muhtemelen iki yöntem kullanılarak daha iyi uygulanır : Bit.set()ve Bit.unset().

Doğrudan kodu yeniden aktive edemiyorsanız , en azından daha okunaklı hale getirmek için sabitleri tanımlayabilirsiniz :

const boolean ENCRYPT = true;
const boolean DECRYPT = false;

...

cipher.init(key, ENCRYPT);

şundan çok daha okunur:

cipher.init(key, true);

sahip olsanız bile:

cipher.initForEncryption(key);
cipher.initForDecryption(key);

yerine.

Hiç kimsenin adlandırılmış parametrelerden bahsetmediğine şaşırdım .

Boolean bayrakları ile gördüğüm sorun onların okunabilirliği incitiyor olmasıdır. Örneğin, ne yaptığını trueiçinde

myObject.UpdateTimestamps(true);

yap? Hiç bir fikrim yok. Ama ne hakkında:

myObject.UpdateTimestamps(saveChanges: true);

Şimdi, geçtiğimiz parametrenin ne anlama geldiği açıktır: işleve değişiklikleri kaydetmesini söylüyoruz. Bu durumda, sınıf herkese açık değilse, boolean parametresinin iyi olduğunu düşünüyorum.

Tabii ki, sınıfınızdaki kullanıcıları adlandırılmış parametreleri kullanmaya zorlayamazsınız. Bu nedenle, enumvarsayılan durumunuzun ne kadar yaygın olduğuna bağlı olarak genellikle bir veya iki ayrı yöntem tercih edilir. Bu tam olarak ne olduğunu. Net yapar:

//Enum used
double a = Math.Round(b, MidpointRounding.AwayFromZero);

//Two separate methods used
IEnumerable<Stuff> ascendingList = c.OrderBy(o => o.Key);
IEnumerable<Stuff> descendingList = c.OrderByDescending(o => o.Key); 

Bu konuda neyin yanlış olduğunu açıkça ifade edemiyorum.

Bir kod kokusuna benziyorsa, bir kod kokusuna benziyor ve - iyi - bir kod kokusuna benziyor, muhtemelen bir kod kokusuna benziyor.

Yapmak istediğin şey:

1) Yan etkileri olan yöntemlerden kaçının.

2) gibi bir merkezi, yaygın durum makinesi (gerekli durumları Kolu Bu ).

Performansı belirlemek için Boole Parametrelerini kullanmanın tüm endişelerini kabul ediyorum; iyileştirin, Okunabilirlik, Güvenilirlik, Karmaşıklığı Düşürme, Kötü Kapsülleme ve Uyumluluk risklerini azaltın ve Bakım Kolaylığı ile Toplam Sahip Olma Maliyetini düşürün.

70'lerin ortalarında şimdi SCADA (denetim kontrolü ve veri toplama) olarak adlandırdığımız donanım tasarlamaya başladım ve bunlar EPROM'daki makro uzaktan kumandaları çalıştıran ve yüksek hızlı veri toplayan makine kodlu ince ayarlı donanımlardı.

Mantığa şu anda Sonlu Durumlu Makineler dediğimiz Mealey & Moore makineleri deniyor . Bunlar, sınırlı bir yürütme süresine sahip gerçek zamanlı bir makine olmadıkça ve aynı zamanda bu amaca hizmet etmek için kısayollar yapılması gerekmedikçe, yukarıdakilerle aynı kurallarda yapılmalıdır.

Veriler senkronizedir, ancak komutlar asenkrondir ve komut mantığı hafızasızlık Boolean mantığını izler ancak önceki, şimdiki ve istenen bir sonraki durumun hafızasına dayanan sıralı komutlarla. Bunun en verimli makine dilinde (sadece 64kB) çalışması için, her süreci bir sezgisel IBM HIPO tarzında tanımlamaya büyük özen gösterilmiştir. Bu bazen Boolean değişkenlerini geçmek ve indekslenmiş dallar yapmak anlamına geliyordu.

Ancak şimdi çok fazla bellek ve OOK kolaylığı ile Kapsülleme bugün önemli bir bileşendir, ancak kodun gerçek zamanlı olarak bayt olarak sayılması ve SCADA makine kodu.

Bu mutlaka yanlış değildir, ancak somut örneğinizde "kullanıcı" nın bazı niteliklerine bağlı olarak, bir bayraktan ziyade kullanıcıya yapılan bir referanstan geçeceğim.

Bu, çeşitli şekillerde netleşir ve yardımcı olur.

Çağrılı ifadeyi okuyan herkes sonucun kullanıcıya bağlı olarak değişeceğini fark edecektir.

Sonuç olarak adlandırılan işlevde, daha karmaşık iş kurallarını kolayca uygulayabilirsiniz, çünkü kullanıcı özelliklerinden herhangi birine erişebilirsiniz.

"Zincir" deki bir işlev / yöntem, bir kullanıcı özelliğine bağlı olarak farklı bir şey yaparsa, kullanıcı özelliklerine benzer bir bağımlılığın "zincir" deki diğer yöntemlerden bazılarına dahil olması muhtemeldir.

Çoğu zaman bu kötü kodlamayı düşünürdüm. Bununla birlikte, bunun iyi bir uygulama olabileceği iki durumu düşünebilirim. Neden kötü olduğunu söyleyen birçok cevap olduğu için, iyi olabileceği durumlarda iki kez teklif ediyorum:

İlki, sekanstaki her çağrının kendi başına mantıklı olmasıdır. Bu çağırarak kod eğer mantıklıdır olabilir yanlıştan doğruya veya false true değiştirilebilir, ya da denilen yöntem ise olabilir geçirmeden yerine doğrudan boolean parametresini kullanmak değiştirilebilir. Üst üste bu tür on çağrı olasılığı düşüktür, ancak olabilirdi ve eğer iyi bir programlama uygulaması olurdu.

İkinci durum, bir boolean ile uğraştığımız göz önüne alındığında biraz gerginlik. Ancak, programın birden fazla iş parçacığı veya olayı varsa, parametrelerin iletilmesi iş parçacığı / olaya özgü verileri izlemenin en kolay yoludur. Örneğin, bir program iki veya daha fazla soketten giriş alabilir. Bir soket için çalışan kodun uyarı mesajları üretmesi gerekebilir ve bir başkası için çalışan bir kod gerekmeyebilir. Daha sonra (çeşit) bir uyarı yönteminin, uyarı mesajlarının üretilebileceği yerlere iletilmesi için çok yüksek bir seviyeye ayarlanmış bir boolean için anlamlı olur. Çok sayıda iş parçacığı ya da bir araya getirilmiş olayların her birinin kendi değerine ihtiyacı olacağı için, veriler genel olarak herhangi bir türden büyük zorluklar dışında saklanamaz.

Emin olmak için, ikinci durumda muhtemelen kimin yalnızca içerik bir boolean bir sınıf / yapı oluşturmak istiyorum ve pas o etrafında yerine. Mesela çok uzun zaman önce başka alanlara ihtiyaç duyacağımdan emin olabilirdim - örneğin uyarı mesajlarının nereye gönderileceği gibi .

Bağlam önemlidir. Bu tür yöntemler iOS'ta oldukça yaygındır. Sık kullanılan bir örnek olarak, UINavigationController yöntemi sağlar -pushViewController:animated:ve animatedparametre bir BOOL olur. Yöntem esas olarak aynı işlevi yerine getirir, ancak YES'e geçerseniz bir görünüm denetleyiciden diğerine geçişi canlandırır ve HAYIR alamazsanız yapmaz. Bu tamamen makul görünüyor; Bunun yerine iki yöntem sunmak zorunda kalmanız aptalca olacaktır, böylece animasyonu kullanıp kullanmayacağınıza karar verebilirsiniz.

Objective-C'de bu tür bir şeyi doğrulamak daha kolay olabilir; burada yöntem adlandırma sözdizimi, her parametre için C ve Java gibi dillerde aldığınızdan daha fazla bağlam sağlar. Bununla birlikte, tek bir parametre alan bir yöntemin kolayca boolean olabileceğini ve hala mantıklı olabileceğini düşünüyorum:

file.saveWithEncryption(false);    // is there any doubt about the meaning of 'false' here?