Laden...

Wofür benutzt Ihr Partial Types ?

Erstellt von rockthecity vor 17 Jahren Letzter Beitrag vor 17 Jahren 2.632 Views
R
rockthecity Themenstarter:in
297 Beiträge seit 2005
vor 17 Jahren
Wofür benutzt Ihr Partial Types ?

Ausser für den Designer !

Urlaubsorte suchen: http://www.tripedio.de

T
68 Beiträge seit 2006
vor 17 Jahren

"Überischtlichkeit" wäre meine Antwort!

Wenn eine Klase halt so groß ist das man durch das Teilen eine bessere Übersicht bekommt sollte mann sowas schon mal teilen 🙂

Eine Code mit über 500 lines bei platzsparend schreibend ist schon etwas umfangreich und da etwas zu finden ist nicht so easy, da bietet sich halt dieser Komfort an.

Nach welchen Kritereien jeder einzelne das dann teilt bleibt jedem selbst überlassen.
Wenn bei mir so eine große Klasse entsteht teile ich sie meist in eine File für die Members + Properties + getters & Setter + Ctor and Inits und die andere für die ganzen Methoden und wenn es ganz schlimm ist teil ich die MEthoden noch in public und private teile.

56 Beiträge seit 2006
vor 17 Jahren

Es ist eben einfach eine weitere Möglichkeit den Klassenaufbau zu strukturieren und so ggf. übersichtlicher zu gestalten.

Wenn mehrere Entwickler eine Klasse erweitern, kann die Aufteilung ganz nützlich sein. Jeder Entwickler bekommt hat seine eigene Partial Class und schreibt seine Erweiterungen nur dort rein.

Ich selber verwende eigentlich nie partial. Große Klassen teile ich über Regionen in Bereiche auf. So habe ich alles in einer Datei und kann auf- und zuklappen nach Bedarf.

402 Beiträge seit 2005
vor 17 Jahren

Ich habe z.B. eine Klasse die so viel Funktionalität und Properties enthält, dass ich sie auf 3 Dateien (Public's, Private's und Initialisierung) zerlegt habe.

Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.

N
4.644 Beiträge seit 2004
vor 17 Jahren

Zum Beispiel eigenen Code einem typed DataSet oder einem typed TableAdapter hinzuzufügen.

49.485 Beiträge seit 2005
vor 17 Jahren

Hallo rockthecity,

in der SDK-/MSDN-Doku steht auch sowas (ok, es steht nicht wirklich drin, wozu wir das benutzen, aber es steht drin, wofür man es benutzen kann):

Einen Klassen-, Struktur- oder Schnittstellentyp auf mehrere Dateien aufzuteilen kann hilfreich sein beim Arbeiten mit großen Projekten oder mit automatisch generiertem Code. Weitere Informationen finden Sie unter
>
.

Und im genannten Abschnitt steht:

Es ist möglich, die Definition einer Klasse, einer Struktur oder einer Schnittstelle auf zwei oder mehr Quelldateien aufzuteilen. Jede Quelldatei enthält einen Abschnitt der Klassendefinition, und alle Teile werden bei der Kompilierung der Anwendung miteinander kombiniert. Es gibt mehrere Situationen, in denen das Teilen einer Klassendefinition von Vorteil sein kann:
Beim Arbeiten an großen Projekten ermöglicht das Aufteilen einer Klasse auf verschiedene Dateien mehreren Programmierern, gleichzeitig daran zu arbeiten.

Beim Arbeiten mit einer automatisch generierten Quelle kann der Klasse Code hinzugefügt werden, ohne die Quelldatei neu erstellen zu müssen. Visual Studio verwendet diesen Ansatz beim Erstellen von Windows Forms, Webdienst-Wrappercode usw. Sie können Code erstellen, in dem diese Klassen verwendet werden, ohne die von Visual Studio erstellte Datei bearbeiten zu müssen.

Generierter Code heißt dabei nicht nur Designer. Es gibt auch andere Code-Generatoren und man kann sich auch selber welche schreiben.

Beim Aufteilen aus Übersichtlichkeitsgründen wäre ich allerdings etwas skeptisch. Klassen, die so groß werden, dass man sie aufteilen will/muss, sollte man i.d.R. in mehrere unterschiedliche Klassen aufteilen und nicht mit partial. Klassen aufzuteilen, damit verschiedene Programmier daran arbeiten können, kann allerdings Sinn machen, auch wenn es nur sehr, sehr selten vorkommen wird und man auch da überlegen muss, ob man nicht mit mehreren unterschiedlichen Klassen besser fährt.

Mein Fazit ist: partial ist toll für Codegeneratoren. Für andere Zwecke braucht man es eher nicht oder sollte sogar die Finger davon lassen.

herbivore

1.985 Beiträge seit 2004
vor 17 Jahren

Hallo zusammen,

ich schließe mich Noodles und herbivore an. Partielle Klassen sind hervorragend, um eigenen Code zu Klassen hinzuzufügen, die auf irgendeine Art und Weise automatisch generiert wurden.

Von der manuellen Aufteilung von Klassen halte ich persönlich nicht so viel.

Gruß,
Fabian

"Eine wirklich gute Idee erkennt man daran, dass ihre Verwirklichung von vornherein ausgeschlossen erscheint." (Albert Einstein)

Gefangen im magischen Viereck zwischen studieren, schreiben, lehren und Ideen umsetzen…

Blog: www.fabiandeitelhoff.de

S
95 Beiträge seit 2006
vor 17 Jahren

Tach beisammen,

ich persönlich halte von einer Aufteilung des Codes auf partielle Klassen auch ned soviel. Weil wenn man wirklich große Klassen hat (so 1000 Zeilen aufwärts) bietet sich doch eine Gliederung in Regions an. Damit hat man auch eine Klasse übersichtlich gestaltet und kann die nicht benötigten Codeblöcke einfach ausblenden 😄.
Man hat aber trotzdem den ganzen wichtigen Klassen-Code in einer Datei. (Außer im VS2005 beim Designer)

Syrinx

Das größte Misstrauensvotum gegen Gott ist ein Blitzableiter auf dem Kirchturm! 😁

B
21 Beiträge seit 2006
vor 17 Jahren

Original von Syrinx
Tach beisammen,

[...] Weil wenn man wirklich große Klassen hat (so 1000 Zeilen aufwärts) bietet sich doch eine Gliederung in Regions an.[...]
Syrinx

also wenn ich mal ne klasse mit über 1000 loc habe, mach ich mind. 2 klassen daraus 😉
ansonsten, wie syrinx schon sagte, einteilung in regions zwecks übersichtlichkeit

S
95 Beiträge seit 2006
vor 17 Jahren

Original von belial

also wenn ich mal ne klasse mit über 1000 loc habe, mach ich mind. 2 klassen daraus 😉

Tja, manchmal ist es aber von Nöten (z. B. wenn du eine Methode mit über 800 loc hast) 😉

Das größte Misstrauensvotum gegen Gott ist ein Blitzableiter auf dem Kirchturm! 😁

B
21 Beiträge seit 2006
vor 17 Jahren

Original von Syrinx

Original von belial

also wenn ich mal ne klasse mit über 1000 loc habe, mach ich mind. 2 klassen daraus 😉

Tja, manchmal ist es aber von Nöten (z. B. wenn du eine Methode mit über 800 loc hast) 😉

tja, eine methode mit über 800 loc kann man aber wieder aufteilen in mehrere methoden 😉
kann man halt so weiterspielen, jedoch sollte jeder für sich entscheiden, wie er aufteilt

1.271 Beiträge seit 2005
vor 17 Jahren

Ralf Westphal zeigt in How partial classes can help Unit Testing noch eine Verwendungsmöglichkeit.

A wise man can learn more from a foolish question than a fool can learn from a wise answer!
Bruce Lee

Populanten von Domizilen mit fragiler, transparenter Außenstruktur sollten sich von der Translation von gegen Deformierung resistenter Materie distanzieren!
Wer im Glashaus sitzt, sollte nicht mit Steinen werfen.

K
174 Beiträge seit 2006
vor 17 Jahren

Hallo belial,

warum sollte man unbedingt eine Klasse mit mehr als 1000 loc in mind. 2 Klassen aufsplitten?

Ich geben Syrinx da schon recht (lange Methoden)... Man kann nicht immer alles Aufsplitten... naja und selbst wenn ich dann diese Methoden aufsplitte... warum sollte ich dann noch wieder in weitere Klassen verzweigen.

Gruß,
Kani

49.485 Beiträge seit 2005
vor 17 Jahren

Hallo Kani,

die 1000 LOCs sind nur ein Anhaltspunkt. Aufteilen sollte man die Klassen nicht nach Größe, sondern nach konzeptuellen/logischen Gesichtspunkten. Die sich in der Implementierung ergebende Größe ist eben nur ein Anhaltspunkt dafür, dass das Konzept/Modell noch nicht optimal ist.

Der Grund eine mittlere Größe bei Klassen anzustreben ist, dass die Komplexität einer Einheit (Statement, Menthode, Klasse, Assembly, ...) überportional mit der Größe wächst. Deshalb schreibt man ja in der Regel auch keine monolitischen Anwemdungen mehr.

Andererseits wächst die Komplexität auch überproportonal mit der Anzahl der Einheiten. Deshalb sollte eine Klassse auch nicht mglichst klein sein, weil man dann eben sehr viele Klassen braucht. Deshalb strebt man eben (als ein Entwurfskriterium) eine mittlere Größe an.

herbivore

K
174 Beiträge seit 2006
vor 17 Jahren

Hallo herbivore,

Aufteilen sollte man die Klassen nicht nach Größe, sondern nach konzeptuellen/logischen Gesichtspunkten.

Das sehe ich genauso und so mache ich es auch.
Nur 1000 loc sind manchmal ziemlich schnell erreicht. Ich will damit nicht sagen, dass mir das ständig passiert, aber in unserer Anwendung dürften es so ca. 5 von >500 Klassen sein, welche die 2000 loc anpeilen. Aber eben genau diese Klassen kann und darf man nicht mehr aufsplitten (bzw. es würde keinen Sinn machen, da sonst hinterher zusätzlicher Programmieraufwand und anderer overhead entstehen würde.

Andererseits wächst die Komplexität auch überproportonal mit der Anzahl der Einheiten. Deshalb sollte eine Klassse auch nicht mglichst klein sein, weil man dann eben sehr viele Klassen braucht. Deshalb strebt man eben (als ein Entwurfskriterium) eine mittlere Größe an.

Stimme ich dir auch zu.

Was ich eigentlich sagen will ist, dass ich denke, dass man manchmal die Typischen Entwurfsmusterregeln doch brechen muss, da man sonst an manchen stellen einen verwaltungsoverhead hätte. Das ist mir auch schon öfter beim DB-Design aufgefallen. Nicht immer ist die 3. Normalform angebracht.-->Manchmal müssen daten mehrfach abgelegt sein, da die Statements sonst unüberschaubar werden. (Lieber n Kommentar mehr und 2-3Zeilen Quelltext die sich um die Verwaltung der zusätzlichen Daten kümmern)
Nun ja, jedenfalls sind das so meine Erfahrungen (und die meines Teams) und wir sind bisher so sehr gut gefahren.

Grüße,
Kani