Yöntemsiz sınıflara ne denir?


10

Yöntemsiz sınıflara ne denir?

Örneğin,

class A
{
  public string something;
  public int a;
}

Yukarıda herhangi bir yöntemi olmayan bir sınıf var. Bu tür bir sınıfın özel bir adı var mı?


1
Yöntemsiz bir sınıf mı?
ChaosPandion

11
Teknik terim kayıt veya yapıdır .
Kilian Foth

4
Bir "mülk çantası"
Martin York

Kilian: Ek çağrışım için "yüceltilmiş yapı" yı tercih ederim.
Jason

Yanıtlar:


23

Çoğu zaman: Bir anti desen.

Neden? Çünkü "Operatör" sınıfları ve veri yapıları ile prosedürel programlamayı kolaylaştırır. Tam olarak iyi olmayan veri ve davranışları ayırın.

Çoğu zaman: Bir DTO (Veri Aktarım Nesnesi)

Bir iş / etki alanı nesnesinden türetilen veri alışverişi anlamına gelen salt okunur veri yapıları.

Bazen: Sadece veri yapısı.

Bazen, sadece sade ve basit olan ve üzerinde herhangi bir işlemi olmayan verileri tutmak için bu yapılara sahip olmanız gerekir. Ama sonra ortak alanları değil, erişimcileri (alıcılar ve ayarlayıcılar) kullanmam.


4
Herkesi java'da sadece halka açık olanlarla / ayarlayıcılarla sınıflar yapmaya cesaret edemiyorum, beynim öldü ve bazı kaplar ayarlayıcı / alıcı kodunu bile çalıştırmayacak (Glassfish'e bakarak ...), bu yüzden ya varsayılan ya da böcek. OOP kapsüllemesinin doğru olduğuna inanmıyorum, çoğu zaman, çoğu uygulamada, DTO'lara sadece ihtiyaç duyulmakla kalmıyor, aynı zamanda en sık kullanılan sınıflar. Bu yüzden antipatterns dışında bir şey, onun yerine "temel yapı taşları" kelimesini kullanırdım.
Aadaam

8
Kesinlikle bir OO ortamındaysanız , belki de bir anti-modeldir. Programlama dünyasının geri kalanı için, basit heterojen alan koleksiyonları olan veri yapılarına sahip olmak, alternatifler üzerinde açık bir faydadır ve hatta iyi bilinen bir OO dayanağında teşvik edilir .
Telastyn

@Aadaam: Beni doğru anlamadın. DTO antipattern değildir. Bazen bu nesneler DTO'lar olduklarında mükemmeldir! Ve Glassfish alıcılara ve setterlere bakmadığında, bu sadece glassfish'in iyi yazılmadığı anlamına gelir (yerleşik erişimciler olmadan java'da zor olsa da). Bu kod braindead değil, kullanışlı bir plaka.
Falcon

4
Çabuk, @Aadaam. Birisi bir alanı geçersiz bir değere ayarlayarak, daha sonra okunduğunda hasara yol açar. Suçluyu tespit edebilmeniz için bir istisna atın. 1.000 yerde kullanılan bir ortak alan için ilk kez böyle bir şey yapmanız gerektiğinde, bir pasör istersiniz. Ortak alanların yerleri vardır, ancak alıcı / belirleyici paradigması iyi bir nedenden dolayı popülerdir.
Karl Bielefeldt

@KarlBielefeldt: bir glassfish versiyonunda, bir setter kodunda bir test olarak (şartlar olmadan) tek bir istisna vardı, hiç çalıştırılmadı. Mülkün özel bir değişkeni ve iki kamu alıcısı ve belirleyicisi vardı. Konteyner sadece ayarlayıcıyı atlattı. Bir şeyin aslında geçersiz bir değeri varsa, kişisel olarak ilkel değerler yerine tip sınıflarını tercih ederim, ama belki de bu sadece benim.
Aadaam

9

Ben diyorum structya da recordveri depolama için kullanıldığı ve bu Corada gördüğünüz gibi diller için çok yaygın olduğu için : struct (C programlama dili) . Şahsen ben structdaha uygun ve okunabilir bir sınıf yerine kullanmayı tercih ederim :

struct A
{
  public string something;
  public int a;
}

Genellikle diğerleri gibi DTO (Veri Aktarım Nesnesi) olarak kullanılırlar.


4
Struct ile ilgili sorun, "struct" birçok dilde bir anahtar kelime olmasıdır. Örneğin C #, yapıları farklı semantiğe sahip değer türleri olarak ele alır. Bu, bazı dillerde "kayıt" için de geçerlidir (PL / SQL).
Falcon

5

Bunlar , boşluğun Java veya C veya CIL olduğu veya kullandığınız dilin olduğu Düz Eski __ Nesneler (PO_O) olarak bilinir .

İletişim için basit veri blokları olarak kullanılıyorlarsa, Veri Aktarım Nesneleri (DTO'lar) olarak bilinirler .

Harici olarak sağlanan verileri temsil ediyorlarsa, Varlıklar olarak bilinirler .


6
POD'ları düşünüyorsunuz - çok farklı bir fikir. POJO'lar açıkça "iş mantığı" nı içerir, ancak belirli çerçevelere olan bağımlılıkları hariç tutar.
Tom Hawtin - çakmak hattı

POD'ların en azından C ++ 'da yöntemlere sahip olmasına izin verilir. Sadece önemsiz kuruculara, yıkıcıya, kopya kurucularına ve atama kurucularına, sadece genel veri üyelerine, temel sınıflara ve sanal işlevlere sahip olmamaları gerekir. Temel olarak, sadece C yapılarıyla uyumlu olmaları gerekir.
Dirk Holsopple

2

Böyle bir sınıfı değişebilir bir veri sahibi olarak adlandırırdım ve bazen genel bir form kullandım:

class DataHolder<T>
{
   public T dat;
}

datBir mülkün içine kaydırmanın performansı düşüreceğini ve fayda sağlayamayacağını unutmayın, çünkü bir mülk erişimcisinin yapabileceği (alanı okuma / yazma dışında) bazı uygulamaları bozmayacak bir şey yoktur. Ayrıca, (veya bir yapı ise, bunun alanlarıyla) Interlockedyöntemlerin kullanılması gerekebilir dat, ancak datbir mülke sarılırsa bu mümkün olmaz .

Değişken veri tutucuların, veri tutması gereken tipler için (değişebilir ya da değil) yararlı olabilmesine rağmen, değişmez tiplerle aynı şekilde veri alışverişi için güvenle kullanılamayacaklarını unutmayın. Örneğin, şöyle bir ifade:

myData = myCollection.GetData(myKey);

GetDatadeğişmez bir sınıf türü veya değişebilir verilere referans içermeyen bir yapı ("değişebilir" ya da değil) döndürülürse, açık bir anlamı olacaktır . Bununla birlikte, değişebilir bir sınıf nesnesi döndürdüyse, bu nesnede yapılan değişikliklerin temel alınan koleksiyon tarafından sürekli olarak yoksayılıp yok edilmeyeceği, sürekli olarak temiz güncellemelerle sonuçlanacağı veya hiçbir açıklamayı karşılamayan bazı rahatsız edici veya öngörülemeyen davranışlara neden olup olmayacağı belirsiz olacaktır.

Bir kişi değişken bir nesnede koleksiyon döndürme verisine sahip olmak isterse, doğru paradigma genellikle şöyle bir şey olurdu:

var myData = new WhateverType();
myCollection.GetData(myKey, myData);
myData.ModifySomehow();
myCollection.StoreData(myKey, myData);

Bu yaklaşımı kullanarak , koleksiyondaki verilerle doldurulmasına GetDataneden olacak myData, ancak myCollectionişlev tamamlandıktan sonra ona bir referans tutması beklenmeyecek ya da başka bir amaç için kullanamayacağı net bir ima vardır . StoreDataaynı şekilde bilgileri myDatareferans vermeden kendi dahili veri yapısına kopyalar . Bu yaklaşımın bir avantajı, istemci kodu bir döngü içinde birçok veri öğesini okuyacaksa, döngü myDatadışında bir örneği güvenli bir şekilde oluşturabilir ve ardından her seferinde aynı örneği yeniden kullanabilmesidir. Benzer şekilde, myCollectionanahtarla ilişkilendirilmiş nesne örneğini (geçirilen örnekten veri kopyalayarak) yeni bir örnek oluşturmadan yeniden kullanabilir.


0

Bağlama bağlı olarak, onlara Varlıklar diyorum. Sıkıcı iş uygulamalarımda, genellikle 1: 1'i DER'imle eşlerler.


0

Buna a diyorum Schema.

Bu, bir veritabanı tablosunu, seriyi kaldırılmış bir kaydı veya bir DTO'yu, vb. Temsil etmek gibi birden çok kullanımı kapsar.

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.