Bu noktada etkisi olmayan bir işlevi çağırmak daha iyi olur mu, kod netliğini iyileştirirse?

60

Programımda (iOS uygulaması) üç görünüm var. Sadece bir tanesi aynı anda aktif durumdadır, bu yüzden ikisi için görünürlüğü kapattım ve kullanıcı düğmelere basarken görünürlüğü değiştirdim. Görünümler görünür olarak başlatıldığından ana görünüm gösterilmeden önce görünürlüğü kodda kapatıyorum.

Yapabilirim

[view1 setAlpha:0.0f];
[view2 setAlpha:0.0f];

iki görüş için, ancak şimdi üçüncüsü (uygulamanın başında görünmesi gereken) ele alınmamıştır. Bir koydum

[view3 setAlpha:1.0f];

ilk ikisinden sonra, çünkü kod görünce iki kişinin değil, üç görüntünün olduğu açık olduğunu düşünüyorum. Diğer programcılar bunu nasıl yapar? Tamamen tercih mi yoksa bazı sözleşmeler var mı?

Eğer arama çok ağırsa, gerekli olmadığında arama yapmamanız daha iyi, ama örneğim gibi küçük şeyleri merak ediyordum.

coding-style clean-code

— Kevin
kaynak

134

Bir değişmeziniz var:

Sadece tek bir görünüm (3'ten fazla) hiç aktif (ve görünür).

Ardından, TÜM görünümlerin etkinliğini ve görünürlüğünü bir kerede değiştirmek için bir işlev sunmanızı öneririm:

[setActiveView viewID:2]

Bu işlev:

Gereksiz çalışmalardan kaçınarak görünümün etkin olup olmadığını kontrol edin
görünümü etkin ve görünür olarak ayarlayın
diğer 2 görünümü etkin ve görünmez olarak ayarlayın

Bir ham çağrı hakkında birden fazla avantaja sahiptir setVisibility:

Dostu: Gereksiz yere çağırmak bir performans sorunu yaratmaz
savunmacı: tek parametresi botch için daha zordur, oysa setVisibilityki değer aralığı olduğunu 0.0f - 1.0fve sadece birinin ayarlanması gerektiğini hatırlamak daha zordur1.0f
esnek: Bir sonraki adam yanlışlıkla görüşlerden birini unutamam
uyarlanabilir: görünüm ekleme / kaldırma, anahtarların nerede olduğunu bulmak için tüm uygulama kodunun incelenmesini gerektirmez, tek bir işlev (bu) güncellenmelidir

İdeal olarak, değişmezliğin uygulanmasına yardımcı olmak için, başka hiçbir fonksiyon bu ayarın üstesinden gelemez.

— Matthieu M.
kaynak

Harika öneri. Bunu şimdiki örneğimle yapacağım. Ama böyle bir tasarımın mümkün olmadığı / istenmediği zaman ne olacak? Yoksa yerinde ele almanın en iyi yolunun ne olduğuna karar veriyor musunuz?

— Kevin

4

@Kevin: Bu gerçekten bağlı. Bazen sorunu bir koleksiyon üzerinde yineleyerek çözebilirsiniz, bazen değil, ancak kilit ilke çoğaltmayı önlemek ve değişmezleri korumayı kolaylaştırmaktır. İşlerin düzgün çalışması için ne kadar “manuel” eylemlerin hatırlanması gerekir, işlerin düzgün çalışması için o kadar az şansınız olur. Burada belirsiz olmaktan nefret ediyorum, ancak “genel” bir kuralın sizi yanıltmanıza yol açmasından korktuğum çok farklı durumlar var.

— Matthieu M.

23

“İstilacıların korunmasını kolaylaştırın” hatırlamaya değer genel bir kuraldır.

— Gusdor

1

@Tonny: Global bir değişkenin kullanımını teşvik etmenin "doğru yapmak" olduğunu bilmiyorum, ama gerçekten hangisinin daha önce aktif olduğunu biliyorsanız, sadece iki görüş güncellemeniz gerekir. Bir başka çözüm, her bir görüşün görünürlüğünü hatırlaması ve görünürlük setVisibilityzaten istenen olanı ise hiçbir şey yapmamak için sorumluluğunu aşağı çekiyor.

— Matthieu M.

1

@MatthieuM. Aceleyle yazdım, ama aslında demek istediğim de buydu. Önceki durumu biliyorsanız, yalnızca en fazla 2 görünümü güncellemeniz gerekir. Bu durumun nasıl hatırlanacağı başka bir meseledir ;-). Sorumluluğu azaltma gelince: Eğer görünüm sınıfı bunu sağlamadıysa, bu özelliği eklemek için sınıfı başka bir nesneye sarmanız gerekir. Bu temiz bir çözüm, ama belki biraz overkill.

— Tonny

12

Alternatif bir fikir: Amacınız, böceklerin oluşmasını engellemekse, çünkü insanlar üç görüş olduğunu unuturlar ve yalnızca ikisiyle birlikte, hepsiyle yapmaları gereken bir şey yaparlarsa, unutmayı imkansız kılan bir işlev yapın :

setViewVisibilities(0.0f, 0.0f, 1.0f)

Artık çok daha güçlü bir şeyiniz var - derleme zamanı, unutmadığınızın garantisidir . Bir parametreyi unutursanız, derleyici size bağırır. Bu, değer verdiğiniz ve zorladığınız kodlardan çok daha kullanışlıdır, çünkü önem verdiğiniz mülkü uygulayan katı bir protokol oluşturur.

view3Görünürlüğünün değişmemesine ihtiyaç duyulmadığı durumlarda , bu satırlar gibi özel bir değerin -1.0veya nil"görünüm görünürlüğünü hiç değiştirme" anlamına gelen özel bir değer iletmenin bazı davranışlar ekleyebilirsiniz . Bu, gereksiz yere görünürlük ayarlama sorununu çözmektedir.

— kriko
kaynak

9

OP 10+ görüntüye ulaşırsa, görünüm başına bir parametrenin korunması imkansız hale gelir. Derleme zamanı hataları hakkındaki düşünceniz doğru, ancak bu maalesef çok anlaşılmaz bir çözüm.

— Chris Cirefice

3

@ChrisCirefice: Görüntüleme sayısı arttıkça, bu değişmezliği zorlayan bir tür "ViewState" nesnesi / sınıfı oluşturabilirsiniz. Daha sonra anahtarlama vb. İçin kullanın. Çok sayıda görünümde, bir tür yönetici nesnesi muhtemelen bir anlam ifade eder.

— sleske,

8

Aramanın gereksiz olduğunu (ve neden) en iyi olduğunu açıklayan bir yorum eklemeye inanırdım.

^{(belki de bir aramanın gereksiz olması veya bunun hakkında bir yorum yapmanız gerekmesi gerçeği bir kod kokusu olabilir)}

— Basile Starynkevitch
kaynak

1

@Hayır Mümkünse, bir iddia yorumdan daha iyi olurdu.

— 200_success

9

Yorumlar, sürdürülemez ve okunamayan bir kodun çözümü değildir

— dj18

2

@Kevin ya da yorum yapmadan tam olarak okunabilen bir kod yazabilirsiniz.

— Ocak

1

@Jan Yorumlar sadece kodun ne yaptığını açıklamaktan başka bir şey değildir .......

— Kevin

2

@Kevin , kodun ne yaptığını açıklamak için hiçbir zaman yorumlar olmaması gerektiğini , bunun yerine neden yaptığını açıklamak gerektiğini söyleyebilirim. Ve bu gibi durumlarda, çoğu zaman bir refaktör, yorum yapmaya ihtiyaç duymadan (Jan'in amacı gibi) neye ihtiyaç duymaz.

— RJFalconer

4

Bu özel durumda, @Mattieu M. doğru çözüme sahiptir.

Benzer hiçbir dönüşümü yoktur daha genel durumda, kendinize şunu sormalısınız: var mı herhangi bir şans gelecekteki programcı kudreti bunda?

Cevap genellikle evet. Yani, evet, aramayı eklemelisin. Belki çerçevenin gelecekteki bir sürümü ON yerine tüm görüşler OFF ile başlar.

— Stig Hemmer
kaynak