OOP, Mülkiyet kavramını içermek için nasıl gelişti?


12

Ben bir C ++ arka plan geldi ve şimdiki işimde C # dışarı gidiyorum ve ben sadece kamu alanları ve özellikleri ve bu varyasyonları ve enkarnasyonları tüm ileri ve geri arasındaki fark hakkında Q & A bir sürü okudum temel soru (örneğin, bu SO yazısı ve bağlantılı tüm sorular ). Tüm bu sorular, bir mülkiyet sisteminin varlığını kabul eden pratik farklılıklar açısından ele alınmaktadır, ancak ilk olarak mülkleri desteklemeye karar veren tüm dillerin tasarımcılarının ne olduğu konusunda bu konuya yaklaşmanın iyi olacağını düşünüyorum. yer düşünüyordu (Wikipedia makalesindeki listeye göz atın). OOP, Wikipedia makalesinin yöntemler ve üye verileri arasında ilginç bir orta alan olarak tanımladığı şeye genişletmek için C ++ / Java'dan nasıl gelişti:

"Diğer bir deyişle, özellikler, sınıfın üye kodu (yöntemleri) ile üye verileri (örnek değişkenleri) arasında aracıdır ve özellikler, ortak alanlardan daha yüksek düzeyde kapsülleme sağlar."

MSDN daha fazla arka plan ekler:

"Özellikler teknik olarak yöntemlere çok benzese de kullanım senaryoları açısından oldukça farklıdırlar. Akıllı alanlar olarak görülmelidirler. Alanların çağrı sözdizimine ve yöntemlerin esnekliğine sahiptirler."

Bu orta seviye kapsüllemenin genel olarak programlama için yararlı olduğunu nasıl anlayacağımı bilmek istiyorum. Bu kavramın, OOP paradigmasını ifade eden programlama dillerinin ilk enkarnasyonunda mevcut olmadığını varsayıyorum.


8
Çıplak dil özelliği, alıcı ve ayarlayıcı yöntemleri için sadece uygun sözdizimsel şekerdir. Yorumun ve terminolojinin arkasında daha derin nedenler olup olmadığını bilmiyorum.

Bir dizi OO uzmanında soru başlığınız provoke edebilir ve gerçekten sorduğunuz şeyden rahatsız olabilir. Kendimi bir OO uzmanı olarak görmüyorum, sadece birkaç yıldır "OO kullanıcısıyım".
Doc Brown

Python'da 'parametresiz yöntemler'den C ++' a giderek özlediğim sözdizimsel bir özellik. BMI = bob.weight/sq(bob.height)IMO'suz daha güzel okur ().
OJFord

Active X (COM) nesnesini yapılandırmanın bir yolu olarak özellikleri özgün (.net olmayan) Visual Basic'te olduğunu düşünüyorum. Bu araçtaki özellik ızgarasının muhtemelen dillerin özelliklerinin benimsenmesi ile ilgisi vardı. Özgün Visual Basic'in birçok yönden nesneye yönelik olmadığını, ancak sınıflar gibi bir şey oluşturma yeteneğine sahip olduğunu unutmayın.
Frank Hileman

Devam ediyor: özellik penceresi, kod yazmadan nesneleri yapılandırmanın bir yoluydu. Buna RAD gelişimi deniyordu. Bu bağlantı VB6 özellikler penceresinin ekran görüntüsünü içerir: microsoft.com/mspress/books/WW/sampchap/4068.aspx
Frank Hileman

Yanıtlar:


5

Her şey Kapsülleme ve Tekdüzen Erişim İlkesi ile ilgilidir.

Bir nesne, varolan verileri döndürerek veya bir yöntem çalıştırarak iletiye yanıt verebilmelidir, ancak gönderenin hangisinin hangisi olduğunu söyleyememesi gerekir. Veya bunu gönderenin tarafından görüntülerseniz: gönderen mevcut verilere erişebilmeli veya tek tip bir arabirim üzerinden bir yöntem çalıştırabilmelidir.

Bunu başarmanın birkaç yolu vardır:

  • Verilerden tamamen kurtulun, sadece yöntemlere sahip olun (Newspeak bunu yapar)

    • yukarıdakilerin daha az radikal bir biçimi: genel arayüzdeki verilerden kurtulun , yani genel arayüzde verileri her zaman özel yapın, sadece yöntemleri ortaya çıkarın (Smalltalk, Ruby bunu yapın)
  • yöntemlerden tamamen kurtulun, sadece verilere sahip olun (Öz bunu yapar, "yöntemler" sadece Methodörnek değişkenlerine atanan nesnelerdir, örnek değişkenler sanal gönderimle aranır)

  • yöntemler ve veriler arasında sözdizimsel veya anlamsal bir ayrım yapmayın (Scala bunu yapar, bir alana erişmek, argüman listesi ( foo.bar) olmadan bir yöntemi çağırmaktan sözdizimsel olarak ayırt edilemez, bir alana atamak, özel olarak adlandırılmış bir yöntemi ( foo.bar = baz) çağırmaktan sözdizimsel olarak ayırt edilemez olarak foo.bar_=(baz)örneğin adlı bir yöntem çağrı foo_=ve salt okunur değerleri geçersiz veya parametre listesine (yani olmayan bir yöntemle uygulanan olabilir val fookılınabilir bir üst içinde) (ya da bir abstract valbir yöntem ile, bir alt uygulanacaktır) def foo)

Bununla birlikte Java, Tekdüzen Erişim İlkesine uymaz. Java'da, verilere erişme ve bir yöntemi çalıştırma arasında ayrım yapmak mümkündür. foo.bar'den farklı foo.bar(). Bunun nedeni, alanların ve yöntemlerin anlamsal ve sözdizimsel olarak farklı olmasıdır.

C # dile temel olarak alanlara benzeyen yöntemler ekleyerek bunu düzeltmeye çalışır. Ancak, yöntem çağrıları hala alan ve özellik erişiminden farklı görünür ve hissedilir. Alanlar ve özellikler artık Tekdüzen Erişim'e sahiptir, ancak yöntemler hala yoktur.

Yani, bu aslında sorunu çözmez: şeylere erişmek için üçüncü bir yol ekleyerek şeylere erişmek için iki farklı yolla düzeltemezsiniz! Bu üçüncü yol diğer iki yoldan birine benzese bile, (en azından) iki farklı yolunuz olacaktır. Bunu sadece biri hariç tüm farklı yollardan kurtularak veya farklılıklardan kurtularak düzeltebilirsiniz.

Yöntemler, özellikler ve alanlarla bir dile sahip olmak gayet iyi, ancak her üçünün de eşit erişimi olmalıdır.


1
Siz (ve diğerleri) Tekdüzen Erişimi sürdürmenin neden bu kadar önemli olduğunu düşünüyorsunuz? Bir yöntemle, ne yaptığını veya üzerinde ne yaptığını değiştirmek için parametreler vermek isteyebilirsiniz. Bir alan veya özellik ile bu yeteneğe sahip değilsiniz, genellikle yalnızca veri döndürürsünüz (bir özellik yalnızca özel bir alanı göstermek yerine bir yöntem çalıştırmak olarak uygulanabilir). Bu benim için sezgisel görünüyor, belki de buna alışkın olduğum için, ancak tekdüzen erişimi zorlayarak zarafet veya verimlilikte ne kazanırdınız? Sınıf dışında uygulama ayrıntılarını sızdırmaktan korkuyor musunuz?
Mike

1
UAP, kamu arayüzünü bozmadan uygulama ayrıntılarını değiştirme özgürlüğünü korumakla ilgilidir. Genel örnek, günlük kaydı eklemektir. Bir yöntemle erişim sunarsam, bir günlüğe yazmak için yöntemin iç bilgilerini değiştirebilirim. Ortak bir alanla, ilk önce tüm istemci kodunu kıran bir yönteme dönüştürmeden günlük ekleyemiyorum. Değişikliklerin kırılması risk altında değilse, yöntemlerin kullanılması şarttır. Özellikler en iyi uzlaşmadır çünkü tam yöntemlerdir, ancak alanlara benzerler. UAP'ye yapışmak kapsüllenmeyi iyileştirir ve sıkı bağlantıyı azaltır.
amon

Bu soruya çok iyi cevaplar var ama bence bu, programlama dillerinin doğasının daha temel yönlerini çekerek ve ilgili resmi UAP kavramı hakkında ayrıntılı bilgi vererek kafasına çiviyi vurdu. Katı
jxramos

18

% 100 emin değilim, ama sanırım işler beklediğinizden daha basit. 90'lı yılların OO modelleme okullarından, kapsüllenmiş üye niteliklerine sahip sınıfları modelleme talebi vardı ve C ++ veya Java gibi dillerde uygulandığında, bu genellikle çok sayıda alıcı ve ayarlayıcı ile koda yol açıyor, bu yüzden çok fazla "gürültü" nispeten basit bir gereksinim için kod. Bağlantılı Wikipedia makalenizde listelenen dillerin çoğunun (muhtemelen hepsi bunu kontrol etmedi), 90'ların sonunda veya daha sonra nesnelerin "özelliklerini" tanıtmaya başladığını unutmayın.

Sanırım dil tasarımcıları bu gürültüyü azaltmak için sözdizimsel şeker eklemeye karar vermelerinin ana nedeni buydu. Ve özellikler kesinlikle "çekirdek OO kavramı" olmamasına rağmen, en azından nesne yönelimi ile ilgili bir şeyleri vardır . "OOP'un evrimi" ni (soru başlığınızın varsaydığı gibi) göstermezler, ancak uygulamayı kolaylaştırmak için programlama dili düzeyinde OO modellemesini desteklerler .


Bir özelliğin bir alanın soyutlanması ve alanların nesne yönelimli programlamanın bir parçası olması dışında, nesne yönelimli programlama ile ilgisi yoktur. Ancak, doğru şekilde not ettiğiniz gibi, nesne yönelimli programlama için özelliklere gerek yoktur.
Frank Hileman

2
@FrankHileman: "Bir özellik bir alanın bir soyutlama olduğunu ve alanların nesne yönelimli programlama parçası olan" - evet, sizin gibi bana sesler kavramı kabul ettiğinizi vardır aslında en azından bir şeyler OOP ile ilgisi yok. Ve bu yüzden beni indirdin mi?
Doc Brown

3
lol. Onu suçlayabilir misin? Tuvaletinden çıktı ve lavabosuna kafasını vurdu. Neyse ... Ben her zaman gördüğümüz yolu özellikler olmasıydı olmayan OO şey üzerinde bir kesinlikle. Enkapsülasyona yardımcı olurlar ve kapsülleme OO'ya yardımcı olur.
MetaFight

1
Ha! Bu benim için programcılar.stackexchange'e giriş. Lol, düz ol stackoverflow :-p Eşdeğer deneyimimden çok daha fazla ısıtılmış Gün karıştırmak için iyi bir yol!
jxramos


11

Geriye doğru var (bir çeşit). Lambda Matematik , programlama dilleri için temel resmi temel olarak varlığını sürdürüyor ve onlarca yıldır var. Alanı yok.

Değişken durumu modellemek için iki soyutlama yapmanız gerekir. Biri bir durum belirlemeyi temsil eder, diğeri bu durumu alır ( referans için TaPL versiyonumdaki Bölüm 13 ). Kulağa tanıdık geliyor mu? Bir itibaren teorik arka plan, OO bu şeyler olması gelişmemiştir. OO Programlama Dilleri 101'i okudu ve bir adım öne geçti.

Bir itibaren pratik perspektiften, iki oldukça açık motivasyonları vardır. Bir C ++ arka planından geliyorsunuz, bu yüzden halka açık bir alanınız olsaydı ne olurdu - diyelim ki ... bir metin kutusundaki metin. "Bu metin kutusu her değiştiğinde falan" olacak şekilde tasarımınızı değiştirmek istediğinizde ne olur? Bu alanı öldürmek, bir veya iki işlev yapmak ve bu mantığı bağlamak, çünkü geliştiricilerin kendilerine "UpdateTextbox" ı çağırmaları için güvenemezsiniz. Bu, API'nizde çok büyük bir değişikliktir (ve maalesef .NET'in özelliklerin uygulanmasında hala büyük bir değişikliktir). Bu tür davranışlar Windows API'sinde her yerde bulunur . Bu Microsoft için büyük bir anlaşma olduğundan, C # bunu daha az acı verici yapmak istedi.

Diğer büyük motivasyon Java Fasulye ve akrabaları. Java yansımasını aramak GetXve SetXçiftlemek ve modern özellikler gibi etkili bir şekilde işlemek için birkaç çerçeve oluşturuldu . Ancak gerçek dil yapıları olmadıkları için, bu çerçeveler kırılgan ve tuhaftı. Eğer bir isim yazsaydın, işler sessizce bozulurdu. Biri yeniden düzenlendiyse, mülkün diğer tarafına hiçbir şey taşınmadı. Ve tüm alan / get / set kazan plakasını yapmak ayrıntılı ve sıkıcıydı (Java için bile!). C # büyük ölçüde "Öğrenilen derslerle Java" olarak geliştirildiğinden, bu tür bir acı bu derslerden biriydi.

Ancak en büyük şey, mülkiyet kavramının başarılı olmasıdır. Anlaması kolay, kullanımı kolay. Bunlar büyük ölçüde benimsenmesine yardımcı olur ve bir araç olarak , programcılar özelliklerin bir sorun alt kümesini fonksiyonlardan veya alanlardan daha temiz bir şekilde çözdüğünü bulmuşlardır.


7
Sizi çoğunlukla alakasız resmi saçmalıklara çok fazla referans için indirdim. Programlama dillerinin gerçek uygulamaları, modellerinin lambda hesabına dahil edilip edilmediğinden çok daha ciddi şeylere sahiptir.
DeadMG

9
@DeadMG - bu kesinlikle doğrudur, ancak diğer taraftan programlama dili uygulayıcıları her zaman bu alakasız resmi boktan aşina olacaklardır . Tasarımlarını etkilemediğini düşünmek saftır.
Telastyn

3
Bu kesinlikle "alakasız resmi saçmalık" değildir. Ancak, lambda hesabı erken programlama dilleri için fazla düşünülmemiş olabilir. Öyleyse, CPU'lar muhtemelen bu zihniyete daha fazla yönelecektir.
Frank Hileman

3
@FrankHileman - Lisp'in bunu düşündüğünden eminim ...
Telastyn

4
@Telastyn - evet - ve Lisp'in başlangıçta bir programlama dili olmaması gerekiyordu, hatırladın mı?
Frank Hileman

3

Özellikle .net'te, özellikler eski Visual Basic günlerinden kaynaklanır, ki bu gerçekleştiğinde bugün hakkında düşündüğümüz şekilde nesne yönelimli değildi. Büyük ölçüde, her şeyi yüzeysel olarak sınıf olarak değil, hem kodda hem de grafik editörlerde erişilebilecek özellikleri ortaya çıkaran bileşenler açısından yüzeysel olarak ele alan yeni COM sistemi etrafında inşa edildi. VB ve yeni oluşturulan C # .net ile birleştirildiğinde, VB bir sürü OOP özelliği kazandı ve bunları kaldırmanın geriye doğru bir adım olacağı için özellikleri korudular - Visual Studio'da sahip oldukları otomatik kod güncelleme aracının tüm özelliklerinizi alıcılar ve ayarlayıcılarla değiştirerek tüm COM kitaplıklarıyla uyumluluğu bozuyordu. Sadece onları desteklemek mantıklı olacaktır.


Delphi ve ondan önce gelen Object Pascal ve Nesnelerle Turbo Pascal'ın C # soyunu görmezden gelmeniz gerektiğini düşünmüyorum. Bunlar nesne yönelimli ve özelliklere sahipti (OP'nin TP5.5'ten özelliklere sahip olup olmadığını veya eklenip eklenmediğini hatırlayamıyorum; muhtemelen Anders tarafından C # 'a pragmatik olarak iyi bir fikir oldukları için devam ettiler.
amaca

Bu sorunun bileşen yönüne çarpan tek kişi olduğun çok ilginç. Ben sadece özellikleri C # tatmin bazı özellik-yöntem-olay modelinin bir parçası olarak listelenen bir siteye bağlayan bir yorum ekledi. Daha sonra birkaç yanlış pozitif iniş "bileşen" için tekrar sorumun sayfasını aradım ama cevabın aslında bağlandığım şeyle çakıştığını düşünüyorum.
jxramos

3

Özelliklerin nesne yönelimli programlama ile ilgisi yoktur, çünkü özellikler sadece sözdizimsel şekerdir. Özellikler yüzeysel olarak alanlara benzer ve .net dünyasında, bazı şekillerde alanlar gibi davranmaları önerilir, ancak herhangi bir anlamda alan değildirler. Özellikler bir veya iki yöntem için sözdizimsel şekerdir: biri bir değer almak için ve diğeri bir değer ayarlamak için. Set yöntemi veya get yöntemi atlanabilir, ancak her ikisi birden atlanamaz. Get yönteminin döndürdüğü değeri depolayan alan olmayabilir. Sözdizimini alanlarla paylaştıkları ve genellikle alanları kullandıkları için, insanlar özellikleri alanlarla ilişkilendirir.

Özelliklerin alanlar üzerinde avantajları vardır:

  • Özellik kümesi yönteminde, bir özellik değeri depolanmadan önce, yeni değer veya nesnenin durumu, bir dizi ön koşul veya değişmezle karşılaştırılarak denetlenebilir.
  • Özellik değerinin alınması mantıksal olarak bir alan değerinin alınmasıyla eşdeğer kabul edilebilirse, bir özellik alma yöntemi kullanılabilir.
  • Özellik kümesi yöntemi, üst nesneyi bildirme veya özellik değerinde yapılan bir değişikliği nesnelerini dinleme gibi diğer işlemleri gerçekleştirebilir.

Özellikler alanların soyutlaması olduğundan ve sözdizimsel kolaylık açısından C # gibi diller özellikler için alan sözdizimini benimser.


2
Wikipedia makalesinin ilk satırı. Msgstr "Bazı nesne yönelimli programlama dillerindeki bir özellik, özel bir sınıf üyesidir ...". İlk cümleniz yanlıştır. Ve geri kalan kısım soruyu cevaplamıyor.
Doc Brown

1
@DocBrown: İlginç bir yanıt. Birçok Wikipedia makalesi açıkça yanlış. Bu makalenin yazarını savunduğunuzu varsayıyorum?
Frank Hileman

1
Nesne yönelimli programlama dillerinin tüm özellikleri nesne yönelimli kavramlarla ilgili değildir.
Frank Hileman

1
Bu, soruyu cevaplamadığınız gerçeğini değiştirmez.
Doc Brown

3
Unutulmamalıdır ki, sadece isteğe bağlı ayarlayıcı değildir. Yalnızca ayarlayıcı özelliklerine sahip olabilirsiniz.
Telastyn

2

Bu meselesi uygulanması karşı zımnen . C ++ veya Java sahneyi vurmadan önce özellikler OOP'taydı (Simula'da kenarlarda biraz pürüzlüydüler ve Smalltalk için esaslardı). Özelliklere sahip varlıklar kavramsal olarak kod eklenmiş değerlerden farklıdır. Bazı dil kurallarındaki get & set önekleri yalnızca suların çamurlanmasına hizmet eder; alanlara ve özellikler arasındaki farkın farkına varırlar, alanlara dil için deyimsel bir şekilde get / set olmadan doğrudan erişilebildiğini varsayarlar ve bu sızıntı yapar.

OOP'un asıl amacı, şeylere "gerçek" dünyadaki varlıklarmış gibi davranmaktır, sadece bazı kodların karıştığı yapılar gibi davranmak değildir. Başka bir programcının şeyleri uygulama şeklim hakkında çok, çok az şey bilmesi gerekir ve elde etmelerine izin verilen ve / veya ayarladıkları çeşitli değerlerden hangilerinin gerçek ve hangilerinin sanal olduğu ile ilgili olmamalıdır. Bir vektörümle karşılaşırsanız, açı ve büyüklük mü yoksa vektör nesnesinin içindeki gerçek ve hayali bileşenleri mi sakladığımı bilmeniz gerekmez. Kütüphanemin V2.0'daki temsilini değiştirirsem, kodunuzu hiç etkilememelidir (yine de harika yeni özelliklerden yararlanmak isteyebilirsiniz). Benzer şekilde, bir işletmenin varlık dışındaki verilere bağlı olabilecek özellikleri vardır, ama kuşkusuz sözcüksel açıdan özelliklerdir. O "nesne" için mevcut olan verilerin doğum tarihi (özel bir değişmez üye) ve bugünkü olduğunu bilseniz bile insanlara "kaç yaşındasınız" değil, "lütfen yaşınızı bana gösterecek hesaplamayı yapın" diye soruyorsunuz. tarih (saat dilimine, gün ışığından yararlanma saatine ve Uluslararası Tarih Satırına bağlı olarak herkese açık, otomatik olarak artan bir çevresel mülk). Yaş, bir yöntem değil, bir yöntemdir, oraya ulaşmak için bazı hesaplama gerektirir ve (yapay olarak sınırlı ömürleri olan şeylerin oyuncak bilgisayar gösterimleri hariç) bir alan olarak saklanamaz. o "nesne" için mevcut olan verilerin doğum tarihi (özel bir değişmez üye) ve bugünün tarihi (saat dilimine, gün ışığından yararlanma saatine ve Uluslararası Tarih Satırına bağlı olarak, herkese açık, otomatik olarak artan bir çevresel mülk) olduğunu bilmenize rağmen ). Yaş, bir yöntem değil, bir yöntemdir, oraya ulaşmak için bazı hesaplama gerektirir ve (yapay olarak sınırlı yaşam sürelerine sahip şeylerin oyuncak bilgisayar gösterimleri hariç) bir alan olarak saklanamaz. o "nesne" için mevcut olan verilerin doğum tarihi (özel bir değişmez üye) ve bugünün tarihi (saat dilimine, gün ışığından yararlanma saatine ve Uluslararası Tarih Satırına bağlı olarak, herkese açık, otomatik olarak artan bir çevresel mülk) olduğunu bilmenize rağmen ). Yaş, bir yöntem değil, bir yöntemdir, oraya ulaşmak için bazı hesaplama gerektirir ve (yapay olarak sınırlı ömürleri olan şeylerin oyuncak bilgisayar gösterimleri hariç) bir alan olarak saklanamaz.

Mülkleri alanların ve yöntemlerin piç çocuğu olarak düşünmek yerine, yöntemlerin özel bir mülk türü olarak - varlıklarınızın oldukları şeylerden ziyade yapabileceği şeyler - çok daha tatmin edicidir. Aksi takdirde, nesne / varlıklarla kavramsal olarak ilgilenmezsiniz, onlara kod eklenmiş olan veri koleksiyonlarıyla ilgilenirsiniz. Uygulamalarla aynı olabilir, fakat etkileri farklıdır.

Bununla birlikte, bu soyutlamanın bir bedeli olduğunu söylemek gereksizdir. Bir sınıfı kullanan bir programcı, depolandığı gibi verilere erişip erişmediğini veya hesaplanması gereken değerleri alıp ayarlayamadığını söyleyemiyorsa, dilin de mutlaka belirsiz (ve dolayısıyla her şeyin erişimciler / seçiciler ve değerler arasında aracılık etmesini gerektirir). "Kodlu yapılar" ile kavramsal olarak yanlış bir şey yoktur - kesinlikle çok daha verimli olabilirler - ancak her yere uygulama sızdırıyorlar ve bu OOP'un ortadan kaldırması gereken şeylerden biri.


Bazı noktalarda katılıyorum ve diğerleri katılmıyorum, ama genel mesaj iyi biridir: hesaplanacak bir nesne ihtiyaçları hakkında bazı bilgiler ancak teknik olarak hâlâ bilgidir olduğunu edilebilir bir eylem yerine yapılması .
Pharap

0

Kesinlikle hiçbir şey. Mülkler ve OOP'nin birbirleriyle hiçbir ilgisi yoktur. Özellikler, işlev çağrıları için sözdizimsel şekerden başka bir şey değildir ve bu nedenle işlev, çağıran hiçbiri olmayan aynı OOP ekine sahiptir.

Bu arada Wikipedia tamamen yanlış. Java'da gördüğünüz getMember / setMember kalıbı, C # özellikleriyle tam olarak aynı avantajları (ve dezavantajları) sunar. Ve isterseniz bu deseni C'de bile çoğaltabilirsiniz.

C # 'daki özellikler, dil destekli sözdizimsel şekerden başka bir şey değildir.


3
Özellik kavramını hiç bir sınıf veya nesne bağlamı dışında herhangi bir programlama dilinde gördünüz mü? Bende yok.
Doc Brown

1
@DocBrown: Uyguladım. Gerçek şu ki, özellikler düzenli yazarlar için oldukça düşük değerli hedeflerdir, çünkü düzenli işlev çağrıları üzerindeki iyileştirmeleri düşüktür.
DeadMG

1
OP popüler programlama dillerinde kavram olarak özelliklerin tarihini soruyordu . Ve aslında, tarihsel anlamda özellikler ile OOP arasında bir bağlantı vardır.
Doc Brown

2
Belki de bu özellik kavramını kendi başına OOP paradigmasına atfetmek için biraz acelecektim, ancak bir kavram olarak kesinlikle bireysel dilleri ve özelliklerini aşar. Belki ikisi arasında uygun ontolojiyi ifade etmekte zorlanıyorum. Sorunun başlığı aracılığıyla, özelliklerin OOP formalizmini yapan veya bozan OOP'nin temel bir özelliği / kavramı olduğunu söylemiyorum ve yine de bu OOP alanında sadece bir gerçekliğe sahip olduklarını hissediyorum, bu yüzden soruyu bu şekilde ifade ettim .
jxramos

4
Bunlar sadece C # 'da sözdizimi şekeri değildir, montaj meta verilerinde ayrı üyeler olarak bulunurlar ve veritabanları gibi alanlarla yapamayacağınız özelliklere sahip şeyler yapabilirsiniz.
Andy
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.