Harry B.

Hallo!

Bei der Suche nach Informationen zu Design Pattern bin ich auch auf dieses Forum gestoßen.

Um es gleich vorweg zu sagen: Ich programmiere nicht in PHP.

Mir geht es darum, ggf. eine Lösung mittels Design Pattern zu bekommen.

Eine bestehende Anwendung soll erweitert werden. Da das für diese Anwendung eine erhebliche Änderung bedeuten wird, habe ich mich entschlossen, es einmal mit Design Pattern zu versuchen.

Einiges zum Thema habe ich bereits gelesen, aber ich finde keinen Weg, zu meiner Aufgabenstellung einen passenden Lösungsansatz (sprich ein Pattern) zu finden.

Es wäre daher schön, wenn ich hier oder per E-Mail mit jemandem darüber diskutieren könnte.

__________________
Gruß, Harry B.
----------------------------------------------
Kaum macht man 's richtig, schon funktioniert 's!

Mister Ad

phpdummi

Na dann mal los:
Worum gehts, wie sieht die Anwendung aus, wofür möchtest du ein Pattern haben?

__________________
"Nobody is as smart as everybody" - Kevin Kelly
— The best things in life aren't things

Harry B.

Danke für das Hilfsangebot!

Die Anwendung kann man sich als Datengitter vorstellen:

1. horizontal die Zeit; eine Spalte pro Tag; Anzahl beliebig zur Laufzeit einstellbar.
2. vertikal die Außendienst-Mitarbeiter; eine Zeile pro AD-Mitarbeiter; Anzahl beliebig zur Laufzeit einstellbar.
3. Manche Tage (=Spalten) im Datengitter werden andersfarbig dargestellt (Wochenende, Feiertage, ...)
4. Es werden für die AD-Mitarbeiter Termine gebucht (von - bis); solche Buchungstermine können noch Erweiterungen (Personal, Material, ...) enthalten.
5. Die Termine haben unterschiedliche Buchungsfarben: Abrechnungsstand des Einsatzes (unbezahlt, teilweise bezahlt, vollständig abgerechnet, Arbeiten haben begonnen, Arbeiten wurden beendet, ...)
6. kleinste Zeiteinheit ist ein Tag

Neu:

1. kleinste Zeiteinheit soll jetzt Stunde, Minute, Sekunde, ... sein
2. Beginn oder Ende einer Buchung würde nicht mehr am Anfang bzw. Ende einer Tagesgrenze (=Spaltengrenze) sein, sondern je nach Uhrzeit irgendwo mittendrin.
3. Die Ad-Mitarbeiter sollen in zur Laufzeit einstellbaren Gruppen (Nord, Ost, Süd, West, Alle, ...) angezeigt werden können. (Unnötig zu sagen, dass das heute auch mit einem Attribut in einem Array geschieht.)

Fragen:

1. Wie verwaltet man die einzelnen Buchungen effizient? Heute geschieht das in einem dynamischen Array. Wäre eine Klasse nicht besser?
2. Es können auch mal 100+ Buchungen im aktuellen Ausschnitt sichtbar sein. Sind Performance-Probleme zu erwarten, wenn man von Arrays auf Klassen umstellt?
3. Wie zeichnet man die einzelnen Buchungen effizient? Heute geschieht das über ein Array, das die Buchungsdaten enthält und mit vielen, vielen IF-Bedingungen. Wäre hier nicht auch eine Buchungsklasse besser, die selber ihren Abrechnungsstatus kennen würde, und somit auch wüsste, wie gezeichnet werden muss?
4. Könnte man alle sichtbaren Buchungen nicht mit einem Pattern verwalten?
5. Wäre die einzelne Buchung selbst nicht evtl. auch mit einem Pattern besser greifbar, da sie ja erweiterbar (Personal, Material, ...) ist und je nach Zustand verschieden dargestellt werden soll?
6. Sind die sichtbaren AD-Mitarbeiter nicht selbst wiederum per Pattern erfassbar, die ggf. nur je nach Attribut angezeigt werden und weil sie ja im aktuell dargestellten Zeitraum verschieden viele Buchungen haben können?

Wünsche:

1. Ich würde mich freuen, wenn Du sagen könntest, packe dies und das in das Pattern A und jenes in das Pattern B
2. Vielleicht gibts es aber auch verschiedene Design-Ansätze, mit unterschiedlichen Vor- und Nachteilen.
3. Evtl. kann man auch sagen, ob irgendwo etwas per Interface gemacht werden sollte. Die Anwendung wurde nämlich in Visual Objects (dem Clipper-Nachfolger) programmiert, und diese Sprache unterstützt Interfaces eigentlich nicht. Es gibt dafür aber eine sehr schöne Lösung, "Quasi-Interfaces" nachzubilden, was ich auch schon mal gemacht habe. Es bin es halt nur (noch) nicht gewohnt, Interfaces zu verwenden und übersehe vielleicht dafür prädestinierte Stellen.
4. Und wenn am Ende die Aussage lautet, alles weiterhin mit Arrays und IF-Orgien zu lösen, dann ist das auch ok! Aber das erwarte ich eigentlich nicht.

Ich würde versuchen, die Vorschläge zu überdenken und ggf. weitere Fragen stellen.

__________________
Gruß, Harry B.
----------------------------------------------
Kaum macht man 's richtig, schon funktioniert 's!

dr.e.

Hallo Harry B.,

zunächst ein Herzliches Willkommen bei uns im Forum. Da man mir nachsagt, ich würde mich mit dem Thema Software-Design gut auskennen, werde ich versuchen deinen Post zu beantworten. Gib mir jedoch bitte noch einen Tag Zeit, ich muss nach einem anstrengenden Wochenende etwas Schlaf nacholen...

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

nikosch

Samstag feiern und auf Arbeit schlafen! Das sind die richtigen...

@Harry B. Du solltest die Problematik erstmal etwas allgemeiner formulieren (noch nicht an Pattern denken). Überhaupt benutzt Du den Begriff sehr weitläufig, in meinem Verständnis ist der enger gefasst und meint Implementierungsansätze.

Auch die Anmutung (quasi das User Interface) und die Prozessmodellierung solltest Du getrennt formulieren. Man würde also bspw. erstmal definieren wir haben Personen (Aussendienstler), Termine, Buchungen etc. die in dem und dem Verhältnis zueinander stehen. Ob der Kalender Wochentage anzeigt oder der Chefeintrag nen rote Ecke bekommt steht auf einem komplett anderen Blatt.

Aber jetzt räume ich das Feld für unseren Design Guru. Der kann das alles nämlich viiiel besser. Allerdings erst, wenn er ausgeschlafen hat.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

dr.e.

Hallo Harry B,

die Aussagen

und

verleiten mich zu der Aussage, dass du im Bereich Software-Design selbst noch nicht sehr viel unterwegs gewesen bist. Du beschreibst durchwegs durchmischt UseCases und Implementierungsdetails. Ich würde hier wesentlich abstrakter vorgehen und zunächst alle UseCases (=Anwendungsfälle aus sicht des Benutzers / der Benutzer) beschreiben. Anschließend ergibt sich daraus mehr oder weniger die Menge der Daten, die für die Bereitstellung der Funktionalitäten benötigt wird. Weiterhin ist es nach einem weiteren Verfeinerungsschritt möglich, ein Domänen-Modell zu erstellen, das als Ergebnis die Inhalte der Überlegungen zu

summiert. Sich in dieser Phase der Software-Entwicklung bereits mit Array vs. Objekte zu beschäftigen halte ich für nicht zielführend. Schon wichtig ist, sich zu entscheiden, ob eine objektorientierte oder eine prozedurale Sprache zum Einsatz kommen soll, denn objektorientierte Analyse und prozedurale Umsetzung sind nicht gerade sehr effiziente Partner.

Wie Software-Entwicklung ablaufen sollte - sofern man einen nicht agilen Ansatz wählt - kannst du im Dokument http://adventure-php-framework.org/f...plomarbeit.pdf nachlesen.

Da sich Design-Pattern - wie bereits angesprochen - mehr um Implementierungsdetails und Software-Architektur kümmern, würde ich für die weitere Vorgehensweise vorschlagen, dass du zunächst die Anforderungen in der im referenzierten Dokument beschriebenen Art und Weise dokumentierst, dann können wir hier deutlich besser helfen.

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Harry B.

Das kann ich probieren; aber ob ich das bezahlt bekomme, weiß ich nicht. Es handelt sich um ca. 140.000 Zeilen extremst "gewachsen" Codes, bei dem versucht wurde, objektorientiert zu programmieren, weil es die Programmiersprache hergibt.

Daher würde dann wohl eher eine Neuprogrammierung anstehen, wenn ichs gemäß Deinem Ratschlag wissenschaftlich angehen würde.

Ich werde sehen, was ich da machen kann.

__________________
Gruß, Harry B.
----------------------------------------------
Kaum macht man 's richtig, schon funktioniert 's!

dr.e.

Hallo Harry B.,

angesichts der 140.000 Zeilen Code würde ich das auch anstreben. Meiner Erfahrung nach ist neu programmieren oft um Faktoren besser als gewachsenen Code zu optimieren. Ob man nun wasserfallmäßig - wie im Dokument beschrieben - vorgeht oder iterativ, ist im Grunde nicht so wichtig. Einzige Bedingung: die bestehende Software wird einer Analsye unterzogen.

Ich würde die Vorgehensweise nicht "wissenschaftlich" nennen, sondern standardisiert. Hierzu kann ich dir das Buch Softwaretechnik von Johannes Siedersleben empfehlen. Dieses beschreibt klassische Vorgehensweisen zur analytischen Beschreibung einer Software.

Heute wählt man oft agilere Vorgehensweisen zur Analyse und Implementierung der Software. Hierzu gibt es jedoch einige gute Literatur (z.B. zu Scrum) bei Amazon. Ich würde dir jedoch empfehlen mit klassischeren Entwurfsmethoden zu beginnen.

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~