Ab wann ist OOP eigentlich wirklich OOP?

[flashpixx]

Er spricht doch erstmal gar nicht von mehreren Zuständen sondern von Unterzuständen und deren Beobachtbarkeit.

Seit wann ist ein Zustand eines Objektes etwas hierarchisches, mir wäre es neu wenn in einem ea in einem Zustand eine Hierarchie existieren würde. Es gibt so etwas in machen Modellierungssystemen, aber von der Definition des ea gibt es keine Hierarchie.

[...] es einen privaten und einen öffentlichen Teil des Zustandes gibt [...]

Das ist kein Zustand, sondern ein View. Der Zustand ist hier gleich, denn ich verändere diesen ja nicht, ich verändere die Sicht auf das Objekt.

Naja, was sind denn dann bitte zusammengsetzte Zustände (teilweise autark).

Man kann hierarchische Zustände modellieren, das ist ein Modellaspekt, aber wenn ich das Modell in Code transformiere, compiliere und ausführe, dann kann ein Objekt, was letztendlich durch einen Speicherbereich im realisiert wird, zu einem Zeitpunkt keine zwei Zustände haben, denn letztendlich kann in der Speicherzelle nur eine 1 oder 0 stehen (mal abgesehen von der technischen Umsetzung).

Außerdem was würdest du dann in einem Aktormodel machen das ähnlich einem Petrinetz organisiert ist.

Auch das ist eine Modellierung, wenn ich mir einen Knoten des Netzgraphen anschaue, dann ist ein Zustand eindeutig. Denn um zu einem bestimmten Knoten zu gelangen muss ich anhand der Daten und der Übertragsfunktionen die Übergangsfunktion berechnen, damit ich in den Zustand wechseln kann. Es kann auch in einem Petrinetz nicht sein, dass die Übertragungsfunktion für gleiche Eingaben unterschiedliche bzw. widersprüchliche Ausgaben liefert.

Ich kann diese ebenso in neuronalen Netzen sehen, denn wenn ich in das Netz Daten hineingebe und das Netz iteriere, dann hat jede Kante und auch jeder Knoten zu einem Zeitpunkt einen Zustand, d.h. bei einem neuronalen Netz, dass z.B. ein Neuron zu einem Zeitpunkt t genau einen Bias, eine Berechnungsfunktion und einen Gewichtsvektor hat. Es kann nicht vorkommen, dass zu einem Zeitpunkt t, 2 verschiedene Werte für den Bias an ein und dem selben Neuron anliegen, weil in diesem Fall wäre nicht klar, wie damit umzugehen ist.

Wenn ich z.B. f(x) = 5*x habe, dann kann ich für die Eingabe f(3) nicht 15 und 20 raus bekommen. Natürlich kann man bei der Abbildungsfunktion Surjektivität zulassen, aber das würde dann f(x)=x^2 entsprechend.

Außerdem musst du explizit Mealy und Moore Automaten unterscheiden...

Rein formal nicht zwingend, denn ich Moore in Mealy (vice versa) überführen. Wenn es nach der Definition 2 Zustände geben würde, dann könnte es zu einem Moore Automaten zwei unterschiedliche Mealy Automaten geben (vice versa). Mir ist kein Beweis bekannt, der dieses inhaltlich belegen könnte

Bearbeitet 19. August 2012 von flashpixx

[Wodar Hospur]

Seit wann ist ein Zustand eines Objektes etwas hierarchisches, mir wäre es neu wenn in einem ea in einem Zustand eine Hierarchie existieren würde. Es gibt so etwas in machen Modellierungssystemen, aber von der Definition des ea gibt es keine Hierarchie.

Softwaretechnik I und weitere...

Rein von der Definition eines EA spricht aber auch nichts dagegen, da es explizit nur gesagt wird es gibt eine Menge von Knoten, ein Eingabealphabet, eine Übergangsfunktion, einen Startknoten, eine Menge von Zielknoten. Dort wird afaik nicht erwähnt das ein Knoten atomar sein muss. Ich kann also die Komplexität meines Automaten selber steuern. Das heißt ich könnte also eine direkt verbundene Gruppe von Zuständen, durch ihre Übergangstransitionen kapseln. Außerdem natürlich beziehe ich mich auf ein Modell. OO ist ein Modell. Die reine Definition von einem DEA bringt hier nichts .

Das ist kein Zustand, sondern ein View. Der Zustand ist hier gleich, denn ich verändere diesen ja nicht, ich verändere die Sicht auf das Objekt.

Es gibt einen öffentlichen und privaten Teil des einen Views? Es gibt 2 Teile eines Views?

Ich finde die Definition es gibt 2 Sichten (Views) und eine Menge der sichtbaren Attribute oder eine Transformationsfunktion verständlich. Für mich als Benutzer eines Objektes, hat dieses einen Zustand. Wenn ich diesen beschreibe, muss der nicht mit dem übereinstimmen wie der Entwickler des Objektes ihn beschreiben würde. Das endet übrigens in Haarspalterei.

Man kann hierarchische Zustände modellieren, das ist ein Modellaspekt, aber wenn ich das Modell in Code transformiere, compiliere und ausführe, dann kann ein Objekt, was letztendlich durch einen Speicherbereich im realisiert wird, zu einem Zeitpunkt keine zwei Zustände haben, denn letztendlich kann in der Speicherzelle nur eine 1 oder 0 stehen (mal abgesehen von der technischen Umsetzung).

OOP beschreibt ein Modell der Programmierung, die ganze Diskussion wird überflüssig wenn du auf de Level abdriftest. Denn dann bleiben wir bei, ld, st und paar Rechnereien. Btw. wie würdest du dann TLS beschreiben? Gibt es dann einfach mehrere Ausführungen von einem Objekt?

Auch das ist eine Modellierung, wenn ich mir einen Knoten des Netzgraphen anschaue, dann ist ein Zustand eindeutig. Denn um zu einem bestimmten Knoten zu gelangen muss ich anhand der Daten und der Übertragsfunktionen die Übergangsfunktion berechnen, damit ich in den Zustand wechseln kann. Es kann auch in einem Petrinetz nicht sein, dass die Übertragungsfunktion für gleiche Eingaben unterschiedliche bzw. widersprüchliche Ausgaben liefert.

Diese Annahme hast du selber, mit deiner, vielleicht wissentlichen, Fehlinterpretation der Aussage getroffen. Es geht doch gar nicht darum, dass auf einer Modellierungshierachie, zwei Zustände in der gleichen Region tätig sein können. In meinen Augen geht es um die Sichtbarkeit der Attribute in z.b. einem so modellierten DEA.

Ich kann diese ebenso in neuronalen Netzen sehen, denn wenn ich in das Netz Daten hineingebe und das Netz iteriere, dann hat jede Kante und auch jeder Knoten zu einem Zeitpunkt einen Zustand, d.h. bei einem neuronalen Netz, dass z.B. ein Neuron zu einem Zeitpunkt t genau einen Bias, eine Berechnungsfunktion und einen Gewichtsvektor hat. Es kann nicht vorkommen, dass zu einem Zeitpunkt t, 2 verschiedene Werte für den Bias an ein und dem selben Neuron anliegen, weil in diesem Fall wäre nicht klar, wie damit umzugehen ist.

Es geht nicht um den Determinismus, bzw. die Eindeutigkeit des Zustands.

Wenn ich z.B. f(x) = 5*x habe, dann kann ich für die Eingabe f(3) nicht 15 und 20 raus bekommen. Natürlich kann man bei der Abbildungsfunktion Surjektivität zulassen, aber das würde dann f(x)=x^2 entsprechend.

Öhm, ein Automat der nicht surjektiv ist, ist generell nicht optimal, da er Zustände beinhalten würde die nie erreicht werden. Wenn du die Mächtigkeit der akzeptierenden Zustände auf 1 beschränkst, wirst du sogar sehr häufig den Effekt haben, dass ein Knoten über mehr als eine Transistion erreicht werden kann. Aber ist das wichtig?

Rein formal nicht zwingend, denn ich Moore in Mealy (vice versa) überführen. Wenn es nach der Definition 2 Zustände geben würde, dann könnte es zu einem Moore Automaten zwei unterschiedliche Mealy Automaten geben (vice versa). Mir ist kein Beweis bekannt, der dieses inhaltlich belegen könnte

Kannst du, wenn du beide Definitionen kennst .

Aber interessanter ist ja das Verhalten an den Übergängen, afaik wird in UML 2 bei den Zustandsautomaten darauf eingegangen wo die Aktion, durch die Transistion getriggert wird ausgeführt werden soll und mit ihr auch eine Blockierung stattfindet.

[flashpixx]

Dort wird afaik nicht erwähnt das ein Knoten atomar sein muss. Ich kann also die Komplexität meines Automaten selber steuern.

Es geht hier nicht um Atomarität eines Zustandes. Es geht um die Übergangsfunktion, denn damit ist impliziert, dass zu einem Zeitpunkt nur ein Zustand vorliegen kann. Ich verweise auf Endlicher Automat in "Das mathematische Modell"

auf Transitionsrelation

Die Transitionsrelation einer formalen Grammatik G (bezeichnet durch den Operator ) ist eine Relation, die besagt, dass sich das Wort rechts des Operators unmittelbar, also durch eine einzelne Produktion, aus dem Wort links des Operators ableiten lässt.

dann zu http://de.wikipedia.org/wiki/Relation_(Mathematik)

Eine Funktion ist eine spezielle (nämlich eine linkstotale und rechtseindeutige, siehe unten) Relation (streng genommen ein Paar aus einer solchen Relation und der Zielmenge). Eine Relation im obigen Sinne entspricht auf eindeutige Weise einer Funktion f_r, deren Definitionsmenge das kartesische Produkt der Mengen ist und deren Zielmenge lediglich die Elemente wahr und falsch umfasst, wobei f_r(a, zu aRb äquivalent ist.

und dann auf http://de.wikipedia.org/wiki/Funktion_(Mathematik)

Eine Funktion ordnet jedem Element einer Definitionsmenge genau ein Element einer Zielmenge zu.

Dies impliziert, dass wenn ich mich in einem Zustand der "Software" / Automaten befinde, genau in einen anderen Zustand bei Ausführung einer Transitionsrelation übergehe. Träfe die Annahme zu, dass mehrere Zustände existieren würden, dann würde dies der Definition der Funktion u. a. widersprechen

Wenn zu einem Zeitpunkt dies möglich wäre, könnte z.B. ein Programm ein Fenster zugleich geöffnet, wie auch geschlossen haben, sprich ein Fensterhandle besitzen, dass existent und nicht existent ist

Bearbeitet 19. August 2012 von flashpixx

[Wodar Hospur]

Es geht hier nicht um Atomarität eines Zustandes. Es geht um die Übergangsfunktion, denn damit ist impliziert, dass zu einem Zeitpunkt nur ein Zustand vorliegen kann. Ich verweise auf Endlicher Automat in "Das mathematische Modell"

auf Transitionsrelation

dann zu http://de.wikipedia.org/wiki/Relation_(Mathematik)

und dann auf http://de.wikipedia.org/wiki/Funktion_(Mathematik)

Dies impliziert, dass wenn ich mich in einem Zustand der "Software" / Automaten befinde, genau in einen anderen Zustand bei Ausführung einer Transitionsrelation übergehe. Träfe die Annahme zu, dass mehrere Zustände existieren würden, dann würde dies der Definition der Funktion u. a. widersprechen

Schade das du den Beitrag von mir nicht mal gelesen hast, bzw. muss ich das durch deine Antwort annehmen. Ich kenne die mathematischen Definitionen. Diese sind doch gar nicht Gegenstand der Diskussion. Es geht um eine SWT Modellierung, die relevante Beschreibung ist nicht der DEA sondern wenn die UML 2 Zustandsübergangsdiagramme und dort der Automat. Mit der Möglichkeit einer Hierachie.

Hier kurz die Punkte wo ich darauf eingehe, warum leider dein letzter Beitrag nichts relevantes beiträgt.

Es geht nicht um den Determinismus, bzw. die Eindeutigkeit des Zustands.

Diese Annahme hast du selber, mit deiner, vielleicht wissentlichen, Fehlinterpretation der Aussage getroffen. Es geht doch gar nicht darum, dass auf einer Modellierungshierachie, zwei Zustände in der gleichen Region tätig sein können. In meinen Augen geht es um die Sichtbarkeit der Attribute in z.b. einem so modellierten DEA.

Außerdem natürlich beziehe ich mich auf ein Modell. OO ist ein Modell. Die reine Definition von einem DEA bringt hier nichts

[afo]

Ich lese gerade Object Thinking von David West. Harter Stoff. Aber gut. Ich habe intzwischen 1/3 gelesen. Bislang hat er als Leitlinien herausgearbeitet, dass Objekte sich durch ihr Verhalten auszeichnen und dass das zentrale Merkmal der OO die Composability von Objekten, also die Fähigkeit mit Objekten Dinge zusammenzusetzen, ist. Alles andere ergibt sich dann daraus.

Das ganze Buch geht halt sehr in Richtung XP. Wenn man mehr aus einer "Software Engineering"-Richtung kommt dann kann man sich damit schon schwer tun. Und, ach: Plato ist auch dabei.

[Gurki]

Muss ich das was über mir steht, eigentlich alles jetzt schon wissen? Irgendwie verstehe ich nämlich nur Bahnhof

[Aras]

Wenn du Informatik studierst dann solltest du das wissen.

[Gurki]

Fiae - 2. Lj.

[.vash]

Muss ich das was über mir steht, eigentlich alles jetzt schon wissen? Irgendwie verstehe ich nämlich nur Bahnhof

Sagen wir es so: Es besteht noch kein Grund zur Sorge. Wenn man über OO redet, dann redet man grundsätzlich über eine Geschichte voller Missverständnisse.

Zunächsteinmal ist es wichtig zu realisieren, dass OO - wie auf Seite eins schon erwähnt - mehr sein kann als die reine Organisation von Code und Programmbestandteilen. Man kann schon vor dem Codieren anfangen die Anforderungen in Objekte zu zerteilen und ein reines Begriffsmodell erstellen, aus diesem ein technisches Diagramm machen, daraus Software generieren lassen und dann die Methodenrümpfe fertig programmieren.

Soweit so einfach. Die prinzipielle Frage an die Herangehensweise werden die meisten die OO verstehen ähnlich beantworten. Sobald es aber an konkrete Fragen geht, dann sieht das oftmals ganz anders aus: Der eine möchte eine bestimmte Methode an diese Klasse hängen, der andere die Funktion lieber über ein Factorypattern abbilden. Hier ist es nun ganz wichtig zu erkennen, dass es nicht eine richtige Lösung gibt.

Denn wie beim herkömmlichen prozeduralen Programmieren kann man die meisten Lösungswege auf eine Unmenge an verschiedenen Wegen implementieren. Dabei will man möglichst alle Ziele der OO einhalten, sprich lose Kopplung der Objekte, Kapselung, etc. Das Problem hierbei ist, dass wenn man jedesmal wirklich alle Prinzipien einhalten will sehr schnell in eine Lösung und Diskussion abdriftet die viel komplizierter sein kann als die Realität es eigentlich erfordert.

Aus meinem Erfahrungsschatz kann ich sagen das OO es

- vereinfacht umfangreiche Programme zu erstellen

- Programme in einem Team aus mehreren Personen zu erstellen.

- Programme wartbarer machen kann

Wendet man OO falsch an, kann sich das alles aber auch schnell ins Gegenteil verkehren. Auch bedeutet es nicht dass die drei Punkte oben nicht auch in anderen Paradigmen möglich sind, nur die Herangehensweisen sind unterschiedlich.

Es für den einzigen sinnvollen Weg zu halten ist verkehrt. Darüberhinaus sollte man nicht den Fehler machen und denken, dass es

- Dokumentation ersetzt

- selbsterklärend ist

- schneller zum Ziel führt

- besser ist als andere Paradigmen

Insbesondere der letzte Punkt ist wichtig. OO begünstigt bei richtiger Anwendung die Softwareentwicklung, weil sie dann ggf. leichter zu handhaben ist als andere Paradigmen. Erfahrene und disziplinierte Entwickler können sicherlich auch rein prozeduralen oder funktionalen Sprachen genauso gute Programme schreiben.

Genau dies ist ein Brennpunkt bei der (durchaus emotionalen) Diskussion zwischen Anhängern und Kritikern des OO-Lagers. Hauptgrund für die Kritik ist oft, dass OO-Programme schnell dazu führen dass man sich in Klassen verzettelt wo ein einfaches Modul mit 10 Funktionen gereicht hätte. Für einfache Probleme muss man daher nicht immer zwingend eine "perfekte" OO Lösung erwarten.

Mit anderen Worten: Bloss weil OO eine vielzahl an herangehensweisen gibt, heisst es nicht dass man auch alle gleichzeitig einsetzen muss. Wann man welche Technik einsetzt wird einem oft erst durch Erfahrung bewusst. Ich denke da können schon ein paar Jahre ins Land gehen bis man sich wirklich sicher sein kann auf Anhieb eine geeignete OO-Lösung zu wählen.

Zu Beginn ist es wichtig - wie allgemein beim Programmieren - viel auszuprobieren, viel Feedback einholen, nicht entmutigen lassen, suboptimale Programme immer wieder und wieder verbessern. Also Kopf hoch und ab durch die Mitte. Für dich als FIAE 2. Lehrjahr würde ich sagen, dass neben den allgemeinen Grundlagen es nicht erforderlich ist OO komplett zu durchsteigen - da habe ich schon Dipl-Infs getroffen die das nicht konnten. Was für Dich speziell wichtig wäre will bzw. kann ich Dir nicht sagen, denn das ist bei jedem anders.

Allgemein kann man sagen: Arbeite an Deinen Schwächen und nutze Deine Stärken

[Gurki]

Danke für den tollen Beitrag! Habe kurz mit meinem Teamleiter gesprochen und der sagt auch man darf von einer Ausbildung nicht zu viel erwarten, es ist halt so, dass man da "nur" die Grundlagen erlernt... Vor allem aber brauch das Lernen furchtbar viel Zeit. Vielleicht habe ich da auch eine zu hohe Erwartungshaltung (?).

Ich schaue jetzt auch äußerst gern Informatik Vorlesungsvideos an ( Jörn Loviscach ). Ich finde die sehr interessant und vielleicht hilft es mir ja auch mit dem Lernen!