Dahili değişkenler kamuya açık ve erişilebilir ilan edildiğinde kullanılan bir terim var mı?

10

Eğer birisi getter / setter yöntemlerini kullanmadan dahili bir $ _fields değişkeni erişilebilir olacak şekilde kod yazarsa, bunu tanımlamak için kullanılan uygun bir terim var mı?

Yönetim ile kullanmak için yeterince kibar bir şey :)

terminology scope

— PeterB
kaynak

9

Kapsülleme eksikliği?

— Oded

@Oded haklı olduğunu düşünüyorum - zayıf kapsülleme eksikliği iyi açıklar

— PeterB

Bu soruyu cevaplamaya çalışırken düşündüğüm iki kelime öbeği "sızdıran soyutlama" ve "gevşek kapsam belirleme" idi - bunların her biri ne anlama geliyor (kafamın dışında)?

— PeterB

1

Sızdıran soyutlama, bir kavramı soyutlamaya çalıştığınızdadır, ancak gerçekten işe yaramaz - temeldeki kavramlar hala dışarı sızar (SQL üzerindeki ORM'ler ve HTTP / HTML üzerinden web çerçeveleri sızıntılı soyutlamalar olma eğilimindedir).

— Oded

@PeterB - Oded'in açıklamasına eklemek için şunu görün: joelonsoftware.com/articles/LeakyAbstractions.html

— Joris Timmermans

30

Özel üyelerin teşviki kibar toplumda asla iyi bir şey değildir ...

Bu uygulama / zayıf kapsülleme eksikliğidir.

— Oded
kaynak

6

1, Eh, almamanızın sizin yapacağınız ofiste er dışarı?

— StuperUser

6

-1: Kapsülleme gerçekten oldu ve iyi oldu. Ancak kaynak kodu aracılığıyla yaygın olarak kabul edilen şekilde belgelenmemiştir . Bazı diller (Python gibi) gerçekten özel değişkenlerden yoksundur, ancak yine de kapsülleme uygular.

— S.Lott

6

@Oded: Kapsülleme bir tasarım konseptidir . Farklı diller kavramın farklı uygulamalarına sahiptir. Özel beyanı olan bir dil bir uygulamaya izin verir. Vatansız nesnelerle işlevsel bir programlama dilinin farklı bir uygulaması olabilir. Python (eksik private) kapsülleme kavramının başka bir uygulamasına daha sahiptir.

— S.Lott

1

@ Lott; Oded - Kapsülleme iyidir ve özel değişkenlerin sık sık doğrudan diğer sınıflardan erişildiği koda dayanarak zayıf kapsülleme yapılır. Python'da bunu, başka bir sınıfın ad tarafından yönetilen özel değişkenlerine erişerek veya tek bir alt çizgi önek kurallarını göz ardı ederek yaparsınız (ancak, alıcınız başka bir davranışta bulunuyorsa; gerçekten __ad yönetimi için kullanmalıdır ). Diğer diller de zayıf kapsülleme özelliğine sahip olabilir, örn. Java'da yansıma ve özel değişkenlere ulaşmak için C ++ 'da işaretçi aritmetiği. Python bu sözdizimini o hantal yapmak için yapmaz.

— dr jimbob

2

@drjimbob: Python kodu nadiren __ad yönetimi kullanır . Olmadan, __tasarım hala iyi kapsüllemeyi yansıtır. "Kamusal" ın "eksik / zayıf kapsülleme" anlamına geldiğini iddia etmek yanlıştır. Kavram hala mevcut. Kaynak kodu uygun dekorasyona sahip değildir.

— S.Lott

10

Oded tarafından daha önce sözü edilen kapsülleme eksikliğinin yanı sıra, programlama diline ve paradigmalarına bağlı olarak, "düz eski veriler" de olabilir (burada mutlaka bir antipattern veya kod kokusu değildir).

— Joris Timmermans
kaynak

4

Daha önce "çıplak nesne" terimini duymuştum.

— Raku
kaynak

1

Çıplak Nesneler Deseni'ni

— Matthieu

1

Evet, bu beni de şaşırttı.

— Raku

2

Bir özellik çantası denir.

Genellikle bir dizi ilgili özelliklerin tutulması için kullanılır (her biri potansiyel olarak uygun erişim belirteçlerine sahip olan veya olmayan bir sınıf nesnesi olabilir). Ancak çevredeki yapı sadece bir çanta özelliği.

— Martin York
kaynak

2

Buna "belirli bir kodlama standardını izlememe" denir.

OP şunu yazdı:

dahili bir $ _fields değişkeni getter / setter yöntemleri kullanılmadan erişilebilir

Bu, standardınıza aykırı olabilir ve (böylece) kod kokusu olabilir. Ancak mutlaka zayıf bir kapsülleme değildir . Bir alıcı ("yalnızca dahili kullanımda" olduğu gibi) bir alıcı ve ayarlayıcılar üzerinde dış dünyaya maruz kalmak daha da kötü olurdu.

Soru şu: $_fieldsdış dünya için erişilebilir olmalı mı?

Öyleyse, getter / setter yöntemlerini ekleyeceğiniz bir durumumuz var. Bu yöntemler $_fields, bir çeşit değişken olan gerçekten başka hiçbir şeyi kapsamaz (hesaplanan / getirilen / vb. Anında) aksine. Dile bağlı olarak, muhtemelen türü (uygulama detayı olarak da bilinir) dışarıya sızdırırsınız. İster alıcılar / ayarlayıcılar isteyin, ister yalnızca "gerekli" olduğunda kodlama standart bir konudur.

Eğer $_fieldsgereken değil erişilebilir, daha sonra, iyi, erişmek yoktur. Başkalarının dil düzeyinde (özel ve arkadaşlar) erişmesini engellemeniz gerekip gerekmediği (belirli durumlarda hata ayıklamayı kolaylaştırabilir) - yine - kodlama standart bir konudur.

Kapsülleme sorunu tamamen buna diktir. Kapsüllemeyi ihlal etmek alıcılar ve pasiflerle kesinlikle mümkündür. Kayması daha da kolaydır , çünkü çoğu insanın alarm zilleri, bir sürü alıcı ve ayarlayıcı gördüklerinde çalmaz - görünüşte en iyi uygulamaları takip eden kod. Kod, bu çok iyi denilen bir değişken daha dahili uygulama ayrıntılarını çok daha bağımlılıkları tanıtmak olabilir $_fieldsdeğil olduğu gibi belirtilecek private.

Ben kötü analojilerin hayranıyım: Zayıf kapsülleme demek silah tutan birine katil demek gibidir.

— rwos
kaynak

1

Bu değişkenlere genel üye değişkenleri diyorum .

— Olivier Jacot-Descombes
kaynak

-2

ayarlayıcı / alıcı yöntemleriniz başka bir şey değilse

void setfoo(bar){foo=bar;}
foo getfoo{return foo;}

kasık değişkeni yapmak, farkın önemli olduğu birkaç uç durumun dışında bazı yazımları kurtarıyor.

— Ryathal
kaynak

3

Sadece sahiplerinizin ve ayarlayıcılarınızın yaptığı şey her zaman böyle olacağı anlamına gelmez. Ve bir ayarlayıcıya doğrulama eklemek, özelliğin erişildiği her yerde bulmak için on binlerce kod satırını taramayı gerektiriyorsa, ilk kez kapsüllemeden kaçınarak kendinizi kurtardığınız düzinelerce saniyeyi anında üflersiniz.

— Plutor

@Plutor: Nesnenin yapacağı tek şey buysa (örn., Başka bir işleme veya veritabanındaki bir kayda gönderilen bir mesajı temsil ettiği için) Tamam; bunlar çok korunması gereken şeyler .

— Donal Fellows