Frage zur Unit-Verwaltung

[RaSoWa1]

Hallo,
wie machen es die Profis?

Seit meiner Turbo-Pascal-Zeit sammele ich Funktionen und Prozeduren in einer Unit. Diese Unit führe ich dann einfach in der USES-Klausel meines aktuelles Projekt auf und kann dann ganz einfach auf die dort gesammelten Konstanten, Typen und Funktionen zugreifen. Diese ist nun mit den Jahren so umfangreich geworden, daß sich die Größe der EXE schon durch das bloße Einbinden dieser Unit verdoppelt.
Ich überlege nun, ob ich die große Unit in kleinere Units für String-, Grafik- ua. Methoden zerteile oder die verwendeten Methoden aus diesem Sammelsurium direkt in das jeweilige Projekt kopiere.

Ihr habt doch mit Sicherheit auch solche Sammlungen.
Wie verwaltet ihr diese?
Wie bindet ihr diese in eure Projekte ein?

Für ein paar Empfehlungen wäre ich dankbar.

Viele Grüße

Klaus

[Balu der Bär]

Zitat:

[..] oder die verwendeten Methoden aus diesem Sammelsurium direkt in das jeweilige Projekt kopiere.

Ja so mache ich es auch. Ich habe eine große Unit wo alle Sachen die man öfter mal braucht drin sind. Wenn ich ein neues Projekt starte kopiere ich einfach die Methoden etc die ich brauche aus der Unit in das neue Projekt.

[SirThornberry]

ich hab mir für Strings, Grafik etc. eine eigene Unit gemacht und darin ein Object mit Klassenmethoden erstellt. Somit binde ich dann die entsprechenden kleinen Units ein. Vom kopieren in das Projekt halte ich nicht viel denn ab und an fällt einem doch irgendwo ein Bug bzw. eine Verbesserungsmöglichkeit auf. Und dann ist es schön wenn die Bugbehebung in jedem Projekt drin ist und nicht nur in zukünftigen.

[Elvis]

Zitat:

Zitat von Balu der Bär

Zitat:

[..] oder die verwendeten Methoden aus diesem Sammelsurium direkt in das jeweilige Projekt kopiere.

Ja so mache ich es auch. Ich habe eine große Unit wo alle Sachen die man öfter mal braucht drin sind. Wenn ich ein neues Projekt starte kopiere ich einfach die Methoden etc die ich brauche aus der Unit in das neue Projekt.

Aber dann verwendest du ja nicht wirklich die ursprüngliche Implementierung.
Spätere Bug fixes sind also nicht in früheren Projekten Verfügbar und Bug fixes, die du innerhalb eines Projektes daran machst sind nicht in der ursprünglichen Unit.

@Klaus

Zitat:

Ich überlege nun, ob ich die große Unit in kleinere Units für String-, Grafik- ua. Methoden zerteile oder die verwendeten Methoden aus diesem Sammelsurium direkt in das jeweilige Projekt kopiere.

Ersteres klingt nach einem guten Start. Wenn es Code aus der TP-Ära ist wäre vllt auch ein wenig Umgestaltung zu OO angebracht. Vieles was prä-OO als elegant und nützlich erschien, dürfte heutzutage eher umständlich erscheinen.

[Balu der Bär]

Zitat:

Spätere Bug fixes sind also nicht in früheren Projekten Verfügbar und Bug fixes, die du innerhalb eines Projektes daran machst sind nicht in der ursprünglichen Unit.

Ja das ist schon klar, sollte dieser Fall wirklich einmal eintreten haben ich auch die 5 Minuten Zeit die Änderungen eben per Hand an den einzelnen Units zu machen. ;)

[Elvis]

Zitat:

Zitat von Balu der Bär

Zitat:

Spätere Bug fixes sind also nicht in früheren Projekten Verfügbar und Bug fixes, die du innerhalb eines Projektes daran machst sind nicht in der ursprünglichen Unit.

Ja das ist schon klar, sollte dieser Fall wirklich einmal eintreten haben ich auch die 5 Minuten Zeit die Änderungen eben per Hand an den einzelnen Units zu machen. ;)

:shock: Nehme mal etwas mentalen Abstand und lese dir den von mir zitierten Teil nochmal mehrfach durch. Was fällt auf? ;)

btw: Das ist übrigens ein nicht zu unterschätzendes Problem bei Versionsverwaltungen: Nehme ich globale Units mit hinein oder nur die Test Suites, die sicherstellen, dass der Code weiterhin das macht was er zu Zeitpunkt X machen sollte?

[Bernhard Geyer]

Zitat:

Zitat von Elvis

Zitat:

Zitat von Balu der Bär

Zitat:

Spätere Bug fixes sind also nicht in früheren Projekten Verfügbar und Bug fixes, die du innerhalb eines Projektes daran machst sind nicht in der ursprünglichen Unit.

Ja das ist schon klar, sollte dieser Fall wirklich einmal eintreten haben ich auch die 5 Minuten Zeit die Änderungen eben per Hand an den einzelnen Units zu machen. ;)

:shock: Nehme mal etwas mentalen Abstand und lese dir den von mir zitierten Teil nochmal mehrfach durch. Was fällt auf? ;)

Ich hoffe (für deine evtl. Kollegen) du machst das nicht in einem Team.
Glaubst Du das dein Kollege wenn er in der Unit A eine Änderung/Fix vornimmt, er alle Netzwerklaufwerke nach weiteren Units durchsucht?
Damit ist deine Vorgehensweise 1A ein Beispiel für das Anti-Pattern Programmierung mittels Copy & Paste

Ich hatte schon ein paar mal den Fall das Code kopiert wurde und diesen (unbeabsichtigte oder Aufgrund von akuten Zeitmangel) aufgetretenen Mehrfachen Code zu bereinigen und auf eine gemeinsame generische Codebasis zu stellen kostet mehr Zeit als gleich es vernünftig (ohne Copy & Paste) zu machen.

[Balu der Bär]

Zitat:

Ich hoffe (für deine evtl. Kollegen) du machst das nicht in einem Team.

Nein nein, ich arbeite Gott sei Dank still und alleine in meinem Kämmerchen. Das eine derartige Vorgehensweise im Team nicht durchsetzbar ist, ist mir schon bewusst. :stupid:

[thkerkmann]

Hi,

Zitat:

Zitat von SirThornberry

ich hab mir für Strings, Grafik etc. eine eigene Unit gemacht und darin ein Object mit Klassenmethoden erstellt. Somit binde ich dann die entsprechenden kleinen Units ein. Vom kopieren in das Projekt halte ich nicht viel denn ab und an fällt einem doch irgendwo ein Bug bzw. eine Verbesserungsmöglichkeit auf. Und dann ist es schön wenn die Bugbehebung in jedem Projekt drin ist und nicht nur in zukünftigen.

muss es unbedingt ein Objekt mit Klassenmethoden sein ?

Welchen tieferen Sinn hat das ?

Ich habe mich schon öfter gefragt warum viele Leute krampfhaft aus irgendwelchen utility Funktionen immer Klassen bauen.

Oder gibt es einen tieferen Sinn, den ich noch nicht verstanden habe. :gruebel:

[mirage228]

Zitat:

Zitat von thkerkmann

muss es unbedingt ein Objekt mit Klassenmethoden sein ?

Welchen tieferen Sinn hat das ?

Ich habe mich schon öfter gefragt warum viele Leute krampfhaft aus irgendwelchen utility Funktionen immer Klassen bauen.

Oder gibt es einen tieferen Sinn, den ich noch nicht verstanden habe. :gruebel:

Hi,

also ich könnte mir vorstellen, dass man damit versucht den Gedanken hinter OOP auf alle Bereiche anzuwenden.
Zudem gibt man durch die Bindung an eine Klasse ein gewisse Kategorie vor, z.B. TGraphicRoutines.ConvertToJPG(), was die Benutzung durch Dritte erleichtert.

Ich selbst praktiziere das jedoch auch nicht immer, da ich meistens für mich selbst programmiere und die handvoll Methoden (noch) nicht den Aufwand lohnen, so ein Klassengerüst drumzubauen.

mfG
mirage228