Kalıtım ve kompozisyonun aksine, özellikler ne zaman kullanılır?

OOP söz konusu olduğunda yeniden kullanılabilirliği uygulamanın üç yaygın yolu vardır: AFAIK

1. Kalıtım: genellikle bir ilişkidir (bir ördek bir kuştur)
2. Kompozisyon: genellikle has-a ilişkisini temsil etmek (bir araba has-a motoru)
3. Özellikler (örneğin PHP'deki trait anahtar sözcüğü): ... bundan emin değilim

Bana göre, özellikler hem has-a hem de a-a ilişkilerini uygulayabilirken, ne tür bir modellemenin amaçlandığından emin değilim. Özellikler ne tür durumlar için tasarlandı?

Özellikler kompozisyon yapmanın başka bir yoludur. Bunları, bir sınıfın tüm parçalarını derleme zamanında (veya JIT derleme zamanında) oluşturmanın ve ihtiyacınız olacak parçaların somut uygulamalarını bir araya getirmenin bir yolu olarak düşünün.

Temel olarak, farklı özellik kombinasyonlarına sahip sınıflar oluştururken bulduğunuz özellikleri kullanmak istersiniz. Bu durum, çoğu zaman başkalarının tüketmesi için esnek kütüphaneler yazan insanlar için ortaya çıkar. Örneğin, işte son zamanlarda ScalaTest kullanarak yazdığım bir birim test sınıfının açıklaması :

class TestMyClass
  extends WordSpecLike
  with Matchers
  with MyCustomTrait
  with BeforeAndAfterAll
  with BeforeAndAfterEach
  with ScalaFutures

Birim testi çerçevelerinin tonlarca farklı yapılandırma seçeneği vardır ve her ekibin işleri nasıl yapmak istedikleri konusunda farklı tercihleri ​​vardır. withScalaTest , seçenekleri özelliklere ( Scala'da karıştırılarak karıştırılır ) koyarak, tüm bu seçenekleri gibi sınıf adları WordSpecLikeWithMatchersAndFuturesveya bir dizi çalışma zamanı boole bayrağı oluşturmak zorunda kalmadan sunabilir WordSpecLike(enableFutures, enableMatchers, ...). Bu, Açık / kapalı prensibini takip etmeyi kolaylaştırır . Yeni bir özellik ekleyerek yeni özellikler ve yeni özellik kombinasyonları ekleyebilirsiniz. Ayrıca Arabirim Ayrışma İlkesini izlemeyi kolaylaştırır , çünkü evrensel olarak ihtiyaç duyulmayan işlevleri kolayca bir özelliğe koyabilirsiniz.

Özellikler, bir miras hiyerarşisini paylaşmak için mantıklı olmayan birkaç sınıfa ortak kod koymak için iyi bir yoldur. Kalıtım çok sıkı bir ilişkidir ve yardım edebiliyorsanız bu bedeli ödememelisiniz. Özellikler çok daha gevşek bir ilişkidir. Yukarıdaki MyCustomTraitörneğimde, sahte bir veritabanı uygulamasını başka türlü alakasız test sınıfları arasında kolayca paylaşırdım.

Bağımlılık enjeksiyonu aynı hedeflerin çoğuna ulaşır, ancak çalışma zamanında programcı girdisine dayalı derleme zamanı yerine kullanıcı girdisine dayalıdır. Özellikler aynı zamanda anlamsal olarak aynı sınıfın parçası olan bağımlılıklar için de tasarlanmıştır. Diğer sorumlulukları olan diğer sınıflara seslenmek yerine bir sınıfın parçalarını bir araya getiriyorsunuz.

Bağımlılık enjeksiyon çerçeveleri , programcı girdisine dayalı olarak derleme zamanında aynı hedeflerin çoğuna ulaşır, ancak uygun özellik desteği olmadan dilleri programlama için büyük bir çözümdür. Özellikler bu bağımlılıkları derleyicinin tür denetleyicisinin alanına, daha temiz bir sözdizimiyle, daha basit bir oluşturma işlemiyle, derleme zamanı ve çalışma zamanı bağımlılıkları arasında daha net bir ayrım yapar.