Code vereinfachen - Listen zusammenfassen

[Luckie]

Ich habe es mit vielen unterschiedlichen Listen zu tun:

Code:

public class AddressCollection
    {
        private List<AddressItem> addressList;

        public AddressCollection()
        {
            addressList = new List<AddressItem>();
        }

        public void Add(AddressItem value)
        {
            addressList.Add(value);
        }

        public int Count
        {
            get { return addressList.Count; }
        }

        public AddressItem this[int index]
        {
            get { return addressList[index]; }
        }

        // needed for "foreach"
        public System.Collections.Generic.IEnumerator<AddressItem>
            GetEnumerator()
        {
            return addressList.GetEnumerator();
        }
        // needed for sorting
        public void Sort(IComparer<AddressItem> comparer)
        {
            addressList.Sort(comparer);
        }
    }

Code:

  // List of websites
    public class WebsiteCollection
    {
        private List<WebsiteItem> websiteList;

        public WebsiteCollection()
        {
            websiteList = new List<WebsiteItem>();
        }

        public void Add(WebsiteItem value)
        {
            websiteList.Add(value);
        }

        public int Count
        {
            get { return websiteList.Count; }
        }

        public WebsiteItem this[int index]
        {
            get { return websiteList[index]; }
        }

        // needed for "foreach"
        public System.Collections.Generic.IEnumerator<WebsiteItem>
            GetEnumerator()
        {
            return websiteList.GetEnumerator();
        }
        // needed for sorting
        public void Sort(IComparer<WebsiteItem> comparer)
        {
            websiteList.Sort(comparer);
        }
    }

Solche Listen gibt es jetzt für Webseiten, Telefonnumern, Produkte, Produkteigenschaften usw. Ich habe bisher für jede Liste eine eigene Listenklasse erstellt, wie oben. das waren dann AdressCollection, WebsitCollection, TelefonnumberCollection usw. Kann man da nicht irgendwie eine Liste nehmen, ohne den Vorteil der typisierung zu verlieren?

[Phoenix]

Code:

public class MyCollection<T>
    {
        private List<T> _list;

        public MyCollection()
        {
            _list = new List<T>();
        }

        public void Add(T value)
        {
            _list.Add(value);
        }

        public int Count
        {
            get { return _list.Count; }
        }

        public T this[int index]
        {
            get { return _list[index]; }
        }

        // needed for "foreach"
        public System.Collections.Generic.IEnumerator<T>
            GetEnumerator()
        {
            return _list.GetEnumerator();
        }
        // needed for sorting
        public void Sort(IComparer<T> comparer)
        {
            _list.Sort(comparer);
        }
    }

Und dann halt woimmer Du eine List brauchst mit MyCollection<AddressItem> oder MyCollection<WebsiteItem> arbeiten.

Edit nachtrag: Aber warum machst Du diese Klasse überhaupt? Was kann die, was Du nicht auch direkt mit List<T> machen kannst? :gruebel:

[Luckie]

Sie hat nur die Methoden, die ich auch brauche. Ich dachte, das wäre dann etwas einfacher zu Hand haben.

Hat der Unterstrich eine besondere Bedeutung oder warum hast du ihn benutzt bei der Namensgebung und ist das so üblich?

[Phoenix]

Hrm.. also ich würde wenn möglich direkt mit List<T> arbeiten. Man weiss nie, an was man so eine Liste später noch binden möchte ;-)

Mit welcher C#-Version arbeitest Du eigentlich? Schon mit 3.0? Ich frag nur, weil Du da den Enumerator laut Kommentar explizit für foreach durchgeschleift hast, und man mit Linq in der Regel viele foreach-Schleifen elegant umgehen kann.

@Unterstrich: Styleguide (& eigene Gewohnheit).

Hier gibts einen Blogeintrag mit einem kleinen Screenshot der mein Lieblingsargument aufzeigt:
http://arcware.net/archive/2007/11/0...Variables.aspx

Und hier stehen viele Sachen zu Naming-Conventions allgemein:
http://www.irritatedvowel.com/Progra...Standards.aspx

Im Prinzip finde ich, man sollte sich an so allgemeine Konventionen halten, insbesondere, wenn man irgendwann mal Code schreibt, der in Bibliotheken von anderen Entwicklern mitgenutzt werden soll.

[Luckie]

Der erste Link ist gut.

Mit welcher Version ich arbeite? Das wüsste ich auch gerne mal, ich weiß im Moment nicht auswendig, welches Framework ich installiert nocvh welches Framewok dem Projekt zu Grunde liegt.

[Phoenix]

Hehe ;-)

Also in der Regel kann man davon ausgehen: Visual Studio 2005 / die 2005er Express Edition: .NET 2.0 mit dem 'alten' C#-Compiler.

Visual Studio 2008 / die 2008er Express Edition: .NET 3.5 mit dem neuen C# Compiler.
Bei letzterem kann man aber im Projekt auch noch angeben, dass man ältere Framework-Versionen wie 2.0 / 3.0 als Ziel haben will.

Interessant ist hierbei insbesonders, dass man die neuen C# Compiler-Features wie Extension Methods und Lambda Expressions auch benutzen kann, wenn man das 2.0er Framework als Ziel hat. Nur für LINQ fehlt dort dann die System.Core.dll (dort sind eine Menge Extensions-Methods auf vielen Basis-Typen definiert, die für Linq benutzt werden). Man kann aber auch die System.Core.dll mit deployen und so Linq auch auf dem 2.0er Framework benutzen.

[Luckie]

Zitat:

Zitat von Phoenix

Hehe ;-)

Also in der Regel kann man davon ausgehen: Visual Studio 2005 / die 2005er Express Edition: .NET 2.0 mit dem 'alten' C#-Compiler.

Visual Studio 2008 / die 2008er Express Edition: .NET 3.5 mit dem neuen C# Compiler.
Bei letzterem kann man aber im Projekt auch noch angeben, dass man ältere Framework-Versionen wie 2.0 / 3.0 als Ziel haben will.

Ich hatte mal die VS 2008 Beta installiert gehabt. Hab eich nach Ablauf des Testzeitraumes wieder deinstalliert. Jetzt weiß ich nicht, ob das .Net Framework 3.5 drauf geblieben ist, müsste ich mal nachgucken, aber so wichtig ist das im Moment noch nicht.

[Phoenix]

Also wenn Du mal Lust hast und ein wenig Zeit, dann schnapp Dir mal die 2008er Express und spiel mal mit den neuen Compilerfeatures rum. Insbesondere mit Linq auf Objektlisten. Ich finde es lohnt sich. Sowas in native Delphi und ich wär happy :mrgreen:

Hier ist noch ein netter Artikel, der ein paar Sauereien mit dem Zeug zeigt:
http://mikehadlow.blogspot.com/2008/...-fun-with.html

[Khabarakh]

Zitat:

Zitat von Luckie

Sie hat nur die Methoden, die ich auch brauche. Ich dachte, das wäre dann etwas einfacher zu Hand haben.

IMO: Bevor ich solchen Boilerplate Code schreibe, würde ich persönlich die paar Intellisense-Einträge mehr in Kauf nehmen ;) .
Anders ausgedrückt: Die WPF-Klasse Control hat 577 öffentliche Member. Danach macht man sich um List<> keine Gedanken mehr :zwinker: .

Zitat:

Zitat von Phoenix

@Unterstrich: Styleguide

Das sieht StyleCop aber anders :P . Selbst benutze ich weder "_" noch "this." :duck: .