Jump to content

Recommended Posts

Geschrieben

Prolog:

Da ich nicht aus der Programmierszene stamme und ich mir alles selbst anlernen muss, bin ich derzeit an einem Punkt, wo ich konfus auf dem Bahnhof stehe und nur noch ICE´s am vorbei rauschen sind.

 

Vorstellung:

Die Frage ist recht simple, ich will einen Übersichtsform haben und Unterformen für spezifische Teile.

z.B.

Hauptform - Overview - Ansicht des Akkuzustandes

2. Form - Stackinfo - Ansicht der angeschlossenen Elemente

3. Form - I/O - Manuelles setzen der I/O

4. Form - Drive - manuelles Fahren des Robots

 

Problem:

Ich habe den Faden verloren, irgendwo zwischen Array, List, Dataset, Datatable,Dataview, Globalen Variablen und IP Connection.

 

Aufgabe:

1. Wie verarbeitet man am sinnvollsten die Verbindungen und Daten der Bricks. z.B. Datenbank?

2. Wie habe ich zugriff auf alle Daten in allen Formen?

3. Ist meine Vorstellung umsetzbar oder ist das Thema Perfomance der Knackpunkt?

 

 

GUI_alt.PNG.69980068ebe8023401fc586c456349a4.PNG

GUI_neu.PNG.6f7a12eed3038afc56fa7b50c32c9740.PNG

Geschrieben

zu 2 mach die Elemente Public (bad and easy) oder du erstellt für alle Daten eine Methode.

zu 1 woraus willst du hinaus?

zu 3 ist machbar.

 

Es gibt verschiedene Wege um die Forms aufzubauen:

1-> Man kann die einzelnen Ansichten in Usercontrols packen und diese dann auf der Hauptform ein- und ausblenden.

2-> Du kannst auch ein Tabcontrol verwenden und so die Ansichten trennen.

3-> Du öffnest aus einer Hauptform andere Forms.

Ich würde Lösung eins bevorzugen.

Geschrieben
zu 2 mach die Elemente Public (bad and easy)

 

Ich habe schonmal eine arme Programmiererin begleitet, die genau nach diesem paradigma arbeitete (da sie noch nie Objekt-orientiert arbeitete). Meine Erfahrung ist, dass das sehr schnell sehr schiefgehen kann. Zumindest wenn man es wirklich wild treibt (und das tut man schneller als man denkt :D)

 

Mein Tipp wäre es den Forms möglichst genau das zu geben was sie brauchen um ihren Job zu machen. Beispielsweise braucht i.d.R. niemand die IPConnection zu kennen, nachdem alle Bricks erstellt wurden. Die IPConnection muss nur der Programmteil kennen der Bricks drauflegt und der der die IPConnection zerstört. Die Programmteile die nur das Fahrzeug steuern brauchen Beispielsweise nur die Bricks.

 

Am Ende hängt alles von deinem speziellen Anwendungsfall ab und es geht auf jeden Fall auch alles public zu machen. Aber versuche trotzdem im Blick zu behalten welche Klasse von wo auf welche andere zugreift, ansonsten weißt du ganz schnell nicht mehr wo oben und unten ist und bekommst komische Abhängigkeiten. Beispielsweise solltest du skeptisch werden wenn das manuelle Fahren des Roboters nur dann möglich ist, wenn auch die Stackinfo-Form existiert.

 

Ausführliche Beschreibungen der Prinzipien für sauberen Code findet man beispielsweise hier:

http://www.clean-code-developer.de/Wertesystem.ashx (Vorsicht, religiöse Einstellung gegenüber sauberem Code ^^)

 

Ansonsten die zwei meiner Meinung nach wichtigsten Punkte:

Don't repeat yourself

Single-Responsibility Principle

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Gast
Reply to this topic...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Clear editor

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...