Eğer bir Arayüz uygularsam Miras olarak mı adlandırılır?


31

Sınıfımın implementsarayüzü varsa o zaman mirası takip ettiğimi söyleyebilir miyim? Bir sınıf extendsbaşka bir sınıfa geldiğinde kalıtım olduğunu biliyorum .



7
Jodrell'in yorumu sadece yanlıştır. Bir arayüzün uygulanması gerçekten mirastır ve bir arayüzü diğerinden miras almaktır. Nasıl bilebiliriz? Kullandığımız kelimeyi tanımlayarak. Kalıtım , bir türden devralınabilen üyelerin aynı zamanda başka bir türün üyesi olmalarıdır. Bu tanım gereği, bir arayüz uygulayan bir sınıf, tüm arayüz metodlarını miras bırakmıştır; sadece sınıfa ve arayüze bakın; doğru bir programda aynı üyelere sahip olduklarını göreceksiniz.
Eric Lippert

Denetlenmedim ve daha fazla kafa karışıklığıyla ayrıldım.
RajeeV VenkaT

18
Buna değer, sanırım size çok fazla fayda sağlayamayacak bir kelime tanımına çok fazla zaman harcıyorsunuz. Günün sonunda, bir arayüzün uygulanmasının ne anlama geldiğini ve "miras" olarak kabul edilip edilmediğini büyük ölçüde günlük işlerinize göre önemsiz olarak kabul edip etmediğimizi biliyoruz.
Robert Harvey

3
Ben (çoğunlukla) Robert ile aynı fikirdeyim. Jargon kelimelerinin çeşitli bağlamlarda kullanıldığı gibi tam olarak teknik anlamlarını anlamada gerçek bir değer olduğunu düşünüyorum. Ancak Robert, pratik etkiyi anlamanın çok daha büyük yararı olduğu konusunda haklıdır! Mirasınızı kodunuzu daha güvenli hale getirmek için nasıl kullanabilirsiniz? Daha fazla test edilebilir mi? Tekrar kullanılabilir mi? Daha esnek? Ve bunun gibi. Baz tür üyelerinin de türetilmiş türlerin üyeleri olduğunu bilmek harikadır, ancak nasıl etkili bir şekilde kullanılacağını bilmek daha iyidir.
Eric Lippert

Yanıtlar:


78

GÜNCELLEME: Bu cevabı revize ettim. Söylemeyi hak eden yorumlarda bir takım iyi noktalar ortaya atıldı.

Sınıfım bir arayüz uygularsa kalıtım takip ettiğimi söyleyebilir miyim?

"Mirastan sonra" ile ne kastettiğiniz tam olarak açık değildir. Biraz farklı bir soru soralım mı?

Kalıtım nedir?

  • Bir X türünün üyeleri, başka Y türünün üyeleri olarak kabul edildiğinde, Y'nin üyeleri X'den miras alınır .
  • Bazı türler arasında kalıtım ilişkisi vardır; yani, bazı X ve Y türleri için "Y, X'ten miras alır" deriz.

Bunlar çok farklı. Bu talihsiz çünkü kafa karıştırıcı.

Bu şaşkınlıktan tipik olarak hangi kafa karışıklıkları ortaya çıkar?

İnsanların mirası, uygulama detaylarını paylaşma mekanizması olarak düşündüğü için karışıklık ortaya çıkabilir. Bu olsa olduğu böyle bir mekanizma, bu mekanizma paylaşarak çalışır üyeleri . Bu üyelerin uygulamaları olması gerekmez! Göreceğimiz gibi soyut olabilirler.

Java ve C # özellikleri, bu karışıklığı önlemek için arayüz yöntemleri ve sınıflar arasındaki ilişkiyi tanımlamak için "miras" dışında bir kelime kullanırsa şahsen daha mutlu olurdum. Ama onlar değil, ve biz akla sahip gelen teknik özellikleri, değil karşı onlarla.

Java'da, arayüz üyeleri onları uygulayan sınıflardan miras alıyorlar mı?

Evet, bazıları Rahatınız için burada alıntı yaptığım Java spesifikasyonu bölüm 8.4.8'e bakın.

C sınıfı, doğrudan üst sınıfından ve doğrudan üst arayüzlerinden, aşağıdakilerin tümü için geçerli olan tüm soyut ve varsayılan yöntemleri miras alır: [...]

Bir sınıfın bir arayüz uyguladığını söylerseniz, sınıf o arayüzün soyut ve varsayılan yöntemlerini miras alır . (Tabii ki takip eden şartları göz ardı ettim; ayrıntılar için teknik özelliklere bakın. Özellikle, bir arayüzün bir üyesini uygulayan bir sınıfın bu üyeyi miras aldığı kabul edilmez . Yine, bu kafa karıştırıcı mı? Evet.)

Genelde Java'da bir sınıfın bir arayüzden miras kaldığını söylüyor muyuz?

Tipik bir sınıf olduğunu söyleyebilirim uygulayan bir arabirim. Yukarıda belirtildiği gibi, bir sınıf üyeleri bir arayüzden devralabilir ve yine de arayüzden devraldığı söylenemez. Kafa karıştırıcı, evet.

Bu ince ayrım günlük işler için önemli mi?

Genelde hayır. Spesifikasyondaki bu dar ayrıştırma, derleyici yazarlar için iş dünyasındaki geliştiricilere göre daha kullanışlıdır. Arabirimi ne zaman kullanacağınızı anlamak, "miras" ın kesin bir tanımını almaktır.


4
Kanonik referansla tartışamam. Şartnamelerin farklı olması durumunda, zorunlu olarak, basit terimler anlamsal olarak aşırı yüklenir ve bağlam dışı belirsizleşir. Soru etiketlendi, javabu yüzden OP başka bir şey ifade etmediğinde doğru cevap bu, java:-)
Jodrell

5
Her ne kadar soru Java ile etiketlenmiş olsa da, genel bir terim için bir dil belirtimini belirtmeyi sorunlu buluyorum. Birçok dilde arayüzler vardır ve dil özellikleri farklı bir terim kullanabilir, bu nedenle X-Lang kullanan geliştiricilerle konuşurken Java'ya özgü bir terim kullanmak kafa karıştırıcı olabilir.
Thomas Owens

5
@ThomasOwens: Bu senaryonun yaygın olduğuna katılıyorum ve sizin sonucunuza tamamen katılmıyorum. Tanımladığınız iletişim sorununa çözüm , ilgili bağlamdaki kelimelerin kesin anlamlarını anlatan herkesi eğitmektir . Bu açıklığı sağlamak için şartnameler mevcuttur; onları kullan!
Eric Lippert

5
Neden Java dili belirtimi burada son söylendi? Dil belirtimi, genellikle "ortak geliştirici" nin terminoloji ile ilgili olmayan şeyleri iddia eder.
Benjamin Gruenbaum

5
@BenjaminGruenbaum: Bilmiyorum. Bu geliştiriciler yanlıştır ve sıklıkla başkalarını yanlış inançları konusunda "eğitmek" için kendileri üstlenirler. Düzeltmek zorunda kaldığım programlama dili kitaplarının sayısına inanmayacaktınız, çünkü yazarların VB, C #, JavaScript, vb. Hakkında kesinlikle doğru olmayan bazı delice inançları vardı. (Jon Skeet aralarında değildi; C # Derinliği en baştan doğruydu! Asla bir kitap hakkında çok az yorum yapmadım ve hala ödeme
aldın

26

Kalıtım , bir üst sınıf için yeni bir alt sınıf yazmak anlamına gelir. Bir arabirime karşı yeni bir sınıf yazmak, bu arabirimi uygulamaktır . (Ve eski olanı temel alan yeni bir arayüz yazmak, bu arayüzü genişletmektir .)

Üç olasılık için de geçerli olan tek doğru terim alt yazıdır . Her alt tip bir alt sınıf değildir.


1
GoF kitabı , alt yazmayı tanımlamak için arayüz kalıtımını uygun bir terim olarak kabul ediyor gibi görünmektedir (Bölüm 1.6 Arayüz Kalıtımına Karşı Sınıf)
gnat

“Bir keresinde James Gosling'in (Java'nın mucidi) özellikli konuşmacı olduğu bir Java kullanıcı grubu toplantısına katıldım. Unutulmaz soru-cevap oturumu sırasında biri ona sordu:“ Java'yı tekrar yapabilseydin, ne değiştirirdin? ” sınıfları dışlamak, "diye cevapladı. Asıl sorunun kendi başına sınıf olmadığını, aksine uygulama mirasını (ilişkiyi genişlettiğini) açıkladı. Arabirim mirasını (uygulanan ilişki) tercih edilebilir. Mümkün olduğunda uygulama mirasından kaçınmalısınız." javaworld.com/article/2073649/core-java/…
ricardoramos

1

İle alt sınıfları , sen

  • üst sınıfın devralma durumu (tüm örnek değişkenleri, görüp görmese de)
  • gerçek uygulamaları devralma (tüm soyut olmayan yöntemler)

İle arayüzleri , yanından bir sözleşme fullfill uygulanması beyan yöntemleri.

Buna bakmanın klasik yolu bu. Şimdi Java 8 ile arayüzler bir karışım haline geldi:

  • Halen devlet devralmıyorsunuz (arayüzler hala örnek değişkenlere sahip değil)
  • Artık arayüzden varsayılan uygulamaları devralabilirsiniz

Yöntemlerinin hepsinin varsayılan uygulamaları olan bir arayüzün uygulanması hala “uygulama” olarak mı, yoksa uzantı olarak mı sayılır? Söyleyemedim. Bu dava oldukça ileriye götürüldüğü için (bu aslında durumsuz çoklu miras özelliğini etkinleştirdi), hala “miras” ı sadece alt sınıflarla kullanırdım.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.