' schrieb:Das wird ja nur aus Anschauungsgründen gemacht. Das Klassenmodell lässt sich an einem realen Objekt einfacher erklären - weil der Schüler mit einer realen Uhr leichter denken kann als mit einem virtuellen Konstrukt.
Eben, genau das ist der Punkt, warum ich OOP anwende und andere davon überzeugen möchte. Man handelt mit OOP-Objekten im Programm genauso wie mit realen Objekten im Leben.
<!--quoteo(post=95148:date=09.04.2010 , 08:55:46:name=<<oenk>>)--><div class='quotetop'>ZITAT(<<oenk>> @ 09.04.2010 , 08:55:46) [url=index.php?act=findpost&pid=95148][/url]</div><div class='quotemain'><!--quotec-->Diese beide Methoden könntest du (ob es sinnvoll ist steht auf einem anderen Blatt) in jeweils eine Methode deiner Klasse packen. Schreibst du jetzt ein filehandler für Kunde A kannst du die beiden Methoden für Kunde A vererben und musst nur noch das formatieren neu implentieren.[/quote]
man könnte aber auch einfach ein VI schreiben, das die von dir beschriebene Funktion bereitstellt und in die User-LIB packen ... ich seh keinen Grund warum man so eine Funktion für jedes Projekt neu in einer Methode implementieren sollte ...
' schrieb:Eben, genau das ist der Punkt, warum ich OOP anwende und andere davon überzeugen möchte. Man handelt mit OOP-Objekten im Programm genauso wie mit realen Objekten im Leben.
joh ... und was ist der Vorteil davon? Jetz mal ausser dass dir LVOOP gefällt und du Spass dran hast?
(was ich für einen Sinn in OOP sehe hab ich ja schon in nem anderen Thread ausgeführt ... nicht dass das jetzt wieder heist, ich wär da penetrant dagegen
)
' schrieb:Man handelt mit OOP-Objekten im Programm genauso wie mit realen Objekten im Leben.
Wie ist das denn beim realen Objekt "Lebenspartner".
Mache ich das nun OOP oder wie er (der Faden) läuft.
Zeit fürs Wochenende.....
' schrieb:man könnte aber auch einfach ein VI schreiben, das die von dir beschriebene Funktion bereitstellt und in die User-LIB packen ... ich seh keinen Grund warum man so eine Funktion für jedes Projekt neu in einer Methode implementieren sollte ...
Wie geschrieben, ob es sinnvoll ist steht auf einem anderen Blatt. Ich hab mich da nur auf dieses konkrete Beispiel bezogen.
Diese Methode würde ich auch nicht in eine OOP-Klasse packen. Teiber jedoch schon. Auch Treiber könnte ich in einem VI kapseln und nur dieses im Programm implementieren. Und für jedes neue Gerät einen neuen TypeDef. State ablegen. Nichts anderes (mehr oder weniger) macht eine OOP-Klasse. Nur steht mir da die Vererbung, Zugriffsrechte, etc (muss ich ja nicht erwähnen, das OOP-Konzept ist dir ja bekannt) zur Verfügung.
Ob OOP oder nicht OOP bleibt jedem selbst überlassen. Es ist nicht für alles sinnvoll, für einiges jedoch schon
und wie RoLe sagte:
Zeit für's Wochenende...
Christian