Sınıf Tasarımı C# Ad Alanı Ayrımı

Question

Yine de, işlevin ayrılmasını ve sınıf oluşturma ve ad alanı eklemeye nasıl uygulanacağını öğrenmeye çalışıyorum. Kullanıcıya sunulduğunda genellikle bir ListItem olarak görünecek bir özel sınıf SoftwareComponent var. ToListItem yöntemi iyi bir fikir mi oluşturuyor? Endişeleniyorum çünkü şimdi System.Web.UI.WebControls ad alanının eklenmesini gerektirecek bir bağımlılık sınıfına yerleştirdim.

public ListItem ToListItem() 
    { 
     ListItem li = new ListItem(); 
     li.Text = ComponentName + " (+" + ComponentCost + ")"; 
     li.Selected = Selected; 

     return li; 
    } 

Benim diğer eğim sınıfının kendi dışındaki özelliklerine dayanarak SoftwareComponent bir ListItem oluşturmaktır. Lütfen hangi yaklaşımın daha uygun/daha iyi olduğuna dair herhangi bir fikir verin. Bu SoftwareComponent gibi geliyor

Answer 1

Bu ek yöntemi bir uzantı yöntemi olarak sunamaz mısınız? Birinci sınıf bir yöntem olarak ana sınıfa sunmak yerine, bu işlevselliği sağlayan statik bir yöntem oluşturarak bir seçenek olarak dahil edilebilecek bir yardımcı sınıfın parçası olmak daha uygun görünmektedir.

public static class SoftwareComponentExtensions 
{ 
    public static ListItem ToListItem(this SoftwareComponent component) 
    { 
     ListItem li = new ListItem(component.ComponentName + " (+" + component.ComponentCost + ")"); 
     li.Selected = component.Selected; 

     return li; 
    } 
} 

Answer 2

etki alanı nesnesidir -. Başvurunuz konuşur dünyada bir "şey" açıklayan bir nesne

O alanı nesneleri etki alanı dışında şeye bağımlı yapmaktan kaçınırız - Bu pile alt seviye (nasıl depolanır? seri hale getirilir? Veritabanında saklanır) veya kullanıcı arayüzünde olun.

Bunu yapmak zor olduğunu kabul ediyorum, genellikle sınıflar, veritabanı eşlemeleri vb. Için ayrı ayrı sınıf hiyerarşileriyle sonuçlanırsınız. Bu nedenle, oluşturduğunuz şeyin boyutuna bağlı olarak, etki alanı nesnelerine UI veya veritabanı kodu eklemek veya öğeleri dışarıda tutmak için bir zorunluluktur.

Belirli bir sorun için C# 3.5 uzantı yöntemlerine bir göz atın. Statik metotların bir sınıf içinde tanımlanmış gibi görünmesini sağlayan bir el çabukluğu vardır - özel/korunan şeylere erişmedikleri sürece (bunlardan başka herhangi bir yöntem gibi kamusal yöntemlere erişebilirler) bunlardan kurtulabilirler . Ancak bunları, başka bir yerde tanımlanmış olan (UI Düzeyinde "etki alanı nesneleri için" yöntemler "gibi) şeyler için kullanırım.

Ancak akılda tutun, uzatma yöntemleri, statik bir sınıftaki eski eski statik yöntemler için sözdizimsel şekerden başka bir şey değildir.

Answer 3

SoftwareComponent, ListItems ve benzerlerini bilmezdim. Açıkça birisinin'un bir SoftwareComponent alması ve parçalarını bir ListItem'e nasıl yazacağını bilmesi gerekiyor, ancak bunun SoftwareComponent'in endişesi olmadığını düşünüyorum.

Başka bir kullanıcı arabirimi öğesi için çalışması gerektiğinde ya da özelliklerinden bazı yeni sınıflar oluşturduğunuzda, her zaman yeni bir ToXYZ() yöntemi ekleyip eklemeyeceğinizi sorun. Muhtemelen, tahmin ederim.