OOP dilinde sınıf ve tür

Programlama dili teorisinde, bir tür bir değerler kümesidir. Örneğin, "int" türü tüm tamsayı değerlerin kümesidir.

OOP dillerinde, sınıf bir türdür, değil mi?

Bir sınıf birden fazla üyeyle tanımlandığında, ör.

class myclass{
    int a; 
    double b;
}

Bir sınıf hakkında konuştuğumuzda,

• " bir int ve bir çift (a,b)nerede " veyaab
• "{ (x,y)| xherhangi bir int, yherhangi bir çift mi}"?

myclassOrtalama örneği ne anlama geliyor?

• " bir int ve bir çift (a,b)nerede " veyaab
• bir bellek alanı ve (ille, yani hem boş) olabilir deposu kaplar bir amacı (x,y), xherhangi bir int ve ybir çift?

Ne.

Aynı alan türlerine sahip olmanın aynı sınıf olarak sınıflandırmak için yeterli olup olmadığını veya aynı şekilde adlandırılmaları gerekip gerekmediğini soruyorsunuz. Cevap: "Aynı türlere ve aynı isimlere sahip olmamak bile yeterli!" Yapısal olarak eşdeğer sınıflar mutlaka tip uyumlu değildir.

Örneğin bir varsa, CartesianCoordinatesbir PolarCordinatessınıf, her ikisi kendi alanlarında olarak iki sayı olabilir ve hatta aynı olabilir Numbertürüne ve aynı isimleri, ama yine de uyumlu olmaz ve bir örneği PolarCoordinatesbir olmaz örneği CartesianCoordinates. Türleri mevcut uygulamalarına göre değil amaçlanan amaçlarına göre ayırabilme yeteneği , daha güvenli ve daha sürdürülebilir kod yazmanın çok yararlı bir parçasıdır.

Türler küme değildir.

Görüyorsunuz, küme teorisinin türlere uygulanmayan birtakım özellikleri vardır ve bunun tersi de geçerlidir . Örneğin, bir nesnenin tek bir kanonik türü vardır. Birkaç farklı türün bir örneği olabilir, ancak bu türlerden sadece biri onu başlatmak için kullanıldı. Küme teorisinin "kanonik" kümeler nosyonu yoktur.

Alt kümeye neyin ait olduğunu açıklayan bir kuralınız varsa, Set teorisi anında alt kümeler oluşturmanıza olanak tanır . Tip teorisi genellikle buna izin vermez. En diller sahipken Numbertürü veya benzer bir şey, onlar yok bir sahip EvenNumbertürü, ne de bir tane oluşturmak için basit olacaktır. Yani, türün kendisini tanımlamak yeterince kolaydır, ancak var Numberolan herhangi bir s sihirli bir şekilde EvenNumbers'ye dönüştürülmeyecektir .

Aslında, alt kümeleri "oluşturabileceğinizi" söylemek biraz gariptir, çünkü kümeler tamamen farklı bir hayvan türüdür. Küme teorisinde, bu altkümeler zaten onları tanımlayabileceğiniz tüm sonsuz yollarla var olurlar. Tip teorisinde, genellikle herhangi bir zamanda sınırlı (büyükse) sayıda tiple uğraşmayı umuyoruz. Var olduğu söylenen tek tür, tanımlayabildiğimiz her tür değil, aslında tanımladığımız türlerdir.

Kümelerin doğrudan veya dolaylı olarak kendilerini içermesine izin verilmez . Python gibi bazı diller, (Python, daha az düzenli yapılarla türlerini sağlamak type'ın kanonik türüdür typeve objectbir örneğini kabul edilir object). Öte yandan, çoğu dil, kullanıcı tanımlı türlerin bu tür bir hile yapmasına izin vermez .

Setlerin birbiri içine girmeden genellikle üst üste binmesine izin verilir. Bu, tür teorisinde nadirdir, ancak bazı diller onu çoklu kalıtım biçiminde desteklemektedir. Java gibi diğer diller, bunun yalnızca sınırlı bir biçimine izin verir veya tamamen izin vermez.

Boş tür vardır ( alt tür olarak adlandırılır ), ancak çoğu dil bunu desteklemez veya birinci sınıf tür olarak kabul etmez. "Diğer tüm türleri içeren tür" de vardır (buna üst tür adı verilir ) ve küme teorisinin aksine yaygın olarak desteklenir.

Not : Bazı yorumcular daha önce işaret ettikleri gibi (konu sohbete taşınmadan önce), set teorisi ve diğer standart matematiksel yapılarla türleri modellemek mümkündür. Örneğin, tür üyeliğini kümeler olarak modellemek yerine tür üyeliğini ilişki olarak modelleyebilirsiniz. Ancak uygulamada, set teorisi yerine kategori teorisi kullanıyorsanız bu çok daha basittir . Örneğin Haskell kendi tip teorisini böyle modeller.

"Alt tipleme" kavramı, "altküme" kavramından oldukça farklıdır. Eğer Xbir alt tipi olan Y, biz anlamına gelir yerine örneklerini Yörnekleri için Xve çalışmaya devam programı "iş" Bir anlamda. Bu yapısal olmaktan ziyade davranışsaldır, ancak bazı diller (örneğin, Go, Rust, tartışmalı olarak C), ikincisini programcıya veya dil uygulamasına kolaylık nedenleriyle seçmiştir.

Cebirsel veri türleri bunu tartışmanın yoludur.

Türleri birleştirmenin üç temel yolu vardır:

• Ürün. Temel olarak böyle düşünüyorsunuz:

  struct IntXDouble{
    int a; 
    double b;
  }
  

  bir ürün türüdür; değerleri bir intve birin tüm olası kombinasyonlarıdır (örn. tuples) double. Sayı türlerini kümeler olarak değerlendirirseniz, ürün türünün temel niteliği aslında alanların temel önemlerinin ürünüdür.

• Sum. Prosedürel dillerde, bu doğrudan ifade etmek biraz gariptir (klasik olarak etiketlenmiş sendikalarla yapılır ), bu yüzden daha iyi anlamak için Haskell'de bir toplam türü vardır:

  data IntOrDouble = AnInt Int
                   | ADouble Double
  

  bu türün değerleri ya forma sahiptir ya AnInt 345da ADouble 4.23her zaman yalnızca bir sayı vardır (her bir değerin iki sayıya sahip olduğu ürün türünün aksine). Böylece kardinalite: önce tüm Intdeğerleri numaralandırırsınız , her biri AnIntyapıcı ile birleştirilmelidir . Ayrıca , her Doubledeğerle birleştirilen tüm değerler ADouble. Dolayısıyla toplam türü .

• Üstelleştirme ¹ . Bunu burada ayrıntılı olarak tartışmayacağım çünkü hiçbir net OO yazışması yok.

Peki ya sınıflar? Ben kasten anahtar sözcüğü kullanılır structziyade classiçin IntXDouble. Mesele şu ki, bir tür olarak bir sınıf, alanlarıyla gerçekten karakterize edilmez, bunlar sadece uygulama detaylarıdır. En önemli faktör, sınıfta hangi ayırt edici değerlerin olabileceğidir.

Ne olduğunu olsa, bir sınıfın bir değer olabilir alakalı değerleri herhangi 's alt sınıflarından ! Bir sınıf bir toplamı tipi yerine bir ürün tipi aslında Yani: eğer Ave Bher iki elde edilecek myClass, myClassesasen toplamı olacaktır Ave B. Gerçek uygulama ne olursa olsun.

¹ _{Bu fonksiyonlardır ( matematiksel anlamda! ); bir işlev türü Int -> Doubleüstel ile temsil edilir Double^Int. Dilinizde uygun işlevler yoksa kötüdür ...}

Üzgünüm ama "ham" teoriyi bilmiyorum. Sadece pratik bir yaklaşım sağlayabilirim. Umarım bu programcılar için kabul edilebilirdir. Buradaki görgü kurallarına aşina değilim.

OOP'un ana teması bilgi gizlemesidir . Bir sınıfın veri üyelerinin ne olduğu tam olarak müvekkillerinin ilgisini çekmemelidir. İstemci , dahili durumu değiştirebilecek veya değiştirmeyecek bir örneğe (çağrı yöntemlerini / üye işlevlerini) ileti gönderir . Fikir, bir sınıfın iç kısmının, istemci ondan etkilenmeden değişebileceğidir.

Bunun bir sonucu olarak sınıf , iç temsilinin "geçerli" kalmasını sağlamaktan sorumludur. Diyelim ki (tam) bir telefon numarasını iki tamsayıda saklayan bir sınıf:

    int areacode;
    int number;

Bunlar sınıfın veri üyeleridir . Bununla birlikte, sınıf muhtemelen sadece veri üyelerinden çok daha fazla olacaktır ve kesinlikle "tüm int x int değerlerinin kümesi" olarak tanımlanamaz. Veri üyelerine doğrudan erişiminiz olmamalıdır.

Bir örneğin oluşturulması negatif sayıları reddedebilir. Belki de inşaat, alan kodunu bir şekilde normalleştirebilir, hatta tüm sayıyı doğrulayabilir. Böylece çok daha yakın adresinden Müşteri sona ereceğini "(a,b) where a is an int and b is a double"kesinlikle değil çünkü, herhangi bu sınıfta saklanan iki int.

Ama bu sınıf açısından gerçekten önemli değil. Ne veri üyelerinin türü ne de sınıfı tanımlayan olası değerlerin aralığıdır , onun için tanımlanmış yöntemlerdir .

Bu yöntemler aynı kaldığı sürece, uygulayıcı veri türlerini kayan noktaya, BIGNUM'lara, dizelere, her neyse değiştirebilir ve tüm pratik amaçlar için hala aynı sınıf olacaktır .

Dahili temsilin bu tür değişikliklerinin, müşterinin farkında olmadan bile yapılabilmesini sağlayan tasarım paternleri vardır (örn., C ++ 'daki pimpl deyimi, opak bir işaretçinin arkasındaki herhangi bir veri üyesini gizler ).

• Bir tür bir kategoride tanımıdır / değerler, bileşik yapıların aralığı veya sizi ne var. Aksi takdirde, bir "arayüz" benzer. (Dil-agnostik anlamda. Dile özel anlamda, çok değil ise Java, örneğin,. intBir olan tip , ama bir ilişkisi yoktur interface. Kamu / korumalı alan özellikler, sıra, bir parçası olmayan interface, ama olan bir "arayüzü" ya da bir parçası türü ).

  Ana nokta, somut olandan çok daha anlamsal bir tanımdır. Yapı sadece açıkta kalan alanlar / davranışlar ve bunların tanımlanmış amaçları aynı hizaya geldikçe faktörlerdir . Her ikisine de sahip değilseniz, tür uyumluluğunuz yoktur.

• Bir sınıf bir tür gerçekleştirilmesidir. İç yapıyı, ekli davranışı vb. Tanımlayan bir şablon.