Kancalar ne zaman doğru tasarım seçeneğidir?

ActiveRecord geri aramalarının yaygın ve rahatsız edici olduğu büyük bir Rails uygulaması üzerinde çalıştım. Bir kaydın kaydedilmesi genellikle beklenmedik yan etkilere neden oldu ve bu sistem hakkında akıl yürütmek için bir zorluktu.

Aynı zamanda, kalıtımın bir parçası olarak iyi etki için kullanılan kancaları gördüm (örneğin, alt sınıfların ebeveynin iç özelliklerini bilmeye gerek kalmadan özel davranışlar eklemesine izin vermek için bir şablon yöntemi kullanarak bir üst sınıf) ve eklentilerde (örneğin, etkinleştirildiğinde kanca çalıştıran bir emacs modu, kullanıcıların bu modun çevresine özel davranış eklemesine olanak tanır).

Bir Rails uygulamasının ve Lisp yorumlayıcısının çok farklı sistemler olduğunu anlıyorum, ancak kancaların karşılaştıkları sorun için doğru tasarım seçimi olup olmadığına karar verirken insanların baktığı bilinen herhangi bir kriter olup olmadığını merak ediyorum.

Bana sıçrayan tema tahmin edilebilirlik. Kancaların yanlış kullanımı, uzaktan ve şaşırtıcı bir davranışta ürkütücü eyleme yol açarken, iyi kullanım sıkı bağlantı olmadan öngörülebilir bir çerçeveye yol açabilir.

Programlama kariyerimde henüz sadece birkaç yıl olduğum için, kendimi birçok bakımdan bir çaylak olarak görüyorum ve insanların bu konuya adil bir şekilde düşündüğünden şüpheleniyorum. Bu kararı yönlendirebilecek bazı yönergeler nelerdir?

Kanca alıcılarına kontrolü aktararak, bir soyutlamanın uygulama detaylarını tüketicilerinden ayırmak istediğinizde kancalar iyi bir tasarım seçimidir.

Bunu anonim bir yayınla (olaylar veya anonim geri aramalar gibi) veya yazılan soyutlamalar (Arabirimler veya üst sınıflar gibi) kullanarak yapabilirsiniz.

Anonim yayını şu durumlarda kullanmalısınız:

• Kancanın çağrısı isteğe bağlıdır
• Arayan kişi kancayı kimin aldığını umursamıyor.
• Alıcıların yürütme sırası önemsizdir.
• Nesne durumunu, çağrının tüm abonelerine yayınlamak istiyorsunuz.

Aşağıdaki durumlarda yazılı bir soyutlama kullanmalısınız:

• Kancayı aramak zorunludur.
• Çağıran nesnenin kancanın alıcısını tanımlaması gerekir.
• Alıcıların yürütme sırası nesnenizle ilgilidir.

Yayın kancasına örnek olarak KeyPressedEvent verilebilir. Etkinliği tetikleyen sınıf, etkinliği kimin aldığını umursamaz ve etkinliğe abone olan herkese klavye durumunu yayınlar. Alıcıların yürütme sırasının, olayı başlatan sınıfın nesne durumu üzerinde hiçbir etkisi yoktur.

Yazılan bir soyutlama kancasına örnek olarak, bahsettiğiniz şablon yöntemi verilebilir. Bu durumda, üst sınıf şablon yöntemleri için bir uygulama gerektirir, alıcıların alt öğe olacağını bilir ve üst sınıf tarafından tanımlandığı gibi şablon yöntemleri için belirli bir yürütme sırasına sahiptir.

Çoğu dil ve çoğu platform, başka bir şey gibi giyinmiş olsa bile kancalamayı kullanır. "Olay", "mesaj", "tetikleyici", "sinyal" veya bu türden diğer terimlerle ilgili her haber duyduğunuzda, kuralın istisnaları olsa da, muhtemelen kuralın istisnaları vardır. bu tartışma için önemli.

Bunları kullanıyorsunuz çünkü platform bunları size sağlıyor veya muhtemelen performans nedenleriyle kullanılmasını gerektiriyor. Kanca kullanmak genellikle kod karmaşıklığını azaltır, iş gereksinimlerinin uygulanmasına yardımcı olur ve CPU kullanımını azaltır, pil ve donanım ömrünü uzatır. Kodunuzdan en iyi performansı almak istediğinizde bunları kullanmalısınız.

Rails'teki rahatsız edici deneyimleriniz bile kancalar için ortak bir kullanım durumunu tanımlar: iş kuralları uygulanmalı ve kancalar iş kurallarını uygulamak için hemen hemen evrensel olarak kullanılmaktadır. Ne yazık ki, tüm kurallar mantıklı değildir ve anlayabileceğiniz gibi, bir geliştirici için keyfi olduklarında işleri daha da zorlaştırır, ancak bu nedenle bir sistemin dokümantasyonu kodun kendisi kadar önemlidir.

Genel bir kural olarak, performans özellikleri oldukları için kancaları kullanın ve kodunuzun alternatiften daha verimli çalışmasını sağlar (olayları kontrol etmek için meşgul bir döngüde beklediğiniz "yoklama" olarak adlandırılır). Ancak, uygun belgeleri kullandığınızdan ve bu belgeleri güncel tuttuğunuzdan da emin olun. Kancalar neredeyse karşılaşacağınız her dilde kullanılır ve neden var olduklarını bilmek önemlidir.

Daha önce kancaları iyi kullanan bir program üzerinde çalıştım. Kitabımda, gerçek bir kanca, geri aramalar (aboneler) listesine yapılan bir çağrıdır (yayınla). Güçlü, kötüye kullanım kolaydır. Kullanım durumu sormak için en iyi soru şudur: Çalışma zamanında davranışı etkinleştirmek veya devre dışı bırakmak ister miyim? Örneğin, kullanıcılarınızın belirli olaylarda çalıştıracağınız komut dosyaları sağlamalarına veya daha küçük eklentilerden oluşan genel bir program yapmalarına izin vermek isteyebilirsiniz. Sonra çağırma uygundur. Genel olarak, çok az seçeneğiniz vardır.

Değilse, modüllerinizin iyi bir kemeri ile kaçmalısınız. Şablon yöntemleri aşırı yüklenmiş işlevlerle iyi çalışır, bunun için çalışma zamanı mantığına gerek yoktur. Gevşek bağlantıyı bir yanılsama olarak uygulayacağını düşünün: doğrudan aradığınız veya bağladığınız bir şey arasında aynı bağımlılık seviyesi var, callee yine de sözleşmesini doldurmak zorunda.

Belki bazı insanlar aşırı yüklenmiş işlevler çengel ile şablon yöntemini çağırır, ancak bu yukarıdakilerden farklıdır: burada, bakım kabusuna girme riski daha düşük olan statik bir bağlantınız vardır.