Değerleri belirlemek için bir boolean parametresi kullanmak yanlış mı?

Göre bu davranışını belirlemek için bir boolean parametresini kullanmak yanlış mı? , Bir davranışı belirlemek için boolean parametreleri kullanmaktan kaçının önemini biliyorum, örneğin:

Orijinal versiyon

public void setState(boolean flag){
    if(flag){
        a();
    }else{
        b();
    }
    c();
}

Yeni sürüm:

public void setStateTrue(){
    a();
    c();
}

public void setStateFalse(){
    b();
    c();
}

Fakat boolean parametresinin davranışlar yerine değerleri belirlemek için kullanılması durumunda? Örneğin:

public void setHint(boolean isHintOn){
    this.layer1.visible=isHintOn;
    this.layer2.visible=!isHintOn;
    this.layer3.visible=isHintOn;
}

İsHintOn bayrağını kaldırmaya çalışıyorum ve 2 ayrı fonksiyon oluşturmaya çalışıyorum:

public void setHintOn(){
    this.layer1.visible=true;
    this.layer2.visible=false;
    this.layer3.visible=true;
}

public void setHintOff(){
    this.layer1.visible=false;
    this.layer2.visible=true;
    this.layer3.visible=false;
}

ancak değiştirilmiş sürüm daha az bakım gerektiriyor çünkü:

1. Orijinal versiyondan daha fazla kod içeriyor

2. katman 2'nin görünürlüğünün ipucu seçeneğinin zıttı olduğunu açıkça gösteremez.

3. yeni bir katman (örneğin: layer4) eklendiğinde, eklemem gerekiyor

   this.layer4.visible=false;
   

   ve

   this.layer4.visible=true;  
   

   setHintOn () ve setHintOff () 'a ayrı ayrı

Öyleyse benim sorum, eğer boolean parametresi sadece değerleri belirlemek için kullanılıyorsa, fakat davranışlarda bulunmuyorsa (örneğin: bu parametrede başka bir if yoksa), hala bu boolean parametresini ortadan kaldırmak için tavsiye edilir mi?

API tasarımı, arayan bir taraftan , bir API müşterisi için en kullanışlı olana odaklanmalıdır .

Örneğin, bu yeni API arayanın böyle düzenli kod yazmasını gerektiriyorsa,

if(flag)
    foo.setStateTrue();
else
    foo.setStateFalse();

öyleyse, parametreden kaçınmanın, arayan kişinin yazmasına izin veren bir API'ye sahip olmasından daha kötü olduğu açık olmalıdır.

 foo.setState(flag);

Eski versiyon sadece o zaman arayan tarafında (ve muhtemelen bir kereden fazla) çözülmesi gereken bir sorun yaratır. Bu ne okunabilirliği ne de sürdürülebilirliği arttırmaz.

Ancak uygulama tarafı , genel API'nin nasıl göründüğünü belirlememelidir. setHintParametre gibi bir fonksiyonun uygulamada daha az kod gerektirmesi, ancak bir müşteri için kullanımı setHintOn/ terimleri açısından setHintOffdaha kolay görünen bir API olması durumunda , aşağıdaki şekilde uygulayabilirsiniz:

private void setHint(boolean isHintOn){
    this.layer1.visible=isHintOn;
    this.layer2.visible=!isHintOn;
    this.layer3.visible=isHintOn;
}

public void setHintOn(){
   setHint(true);
}

public void setHintOff(){
   setHint(false);
}

Bu nedenle, genel API'nin boolean parametresi olmamasına rağmen, burada yinelenen mantık yoktur, bu nedenle yeni bir gereksinim (soru örneğinde olduğu gibi) geldiğinde değiştirilecek tek yer vardır.

Bu aynı zamanda diğer yollarda da işe yarar setState: Yukarıdaki yöntemin iki farklı kod parçası arasında geçiş yapması gerekiyorsa, bu kod parçaları iki farklı özel yönteme yeniden yansıtılabilir. Yani IMHO, “bir parametre / bir yöntem” ile “sıfır parametreler / iki yöntem” arasında içsellere bakarak karar vermek için bir kriter aramak mantıklı değildir. Bununla birlikte, API'yi tüketici rolünde görmek istediğiniz şekilde bakın.

Şüpheniz varsa, sizi genel API ve bunun nasıl kullanılacağı hakkında düşünmeye zorlayacak "test odaklı geliştirme" (TDD) kullanmayı deneyin.

Martin Fowler, Kent Beck'ten ayrı setOn() setOff()yöntemler önermekten alıntı yapar ancak aynı zamanda bunun dokunulmaz olarak görülmemesi gerektiğini söyler:

Eğer böyle bir kullanıcı arayüzü denetimi veya veri kaynağı olarak bir boolean kaynağından [sic] veriyi, çekme, ben tercih ederdim setSwitch(aValue)daha

if (aValue)
  setOn();
else
  setOff();

Bu, arayanın işini kolaylaştıracak bir API'nin yazılması gerektiği bir örnektir, bu yüzden arayanın nereden geldiğini biliyorsanız, API'yi bu bilgiler göz önünde bulundurarak tasarlamalıyız. Bu ayrıca, arayanları her iki şekilde elde edersek, bazen her iki stili de sağlayabileceğimizi savunuyor.

Başka bir öneri , içeriğe özgü isimler vermek ve daha iyi hale getirmek için numaralandırılmış bir değer veya bayrak tipi kullanmaktır . Örnekte ve daha iyi olabilirdi.truefalseshowHinthideHint

Bence yazınızda, API ve uygulamada iki şeyi karıştırdığınızı düşünüyorum. Her iki durumda da, her zaman kullanabileceğiniz güçlü bir kural olduğunu düşünmüyorum, ancak bu iki şeyi bağımsız olarak düşünmelisiniz (mümkün olduğunca).

Her ikisi de: API ile başlayalım:

public void setHint(boolean isHintOn)

ve:

public void setHintOn()
public void setHintOff()

Nesnenizin sunması gerekenlere ve müşterilerinizin API'yi nasıl kullanacaklarına bağlı olarak geçerli alternatiflerdir. Doc'un belirttiği gibi, kullanıcılarınız zaten bir Boolean değişkenine sahipse (bir UI kontrolünden, bir kullanıcı eyleminden, harici bir API'den, vb.), İlk seçenek daha mantıklı olur, aksi halde sadece müşterinin kodunda bir if if ifadesi zorlarsınız . Bununla birlikte, örneğin bir işleme başlarken ipucunu true olarak değiştiriyorsanız ve sonunda false yapıyorsanız, ilk seçenek size şöyle bir şey verir:

setHint(true)
// Do your process
…
setHint(false)

ikinci seçenek size şunu verir:

setHintOn()
// Do your process
…
setHintOff()

Hangi IMO çok daha okunaklı, bu durumda ikinci seçeneğe geçeceğim. Açıkçası, hiçbir şey sizi iki seçenek de önermekten alıkoyamaz (ya da daha fazlası, örneğin Graham’in dediği gibi enum kullanabilirsiniz).

Önemli olan, API'nızı, nesnenin ne yapması gerektiğine ve nasıl uygulayacağınıza bağlı olarak istemcilerin nasıl kullanacağına bağlı olarak seçmeniz gerektiğidir.

O zaman genel API'nizi nasıl uygulayacağınızı seçmelisiniz. Diyelim ki yöntemleri setHintOnve setHintOffgenel API'mız olarak seçtik ve bu ortak mantığı örneğinizdeki gibi paylaşıyorlar. Bu mantığı özel bir yöntemle (Doc'tan kopyalanan kod) kolayca soyutlayabilirsiniz:

private void setHint(boolean isHintOn){
    this.layer1.visible=isHintOn;
    this.layer2.visible=!isHintOn;
    this.layer3.visible=isHintOn;
}

public void setHintOn(){
   setHint(true);
}

public void setHintOff(){
   setHint(false);
}

Bunun tersine, setHint(boolean isHintOn)bir API seçtiğimizi varsayalım, ancak ipucunu Açık olarak ayarlamak nedenini Kapalı olarak ayarlamaktan tamamen farklı olduğu için örneğinizi tersine çevirelim. Bu durumda aşağıdaki gibi uygulayabiliriz:

public void setHint(boolean isHintOn){
    if(isHintOn){
        // Set it On
    } else {
        // Set it Off
    }    
}

Ya da:

public void setHint(boolean isHintOn){    
    if(isHintOn){
        setHintOn()
    } else {
        setHintOff()
   }    
}

private void setHintOn(){
   // Set it On
}

private void setHintOff(){
   // Set it Off 
}

Mesele şu ki, her iki durumda da, önce genel API'mızı seçtik ve daha sonra uygulamalarımızı seçilen API'ye (ve sahip olduğumuz kısıtlamalara) uygun şekilde uyarladık.

Bu arada, aynısının davranışı belirlemek için bir boolean parametresi kullanma hakkında bağladığınız gönderi için de geçerli olduğunu düşünüyorum, yani bazı zor kurallardan ziyade belirli kullanım durumunuza dayanarak karar vermelisiniz (ancak bu durumda genellikle yapılacak doğru şey Birden çok işlevde onu kırmak).

İlk önce ilk şeyler: kod biraz daha uzun olduğu için otomatik olarak daha az bakım gerektirmez. Netlik önemli olan şeydir.

Şimdi, gerçekten sadece verilerle ilgileniyorsanız, sahip olduğunuz şey bir boolean özelliği için belirleyicidir. Bu durumda, doğrudan bu değeri doğrudan depolamak ve katman görünürlüklerini elde etmek isteyebilirsiniz.

bool isBackgroundVisible() {
    return isHintVisible;
}    

bool isContentVisible() {
    return !isHintVisible;
}

^{(Katmanlara gerçek isimler verme özgürlüğünü aldım - eğer orijinal kodunuzda yoksa, onunla başlardım)}

Bu hala bir setHintVisibility(bool)yönteme sahip olup olmadığı sorusu ile size bırakır . Şahsen, onu showHint()ve hideHint()yöntemiyle değiştirmenizi tavsiye ederim - her ikisi de gerçekten basit olacak ve katman eklediğinizde bunları değiştirmek zorunda kalmayacaksınız. Ancak bu kesin olarak doğru / yanlış değil.

Şimdi eğer işlev çağırmak aslında bu katmanların görünürlüğünü değiştirmeli ise, aslında davranışınız var. Bu durumda kesinlikle ayrı yöntemler önerebilirim.

İkinci örnekte Boole parametreleri iyi. Zaten anladığınız gibi, boole parametreleri kendi başlarına problemli değildir. Sorunlu olan bir bayrağa dayanan davranışını değiştiriyor.

İlk örnek problemlidir, çünkü adlandırma bir belirleyici yöntemi gösterir, ancak uygulamalar farklı bir şey gibi görünmektedir. Yani davranış değiştirme antipattern ve yanıltıcı olarak adlandırılmış bir yöntem var. Fakat eğer yöntem aslında normal bir belirleyici ise (davranış değiştirme olmadan), o zaman sorun olmaz setState(boolean). İki yönteme sahip olmak setStateTrue()ve setStateFalse()faydası olmadan gereksiz yere işleri karmaşıklaştırmaktır.

Bu sorunu çözmenin bir başka yolu, her ipucunu temsil edecek bir nesne sunmak ve bu ipucu ile ilişkili boolean değerlerini belirlemekten nesnenin sorumlu olmasını sağlamaktır. Bu şekilde, sadece iki boolean duruma sahip olmak yerine, yeni permütasyonlar ekleyebilirsiniz.

Örneğin, Java’da şunları yapabilirsiniz:

public enum HintState {
    SHOW_HINT(true, false, true),
    HIDE_HINT(false, true, false);

    private HintState(boolean layer1Visible, boolean layer2Visible, boolean layer3Visible) {
         // constructor body and accessors omitted for clarity
    }
}

Ve sonra arayan kodunuz şöyle görünür:

setHint(HintState.SHOW_HINT);

Uygulama kodunuz şöyle görünür:

public void setHint(HintState hint) {
    this.layer1Visible = hint.isLayer1Visible();
    this.layer2Visible = hint.isLayer2Visible();
    this.layer3Visible = hint.isLayer3Visible();
}

Bu, uygulama kodunu ve arayan kodunu özlü bir şekilde tutar, açıkça yazılan, belirtilen durum kümelerine yönelik niyetleri açıkça tanımlayan yeni bir veri türünü tanımlamak yerine . Bence bu her yerde daha iyi.

Öyleyse benim sorum, eğer boolean parametresi sadece değerleri belirlemek için kullanılıyorsa, fakat davranışlarda bulunmuyorsa (örneğin: bu parametrede başka bir if yoksa), hala bu boolean parametresini ortadan kaldırmak için tavsiye edilir mi?

Böyle şeyler hakkında şüphelerim olduğunda. Yığın izinin nasıl göründüğünü hayal etmeyi seviyorum.

Uzun yıllar boyunca setter ve getter ile aynı işlevi kullanan bir PHP projesi üzerinde çalıştım . Eğer boş atarsanız , değeri döndürür, aksi takdirde ayarlayın. Çalışmak korkunçtu .

İşte bir yığın iz örneği:

function visible() : line 440
function parent() : line 398
function mode() : line 384
function run() : line 5

İç durum hakkında hiçbir fikriniz yoktu ve hata ayıklamayı zorlaştırıyordu. Başka olumsuz yan etkileri de var, ancak işlevler tek bir işlem gerçekleştirdiğinde ayrıntılı işlev adında ve netlikte bir değer olduğunu görmeye çalışın .

Şimdi bir boolean değerine dayalı A veya B davranışı olan bir işlev için yığın iziyle çalışan resmi.

function bar() : line 92
function setVisible() : line 120
function foo() : line 492
function setVisible() : line 120
function run() : line 5

Bana sorarsan bu kafa karıştırıcı. Aynı setVisibleçizgiler iki farklı iz yolu sağlar.

Öyleyse sorunuza geri dönün. Yığın izlemesinin nasıl görüneceğini, bir kişiye ne olduğunu nasıl ilettiğini ve kodun hatalarını ayıklamak için gelecekteki bir kişiye yardım edip etmediğinizi kendinize sorun.

İşte bazı ipuçları:

• Argüman değerlerini bilmeye ihtiyaç duymadan niyeti ima eden açık bir fonksiyon ismi.
• bir işlev tek bir işlem gerçekleştirir
• isim mutasyon veya değişmez davranış anlamına gelir
• dilin ve araçların hata ayıklama becerisine göre hata ayıklama sorunlarını çözebilir.

Bazen kod mikroskop altında aşırı görünür, ancak daha büyük resme geri döndüğünüzde minimalist bir yaklaşım onu ​​ortadan kaldırır. Eğer öne çıkması için ihtiyacınız varsa, onu koruyabilirsiniz. Birçok küçük işlev eklemek aşırı derecede ayrıntılı olabilir, ancak daha geniş bir bağlamda geniş bir şekilde kullanıldığında bakımı geliştirir.

Bir şeyin davranışını değiştirmek için bir booleanparametreyi bayrak olarak bir yönteme geçirdiğiniz hemen her durumda , bunu yapmanın daha açık ve daha güvenli bir yolunu düşünmelisiniz .

Eğer bir Enumdurumu kullanmaktan başka bir şey yapmazsanız , kodunuzu daha iyi anladınız.

Bu örnek aşağıdakilerden Nodesınıfı kullanır JavaFX:

public enum Visiblity
{
    SHOW, HIDE

    public boolean toggleVisibility(@Nonnull final Node node) {
        node.setVisible(!node.isVisible());
    }
}

her zaman, birçok JavaFXnesnede bulunandan daha iyidir :

public void setVisiblity(final boolean flag);

ama sanırım .setVisible()ve .setHidden()durum için en iyi çözümdür bayrak bir olduğunu booleano azından ayrıntılı en açık ve olduğu gibi.

Birden fazla seçime sahip bir şey söz konusu olduğunda, bu şekilde yapılması daha da önemlidir. EnumSetsadece bu nedenle var.

Ed Mann'in bu konuda çok iyi bir blog yazısı var. Söylediklerinin aynısını yapmak üzereydim, bu yüzden çabayı çoğaltmak için değil, sadece bu cevabın eki olarak blog postasına bir link göndereceğim .

Bir (boolean) parametreye karşılık bazı parametrelere dayanan aşırı yüklü yöntemlere karşı geçen bazı arabirimler için bir yaklaşım arasında karar verirken, tüketen müşterilere bakın.

Tüm kullanımların sabit değerler (örneğin doğru, yanlış) geçmesi durumunda, bu aşırı yükleri savunur.

Tüm kullanımların değişken bir değeri geçmesi durumunda, bu parametre yaklaşımlı yönteme yöneliktir.

Bu aşırı uçların hiçbiri geçerli değilse, bu, müşteri kullanımlarının bir karışımı olduğu anlamına gelir; bu nedenle, her iki formu da destekleyip desteklememeyi seçmeniz veya bir müşteri kategorisini diğerine adapte etmek için (ne onlar için doğal değildir) seçmelisiniz.

Tasarım için iki husus var:

• API: Kullanıcıya hangi arayüzü sunduğunuz,
• Uygulama: netlik, bakım kolaylığı, vb ...

Onlar birbirine karışmamalı.

Bu tamamen iyidir:

• API yetkilendirmesinde tek bir uygulamaya devredilecek birden fazla metoda sahip olmak,
• API gönderiminde duruma bağlı olarak birden fazla uygulamaya tek bir yöntem var.

Bu nedenle, bir API tasarımının maliyet / faydalarını uygulama tasarımının maliyet / faydaları ile dengelemeye çalışan herhangi bir tartışma şüphelidir ve dikkatlice incelenmelidir.

API tarafında

Bir programcı olarak, genellikle programlanabilir API'leri tercih edeceğim. Bir işlevi iletebileceğimde, hangi işlevi arayacağınıza karar vermek için değere ilişkin bir if/ switchifadesine ihtiyacım olandan çok daha açık bir kod var .

Her işlev farklı argümanlar beklerse, ikincisi gerekli olabilir.

Senin durumunda, tek bir yöntem setState(type value)daha iyi görünüyor.

Ancak , isimsiz daha kötü bir şey yoktur true, false, 2, vb ... bu sihirli değerleri kendi başlarına hiçbir anlamı yoktur. İlkel takıntılardan kaçının ve güçlü yazmayı benimseyin.

Böylece, bir API POV, ben istiyorum: setState(State state).

Uygulama tarafında

Daha kolay olanı yapmanı öneririm.

Yöntem basitse, en iyi şekilde bir arada tutulur. Kontrol akışı kıvrılırsa, her biri bir alt kasa veya boru hattının bir adımıyla ilgili olan birden fazla yöntemde ayrılması en iyisidir.

Son olarak, gruplamayı düşünün .

Örneğinizde (okunabilirlik için boşluk bırakıldı):

this.layer1.visible = isHintOn;
this.layer2.visible = ! isHintOn;
this.layer3.visible = isHintOn;

Neden layer2trendi dalgalandırıyor? Bu bir özellik mi yoksa bir böcek mi?

O 2 listesine sahip olmak mümkündür olabilir [layer1, layer3]ve [layer2]bir ile açık onlar gruplanmış nedeni belirtilmek isim ve sonra bu listeleri üzerinde yineleme.

Örneğin:

for (auto layer : this.mainLayers) { // layer2
    layer.visible = ! isHintOn;
}
for (auto layer : this.hintLayers) { // layer1 and layer3
    layer.visible = isHintOn;
}

Kod kendisi için konuşur, neden iki grubun olduğu ve davranışlarının farklılık gösterdiği açıktır .

setOn() + setOff()Vs set(flag)sorusundan ayrı olarak, bir boole türünün burada en iyi olup olmadığını dikkatlice düşünürdüm. Asla üçüncü bir seçenek olmayacağından emin misin?

Bir boole yerine bir enum düşünmeye değer olabilir. Genişletilebilirliğe izin vermenin yanı sıra, bu aynı zamanda boolinin yanlış şekilde yükseltilmesini de zorlaştırır, örneğin:

setHint(false)

vs

setHint(Visibility::HIDE)

Enum ile, birisi 'gerektiğinde' seçeneği istediğine karar verdiğinde uzatılması daha kolay olacaktır:

enum class Visibility {
  SHOW,
  HIDE,
  IF_NEEDED // New
}

vs

setHint(false)
setHint(true)
setHintAutomaticMode(true) // New

... 'a göre davranışları belirlemek için boolean parametreleri kullanmaktan kaçınmanın önemini biliyorum

Bu bilgiyi tekrar değerlendirmeyi öneriyorum.

Öncelikle, bağladığınız SE sorusunda önerdiğiniz sonucunu görmüyorum. Çoğunlukla, bir zincirin çok aşağısında değerlendirildiği birkaç yöntem çağrısı adımında bir parametre iletmekten bahsediyorlar.

Örneğinizde, metodunuzdaki parametreyi doğru değerlendiriyorsunuz. Bu bakımdan, diğer herhangi bir parametreden hiçbir şekilde farklı değildir.

Genel olarak, boole parametrelerinin kullanılmasında kesinlikle hiçbir yanlışlık yoktur; ve açıkçası herhangi bir parametre bir davranışı belirleyecektir, ya da niçin ilk etapta buna sahiptiniz?

Soruyu tanımlamak

Başlık sorunuz "Yanlış mı [...]?" Mı? - ama "yanlış" ile ne demek istiyorsun?

Bir C # veya Java derleyicisine göre, yanlış değil. Bunun farkında olduğun konusunda eminim ve istediğin şey bu değil. Bundan başka korkuyorum, sadece nprogramcılarımızın n+1farklı görüşleri var. Bu cevap, Temiz Kod kitabının bu konuda ne söyleyeceğini sunar.

Cevap

Temiz Kod , genel olarak işlev bağımsız değişkenlerine karşı güçlü bir durum oluşturur:

Argümanlar zor. Çok fazla kavramsal güç alıyorlar. [...] okuyucularımız her gördüklerinde yorumlamak zorunda kalacaklardı.

Buradaki bir "okuyucu", API tüketicisi olabilir. Ayrıca, bu kodun henüz ne yaptığını bilmeyen bir sonraki kodlayıcı olabilir - bu bir ay içinde siz olabilirsiniz. Ya iki işlevi ayrı ayrı ya da bir kez iki kez , bir truekez falseakılda tutarak bir kez işlevden geçer .
Kısacası, mümkün olduğunca az argüman kullanın .

Bir bayrak argümanının özel durumu daha sonra doğrudan ele alınır:

Bayrak argümanları çirkin. Bir boole fonksiyona geçmek gerçekten korkunç bir uygulamadır. Derhal yöntemin imzasını zorlaştırır, bu fonksiyonun birden fazla şey yaptığını yüksek sesle ilan eder. Bayrak doğru ise bir şey, bayrak yanlış ise bir şey yapar!

Sorularınızı doğrudan cevaplamak için:
Temiz Kod'a göre , bu parametreyi ortadan kaldırmanız önerilir.

İlave bilgi:

Örneğiniz oldukça basittir, ancak orada bile kodunuza yayılan basitliği görebilirsiniz: Parametre içermeyen işlevler yalnızca basit atamalar yapar, diğer işlev aynı hedefe ulaşmak için boole aritmetiği yapmalıdır. Bu basitleştirilmiş örnekte önemsiz bir boole aritmetiğidir, ancak gerçek bir durumda oldukça karmaşık olabilir.

API kullanıcısına bağımlı hale getirmeniz gerektiğine dair birçok tartışma gördüm, çünkü bunu bir çok yerde yapmak aptalca olurdu:

if (isAfterSunset) light.TurnOn();
else light.TurnOff();

Ben do bir şeylerin olmayan optimum burada oluyor katılıyorum. Belki de görmek çok açık, ama ilk cümleniz "davranış belirtmek için boolean parametreleri kullanmaktan kaçınmanın öneminden" bahsediyor ve bu tüm sorunun temelini oluşturuyor. API kullanıcısı için daha kolay yapılması gereken bu şeyi yapmak için bir neden görmüyorum.

Test yapıp yapmadığınızı bilmiyorum - bu durumda, şunu da göz önünde bulundurun:

Bağımsız değişkenler, test açısından bile daha zordur. Tüm çeşitli argüman kombinasyonlarının düzgün çalıştığından emin olmak için tüm test senaryolarını yazmanın zorluğunu hayal edin. Eğer argüman yoksa, bu önemsizdir.