Rich Hickey, “Arayüzlerin / sınıfların / türlerin bütün bu özelliği, yeniden kullanımınızı öldürür!” Derken ne demek istedi?

Rich Hickey’in 29. dakikada “ Değerlerin Değeri ” konulu açılış konuşmasında , Java gibi bir dilin tepesinden bahsediyor ve “Tüm bu arayüzler yeniden kullanımınızı öldürüyor” gibi bir ifade veriyor. Ne demek istiyor? Bu doğru mu?

Cevapları araştırmamda, aşağıdakileri geçtim:

• En Az Bilgi Prensibi AKA Hava geçirmez API arayüzlerini teşvik eden Demeter Kanunu . Wikipedia da bazı dezavantajları listeler.

• Kevlin Henney'nin kullanılmasının, yeniden kullanılmamasının savunulan İmparatorluk Kıyafetleri Krizi uygun amaçtır.

• Jack Diederich'in genel olarak aşırı mühendislik karşıtı olan "Yazmayı Durdurma Sınıfları " konuşması.

Açıkça, yeterince kötü yazılmış herhangi bir şey işe yaramaz. Peki, iyi yazılmış bir API'nin arayüzü bu kodun kullanılmasını nasıl önler? Tarih boyunca , bir amaç için başka bir şey için daha fazla kullanılan bir şeyin yapılmış örnekleri vardır . Ancak yazılım dünyasında, amaçlanmadığı bir amaç için bir şey kullanırsanız, genellikle kırılır.

Bazı kodların meşru fakat istenmeden kullanılmasını önleyen iyi bir arayüz örneği için iyi bir örnek arıyorum. Bu var mı? Ben hayal edemiyorum.

Rich Hickey sunumunun tamamını izlemedim, ama onu doğru anlarsam ve 29 dakikalık işaret hakkında söylediklerini değerlendirirsek, yeniden kullanım türlerini öldürmeyi tartışıyor gibi görünüyor . “Arayüz” terimini gevşek bir şekilde “adlandırılmış tür” ile eşanlamlı olarak kullanıyor, bu mantıklı.

İki varlık varsa { "name":"John" }Çeşidi Personve { "name": "Rover" }Çeşidi DogJava topraklarda, muhtemelen ortak bir arayüz veya atası (gibi paylaşamaz birlikte çalışan sürece Mammal, daha fazla kod yazma aracı). Bu yüzden buradaki arayüzler / tipler "yeniden kullanımınızı öldürüyor": aynısını görseniz Personve Doggörseniz bile , bunu desteklemek için ek bir kod yazmazsanız biri diğerine göre kullanılamaz. Not Hickey ayrıca Java'da birçok sınıfa ihtiyaç duyan projeler hakkında şakalar yapar ("Burada kim sadece 20 sınıf kullanarak bir Java uygulaması yazdı?"), Bu da yukarıdakilerin bir sonucu gibi görünüyor.

Ancak “değer odaklı” dillerde, bu yapılara tipler atamazsınız; bunlar sadece aynı yapıyı paylaşan değerlerdir (benim örneğimde her ikisinin de namebir String değeri olan bir alanı vardır) ve bu nedenle kolayca birlikte çalışabilirler, örneğin aynı koleksiyona eklenebilirler, aynı yöntemlere geçtiler, vb.

Özetle, bütün bunlar yapısal eşitlik ve açık tip / arayüz eşitliği hakkında bir şey gibi görünüyor . Videonun bölümlerinden henüz bir şey kaçırmadıysam, henüz izlemedim :)

Muhtemelen bir arayüzün başlatılamamasının temel gerçeğinden bahsediyor. reuseBir arayüz olamaz . Yalnızca onu destekleyen kodu uygulayabilirsiniz ve bir arabirim için kod yazdığınızda yeniden kullanım yoktur.

Java, bir argüman olarak ara yüz alan birçok API (ler) in çerçevelerini sağlama geçmişine sahiptir, ancak API'yi geliştiren ekip , bu arayüzlerle tekrar kullanmanız için hiçbir zaman geniş bir sınıf aralığı uygulamamaktadır .

IWindowBir iletişim kutusu için bir arayüze sahip olan bir GUI çerçevesi gibidir ve ardından IButtonkontroller için arayüzler ekleyebilirsiniz . Dışında, size asla Buttonuygulayan iyi bir sınıf vermediler IButton. Yani kendi yaratıcılığını kendin yarattın.

Çekirdek işlevsellikler sağlayan geniş bir temel sınıf yelpazesine sahip soyutlanmış çerçeveler daha tekrar kullanılabilir niteliktedir ve bu soyutlanmış sınıfları çerçeveyi kullananlar için erişilebilir olduğunda en iyi şekilde çalışır.

Java geliştiricileri bu şeyi API katmanlarının yalnızca ortaya çıkardığı yerlerde yapmaya başladı interfaces. Bu arabirimleri uygulayabilirsiniz, ancak bu arabirimleri uygulayan geliştiricinin sınıflarını hiçbir zaman yeniden kullanamazsınız. Bir çeşit pelerin ve hançer API geliştirme tarzı gibi.

Bence sunumunda 13 no'lu slayt ( Değerlerin Değeri ) bunu anlamaya yardımcı olur:

Değerler

• Yapma ihtiyaç yöntemleri
  • Sana kod olmadan değerler gönderebilirim
    ve sen iyisin

Anladığım kadarıyla Hickey, bana gönderdiğiniz değeri iki katına çıkarmam gerekirse, basitçe şöyle bir kod yazmam gerektiğini söylüyor

    MyValue = Double(YourValue)

Görüyorsunuz, yukarıdaki kod aynı, ne tür bir değer yolladığınızın önemi yok - mükemmel bir yeniden kullanım .

Şimdi, bunun nesneleri ve arayüzleri olan dilde nasıl görüneceği?

    Doublable MyValue = YourValue.Double()

bekle! Ya YourValueuygulamıyorsa Doublable? iki katına çıkamayacağı, mükemmel olabileceği söylenemez ama ... ya da hiçbir yöntem yoksa Double? (ya denilen bir yöntem varsa TwiceAsMuch?)

Ah, bir sorunumuz var. YourValue.Doubleçalışmayacak, tekrar kullanılamaz . Yukarıdaki slaytı okuduğumda, bu, "Tüm bu arayüzler yeniden kullanımınızı öldürür!" Dediğinde Hickey'nin ne demek istediği ile ilgilidir.

Görüyorsunuz, arayüzler nesnelerin "metotlarıyla birlikte" etraflarında geçirildiğini varsayıyorlar ve bunlar üzerinde çalışan kodlarla. Nesneleri kullanmak için, o kodu nasıl çağıracağınızı, hangi yöntemi çağıracağınızı anlamanız gerekir .

Beklenen yöntem eksik olduğunda, bir sorun vardır, her ne kadar anlamsal olsa da , istenen işlem bir nesne için mükemmel bir anlam ifade eder. Sunumda belirtildiği gibi, değerler metotlara ihtiyaç duymaz ("Size kod olmadan kodları gönderebilirim ve iyisin"), bunlarla ilgili kodları genel bir şekilde yazmanıza olanak tanır.

Yan not: kodsuz değerlerin etrafında dolaşılması kavramı bana bir şekilde OOP'daki bir Flyweight modelini hatırlatıyor .

^{diğer benzer nesnelerle mümkün olduğu kadar veri paylaşarak bellek kullanımını en aza indiren bir nesne; Basit bir tekrarlanan gösterimin kabul edilemez miktarda bellek kullanması durumunda, nesneleri büyük sayılarla kullanmanın bir yoludur ... Flyweight nesneleri, tanım değer nesnelerine göredir . Nesne örneğinin kimliği sonuçsuzdur, bu nedenle aynı değerde iki Flyweight örneği eşit olarak kabul edilir ...}

Kolay düzeltme Genellikle görülen nesne kodu (yöntemleri, arayüzler) sıyırma gibi, iyi, yaklaşık etrafında malzeme geçen aynı yaklaşım takip ziyaretinde kullanımları kod az değerler , kodunu aldıktan bu üzerinde çalışmak için gerekli araçlara sahip olmasıdır bekliyor.

Bu, slaytta olduğu gibi hissettiriyor, "değerler yöntemlere ihtiyaç duymuyor. Size kod olmadan değerleri gönderebilirim ve iyisin".

Bir (yani benim) ideal dünya sınıflarında ve arayüzlerinde her zaman davranışı tarif ederdi, ama gerçek şu ki, çoğu zaman gerçekten sadece verileri tanımlamaya başlıyorlar. Sadece dün, birinin BankAccountyüceltilmekten başka bir şey olmayan sözde bir sınıf inşa etmesini izledim int(gerçekten de bir şeyden çok daha az işe yaramazdı int, bu yüzden tekrar bıraktığım yeniden kullanımı 'öldürüyor' int), hepsi 'iyi' tasarım adına. Verilerin katlanmış temsillerini sürekli olarak yeniden icat etmek için harcanan kod, ter ve gözyaşı miktarı şaşırtıcıdır; Verileri anlamlı bir şekilde kullanmıyorsanız, lütfen bırakın.

Şimdi, Rich Hickey'in bebeği banyo suyuyla atmaktan memnun olduğumuz ve değerlerin ülkesinde yaşayacağımızı (isim krallığının komşusu) söyleyen aşama budur. Bence, OOP'nin, ustaca kullanıldığında yeniden kullanımı (ve fonksiyonel programlamada eksik bulduğum keşfedilebilirliği) destekleyebileceğini ve desteklediğini düşünüyorum. Bu gerilimi en iyi yakalayan bir OOP ilkesi arıyorsanız, bunun http://c2.com/cgi/wiki?TellDontAsk (elbette Demeter'in yakın bir kuzeni) olabileceğini düşünüyorum.