OOP: Subklassen / Subobjekte

[litterauspirna]

Nunja es ist ja auch der Sinn keine Abhängigkeiten da drin zu schaffen. Eine Maschine und ein Artikel haben dierekt keie Abhängigkeit.

Artikel und Maschinen, die diese produziert haben musst z.B. in deiner Datenbank unterbringen. Über geeigente Models kannst du dann diese Daten in einem Zusammenhang auslesen. Eine Abhängigkeit zwischen Maschine und Artikel wird somit nur in der Datenbank gebildet, da wo sie auch hingehört. In deiner Software hat diese Abhängkeit nichts zu suchen.

In deiner DB stellst du ja auch erst die Abhängigkeit Auftrag -> Auftrag Details her. Somit also auch die Abhängikeit Maschine -> Artikel.

Softwaretechnisch kann man sich den Ablauf so vorstellen.

1.) Auftrag kommt zu stande
2.) zu Produzierende Artikel werden aus dem Auftrag entnommen
3.) Maschinen für Aufragsproduktion werden bereitgestellt
4.) Maschinen werden für Auftragsproduktion konfiguriert (Anzahl Produkte z.B.)
5.) Herstellungsprozess wird gestartet, die Maschinen stellen nun Teilartikel oder Artikel her. Da musst du dich eben Softwaretechnisch auch darum kümmern, es kann ja auch vorkommen das für die Fertigstellung von Produkten Abhängigkeiten entstehen. Heist das erst ein Teil des Produktes fertig gestellt sein muss bevor der andere Teil produziert werden kann und erst danach ein ganzes Produkt entsteht.
6.) Während der Produktion werden Werte der Maschinen etc. in die DB geschrieben.
7.) Produktion für Auftrag ist fertiggestellt, alle Maschinen haben ihre Arbeit getan.
8.) Auftragsprotokoll wird über die gesamte Auftragsproduktion erstellt.

Das ist mal so der grobe Ablauf.

Ich emfpehle dir hier, sehr viel Zeit in die Planung und die Modelierung deiner Software zu investieren bevor du auch nur eine Zeile Code schreibst.
Benutze gegebenenfalls wenn es sich dafür anbietet Frameworks, die es dir erleichtern dein Projekt gut strukturiert und sauber getrennt umzusetzen.

[Guenni61]

Hallo,
. . .
[EDIT]
@Guenni61, dein Beispiel von Vererbung (Ableitung) kann man leider falscher nicht darstellen. Eine Maschine ist kein Artikel,
sondern eine Maschine produziert einen Artikel, besser sogar sie erzeugt ein Produkt, ein Artikel wird es erst wenn es Angeboten wird
zum Kauf und über einen Preis etc. verfügt.
Eine Auswertung ist auch keine Maschine, in einer Auswertung werden höchstens Maschinen die für einen Produktionsauftrag benutzt
wurden gelistet mit diversen Detail Auswertungsdaten.
Immer daran denken, eine Vererbung stellt immer (ausnahmslos immer) einen spezialisierten IST Zustand von Klassen (Objekten) dar.
Für den TE wären hier noch Punkte wie Dependensy Injection und Dependensy Injection Container ne gute Sache zum nachlesen.

Hi Litter,

zu aller erst ging es dem TO ja mal darum, solche Zugriffe auf Variablen zu vermeiden:
$this->maschine['testmaschine1']->artikel['1000']->prodauf['1215']->proddetail[0]

Dass eine Maschine kein Artikel (kein Produkt) ist und eine Auswertung keine Maschine, ist mir schon klar. Das soll diese Ableitung,
oder besser gesagt Erweiterung, denn to extend bedeutet ja erweitern, auch gar nicht ausdrücken. Sondern das, was to extend
bedeutet: Eine Klasse um die Variablen und Methoden einer anderen Klasse zu erweitern. Statt also in einer Klasse eine Variable vom Typ andere Klasse
anzulegen, eine Klasse von der anderen die Eigenschaften und Methoden erben lassen, damit die erbende Klasse direkt Zugriff auf Eigenschaften hat.
Und nicht über $this->maschine['testmaschine1']->artikel['1000']->prodauf['1215']->proddetail[0].

Jetzt könntest du natürlich einwenden: "Deine Vererberei (Ableitung, Erweiterung) ist Quatsch, dann kann ich auch alle Eigenschaften und Methoden in
einer Klasse unterbringen". Kann man das? Ich denke nein. Jedes Produkt hat hat spezielle Parameter. Und dem nach kann ich ein Produkt nur auf einer Maschine
fertigen, die für ein bestimmtes Produkt gebaut wurde.

class produkt1{hat spezielle Parameter1}
class produkt2{hat spezielle Parameter2}
class produkt3{hat spezielle Parameter3}

class maschine1{erfüllt spezielle Parameter1} extends class produkt1 {hat spezielle Parameter1}
class maschine2{erfüllt spezielle Parameter2} extends class produkt2{hat spezielle Parameter2}
class maschine3{erfüllt spezielle Parameter3} extends class produkt3{hat spezielle Parameter3}

Heißt das jetzt, dass ich aus einer Maschine ein Produkt mache, oder aus einem Produkt eine Maschine?

Nein. Es heißt einfach nur, dass ich in einer Instanz einer Klasse die jeweiligen Eigenschaften und Methoden beider Klassen nutzen kann,
um einen Produktionsauftrag darzustellen.

$instanz1 = new maschine1;
$instanz2 = new maschine3;

Zu deiner Aussage . . .

Artikel und Maschinen, die diese produziert haben musst z.B. in deiner Datenbank unterbringen. Über geeigente Models kannst du dann diese Daten
in einem Zusammenhang auslesen. Eine Abhängigkeit zwischen Maschine und Artikel wird somit nur in der Datenbank gebildet, da wo sie auch hingehört.
In deiner Software hat diese Abhängkeit nichts zu suchen.

. . . könnte man jetzt die Frage stellen: Wer war denn zuerst da? Das Huhn oder das Ei?

Üblicherweise ist eine Datenbank doch leer, wenn ich eine Software das erste mal benutze. Was wäre denn jetzt zu tun?
Die Datenbank zu erstellen, Tabellen zu füllen, und dann erst die Software benutzen?

Oder ist es nicht so, dass die Software die Datenbank/Tabellen füllt?

Gruß
Günni

[h3ll]

Jetzt könntest du natürlich einwenden: "Deine Vererberei (Ableitung, Erweiterung) ist Quatsch, dann kann ich auch alle Eigenschaften und Methoden in
einer Klasse unterbringen". Kann man das? Ich denke nein. Jedes Produkt hat hat spezielle Parameter. Und dem nach kann ich ein Produkt nur auf einer Maschine
fertigen, die für ein bestimmtes Produkt gebaut wurde.

class produkt1{hat spezielle Parameter1}
class produkt2{hat spezielle Parameter2}
class produkt3{hat spezielle Parameter3}

class maschine1{erfüllt spezielle Parameter1} extends class produkt1 {hat spezielle Parameter1}
class maschine2{erfüllt spezielle Parameter2} extends class produkt2{hat spezielle Parameter2}
class maschine3{erfüllt spezielle Parameter3} extends class produkt3{hat spezielle Parameter3}

Heißt das jetzt, dass ich aus einer Maschine ein Produkt mache, oder aus einem Produkt eine Maschine?

Ja, genau das heißt das. Wer sowas macht, hat den Sinn von Ableitungen (noch) nicht verstanden.

Programmieren findet erstmal mit Papier und Bleistift statt. Zeichne dir Klassen/Objekte und deren Methoden und Eigenschaft auf Papier auf. Welche Zusammenhänge gibt es?

Wenn du ein Objekt in einem anderen Objekt benötigst, dann übergib es. Eine Ableitung dient nicht dazu die Funktionalität eines Objekts in einem anderen Objekt zur Verfügung zu stellen.

Üblicherweise ist eine Datenbank doch leer, wenn ich eine Software das erste mal benutze. Was wäre denn jetzt zu tun?
Die Datenbank zu erstellen, Tabellen zu füllen, und dann erst die Software benutzen?

Oder ist es nicht so, dass die Software die Datenbank/Tabellen füllt?

Üblicherweise ist es so, dass man sich das Datenmodell auf Papier (oder von mir aus auch in elektronischer Form) aufzeichnet. Lange bevor man überhaupt ans Programmieren denkt. Aus dem Datenmodell ergibt sich dann automatisch die Datenbankstruktur sowie auch die Modell-Klassen. Es gibt sogar Tools, die aus einem Datenmodell die Datenbankstruktur und Klassen automatisiert erstellen. Also das ist eigentlich eine ziemlich "dumme" Arbeit. Der größere Leistung ist erst mal ein vernünftiges Datenmodell zu entwickeln. Und dafür braucht man Hirn und keinen Computer.

[Relativity]

Hallo zusammen,

ich bedanke mich hiermit abschließend bei allen Beteiligten für die vielen Antworten, möchte aber abschließend noch folgendes erneut zum Ausdruck bringen, da es etwas untergegangen zu sein scheint:

- die Datenbank, aus der die Daten stammen, ist nicht von mir, sondern aus einem bestehenden ERP System, an das ich nicht dran packen werde/kann/darf. Es ist daher contra-produktiv über die Struktur der Daten und deren Optimierung als Lösungsvorschlag zu reden, da ich nicht dran darf

- der gesamte Produktionsprozess ist bereits abgebildet, es geht hier um eine nachträgliche Auswertung der Effektivität abgeschlossener Produktionsaufträge. Ob ein Fehler im Modeling der Datenbank und der Art der Ablage der Daten damals gemacht wurde vom Entwickler - ich weiss es nicht - das ist aber auch nicht meine Aufgabe dies zu beurteilen sondern mein Job ist es die Daten dennoch auszuwerten.

- Eine Vorselektion innerhalb der Datenbank ist nicht möglich, da innerhalb der Datenbank es keine Verknüpfung zwischen der Maschine und dem auf ihm gefertigten Produkt gibt, es gibt eine Sortier-Reihenfolge in welcher immer zuerst die Maschine steht, anschließend die Arbeitsschritte des Personals, auf dieser Maschine, dann folgt wieder eine Maschine etc. bis der produktionsauftrag abgeschlossen ist - nichts was ich in irgendeiner Weise (mit meinem SQL Wissen) effektiv verarbeiten konnte, da nur Teile des Produktionsauftrags einer Maschine zugewiesen sind, und andere wiederrum einer anderen Maschine. Daher gibt es in den Header Daten des Prod.Auftrags auch keine Information zur Maschine, da mehrere verwendet werden.

- meine Zielführung war nicht gewesen neue Datenbanken anzulegen und quasi alle Daten hinterher doppelt zu haben, oder gar das gesamte Prod.Modul der ERP Lösung neu zu entwickeln, sondern die bestehenden Daten möglichst effektiv auszuwerten aus der Datenbank, in der sie bereits stehen.

- Ich habe nicht eine Klasse extended - darum ging es auch nie - es ging um Objekte, welche wiederrum Sub-Objekte erzeugen.

- Es ging primär darum, das die Verschachtelung von Objekten mit weiteren Sub-Objekten innerhalb des Quellcodes sehr unübersichtlich wurde und ich evtl. irgendetwas übersehen habe / noch nicht kannte, was dies hätte einfacher und übersichtlicher machen können.

- Ich bin nach wie vor der Meinung, das die Verwendung von entkoppelten Objekten, die in keinerlei Relation zueinander stehen, in meinem Fall sehr ressourcen-ineffektiv ist, da ich jedesmal alle Objekte durchlaufen lassen muss um die Objekte dem User darzustellen, welche die von ihm gewählte Maschine betreffen.



Im Normalfall hätte ich eigenständige Klassen für Maschinen, Artikel etc. gehabt, welche nichts miteinander zu tun gehabt hätten und hätte diese einfach mit speziellen SQL Querys mit Daten befüllt und hinterher ausgegeben.

Wie oben bereits erwähnt geht es in diesem Fall nicht, sondern alle Daten müssen über das Datum von / Datum bis ausgelesen werden und durch eine Schleife stur in die entsprechenden Objekte geschrieben werden.

Hierfür hatte ich nun zwei Lösungs-Möglichkeiten mir ausgedacht:

1. Die von mir beschriebene Sub-Objekt Methode, das die Maschine einfach ein Unterobjekt enthält, der Artikel, die auf ihr produziert werden usw.

2. Loose Objects, deren ID in dem logisch übergeordneten Objekt festgeschrieben werden. Als Beispiel:

$maschine[1000]->artikel

wäre dann ein Array in welchem die Artikelnummern stehen, der Artikel, die auf ihr gefertigt wurden, z.B.:

$maschine[1000]->artikel[0] wäre 1234
$maschine[1000]->artikel[1] wäre 5678

in Bezug zu

$artikel[1234] und $artikel[5678]

Ich bin von dieser Idee aber abgerückt, als ich merkte, das der Artikel 1234 sowohl auf Maschine 1000, als auch auf Maschine 1001 produziert werden kann, und in dem Fall nicht summiert werden darf, da ausgewertet werden soll, auf welcher Maschine er effektiver produziert wurde.

Somit bin ich auf meine erste Variante zurück gegangen und musste leider in die Subobjects runter gehen.


In diesem Sinne, euch allen vielen Dank und ein sonniges Wochenende.

Gruss
Relativity

[UzumakiNaruto]

also das DB problem scheint dir die arbeit ja ungemein zu erschweren und auch der community hier.

also ich weiß noch von meiner zeit als ich selber in einem unternehmen war das selber ein ERP system entwickelt hat und gelegentlich auch mit anderen ERP systeme kommunizieren musste, das dort mit visual fox pro der export aus dem externen ERP system so umgebaut worden ist das unser ERP system das verstehen konnte.

sowas könntest du doch auch machen oder nicht? natürlich ginge das auch mit php und jede nacht rackert der cron durch und erstellt dir deine DB so wie du sie brauchst.

oder wäre das keine option?

ich glaube die zeit die du damit verwendet hast mit der bestehenden DB klar zu kommen hätte gereicht um diese schnittstelle zu schreiben.