Einzelnen Beitrag anzeigen

StuRic

Registriert seit: 11. Jun 2013
8 Beiträge
 
#4

AW: dynamische Verwaltung von Objekten - Fahrstuhlsteuerung

  Alt 12. Jun 2013, 14:23
Danke für die zügige Antwort.


Wieviel Theoriewissen über Objektorientierung und Anforderungserhebung habt ihr mit auf den Weg bekommen? Die Anforderung von dir sagt "Fahrstuhlsteuerung, die eine beliebige Anzahl von Fahrstühlen, Etagen etc. verwalten & steuern kann". Kannst du mehr dazu erzählen? Gerade zur Methode Steuerung.Suche_Fahrstuhl(..) und insbesondere den Parametern kann ich mir spontan gar nichts vorstellen
Die Problemstellung ergibt sich bei mir aus dem Fach Softwaretechnologie heraus. Dort ist in Prinzip nur ein Erstellen von Use-Case-Diagrammen, Systemsequenzdiagrammen und ein anschließendes Klassendesign gefordert. Allerdings dachte ich es ist einfacher/realitätsnaher wenn ich es implementiere und dann sehe was geht und was nicht

Da ich das Ganze eher hobby-mäßig mache, beantwortet dass u.U. auch deine anderen Fragen:
Das bringt mich dann zu einem an sich erst einmal subjektiven Thema, hoffe aber, dass der Großteil der Belegschaft hier das ähnlich sieht: Ich finde den Code extrem schwer zu lesen, warum überhaupt die Records (und Zeiger)? Und warum keine gängigen Listentypen wie TList oder TObjectList ? Ist das eine zwingende Vorgabe? Man muss doch nicht in jedem Projekt die verkettete Liste neu erfinden...
Ich hab mich bis dato noch nicht damit beschäftigt. In Zukunft werde ich bestimmt eine elegantere Lösung wählen...

Zu Stilvorgaben und Namenskonventionen: Wie lange bist du schon bei Delphi dabei und von welcher Sprache kommst du? Mir kam es anfangs auch etwas dämlich vor, die Klassennamen immer mit T beginnen zu lassen, das ist sicher auch persönliches Gusto. Aber ich kann mir spontan keinen (hier passenden) Grund ausdenken, Konstruktoren und Destruktoren nicht Create und Destroy zu nennen, das bietet auf Dauer nur Verwirrungspotentiel.
Guter Einwand! Werde ich überarbeiten.

Wenn ich jetzt noch damit anfange, dass zumindest mein Kopf es spontan nicht schafft, den Zweck hinter Variablennamen wie sNiAnEt oder pFstKa zu erkennen, wendest du dich wahrscheinlich wie jeder vernünftige Mensch angewidert vom Forum (insbesondere von mir) ab, da du eigentlich aus einem anderen Grund hergekommen bist. Aber ich denke dass es viel schwerer ist, überhaupt durcheinander zu kommen, wenn man nicht an Buchstaben spart und außen am Funktionskopf dokumentiert, wozu die Werte die rein- und rausgehen überhaupt gut sind.
Öhm,...Platzgründe (sNiAnEt = string für "nicht anzufahrende Etagen"...). Kritik ist angebracht und erwünscht. Also keine Sorge, was das betrifft


So nun aber back to topic:
Gerade zur Methode Steuerung.Suche_Fahrstuhl(..) und insbesondere den Parametern kann ich mir spontan gar nichts vorstellen.
 Suche_Fahrstuhl soll die Liste durchgehen und die zu suchende Instanz der Klasse Fahrstuhl in Form eines Zeigers darauf (pTFstKa) ausgeben. Es soll einerseits nach der ID und andererseits nach der Erstellungsreihenfolge gesucht werden. Letzteres brauchte ich um mit Combob_FstKa.ItemIndex arbeiten zu können...So sieht die Funktion zur Zeit aus:
Delphi-Quellcode:
function Steuerung.Suche_Fahrstuhl(Suchkriterium, id_in, Stelle: cardinal):pTFstKa;
var i: integer;
begin
  result:= pFstKa;
  case Suchkriterium of
    1: begin
      //Id.....
    end;
    2: begin
      i:= 1;
      while i < Stelle do
      begin
        result:= result^.next;
        i:= i + 1;
      end;
    end;
  end;
end;

Zur Lösung des eigentlichen Problems: Entweder bin ich dumm (zum Ausgleich bin ich aber relativ schön), oder aus dem hier ersichtlichen Code lässt sich nichts finden. Meine Vermutung wäre, dass Steuerung.Suche_Fahrstuhl(..) keinen vernünftigen Zeiger zurückgibt, beispielsweise den Record nicht mittels new() auf dem Heap anlegt, sondern nur lokal "bei sich" auf dem Stack und dann einen Pointer auf Schrott zurückgibt.
Klingt plausibel. Allerdings wird, wie oben erkennbar, kein neues Listenelement hinzugefügt...Evt habe ich dich aber auch falsch verstanden.

Alternativ streicht bei mir der Debugger immer wieder gerne eine Zeile zu tief an, meint in Wirklichkeit die Zeile darüber. Setz doch mal einen Haltepunkt auf p1 := Steuerung1.Suche_Fahrstuhl(2,0,index); und geh dann schrittweise mit F7 durch und schau wo er rausfliegt.
Steuerung1.Suche_Fahrstuhl(..) durchläuft er ohne Probleme. Exception gibt es es nach wie vor bei Form.Caption:= 'Aufzug - Nr:' + inttostr(p1^.FstKaX^.id); Mir fällt übrigens noch eine potentielle Stelle ein, die den Fehler evt. hervorrufen könnte: Die hier verwendete Form wird dynamisch als eine von vielen Instanzen von TForm2 erstellt und ebenfalls einer Liste hinzugefügt...

Delphi-Quellcode:
//Form-Listen
  pForm2 = ^VForm2;

  VForm2 = record
    Form: TForm2;
    next: pForm2;
  end;
...
var //global
  Form1: TForm1;
  Steuerung1: Steuerung;
  Fenster_FstKa: pForm2;

var //lokal
    p,h: pForm2;
    Form: TForm2;
...
//_____________________Form in die Formen-Liste aufnehmen_______________
  //Listenelement hinzufügen
  p:=Fenster_FstKa;
  new(h);
  h^.next:=nil;
  //Objektinitialisierung:
  Form:= TForm2.Create(Application);
  h^.Form:= @Form;
  //an Liste anfügen
  if Fenster_FstKa=nil then Fenster_FstKa:=h
  else begin
    while p^.next<>nil do
    begin
      p:=p^.next;
    end;
    p^.next:=h;
  end;
Ich werde noch ein wenig weitersuchen, damit ich meinen bisherigen Code nach Möglichkeit weiterverwenden kann. Ansonsten wäre es auch kein Problem die Aufgabenstellung mit TObjectList o. Ä. zu realisieren.
Daher bitte ich um eine beispielhafte Lösung für: Eine beliebige Anzahl Instanzen einer Klasse (z.B. Fahrstühle) soll in eine TObjectList bzw. TComponentList eingetragen werden und anschließend über die Liste angesprochen werden (Property verändern, Methode aufrufen o. Ä.)

Vielen Dank für eure Mühen!!!

Geändert von StuRic (12. Jun 2013 um 15:08 Uhr)
  Mit Zitat antworten Zitat