Electronic Attack - Forum für elektronische Musikproduktion

Electronic Attack - Forum für elektronische Musikproduktion (https://www.electronicattack.de/forum.php)
-   DIY (https://www.electronicattack.de/forumdisplay.php?f=84)
-   -   object.FOP() != OOP (https://www.electronicattack.de/showthread.php?t=45944)

Psychotronic 08-02-2010 23:32

object.FOP() != OOP
 
Sammlung - Verständnisbrücken

Einleitung:

1. Jemand der es das erste mal liest, hat keine Ahnung was er da liest und wird es ohne das notwendige Hintergrundwissen keinesfalls verstehen können, da hilft weder Studium noch Ausbildung. Man braucht Talent oder Erfahrung oder beides ansonsten hat man einfach keine Chance. Wobei sich Talent aus einem kleinen Prozentsatz Eingebung und einer riesen Masse an sturem Willen definiert. Das war eigentlich abzusehen, also bleib cool.

2. Ich weiss das ich nichts weiss und damit weiss ich mehr als die die nicht wissen das sie nichts wissen, also immer ruhig blut gevatter... auch wenn es zeitlich kritisch ist

3. Die meinen das Ernst und das heisst das du absolut keine Ahnung hast und damit ein D.A.I. bist!!!


Hintergrund:

http://typicalprogrammer.com/?p=23 (vor allem kommentare)
http://peripateticaxiom.blogspot.com...nd-design.html
http://www.javaworld.com/javaworld/j...5-toolbox.html


Annahme:

OO wird von dir in den meisten Fällen dazu genutzt um FOP in O und M zu kapseln, was faktisch genau gar keinen Sinn macht. In Hinblick auf das GOF Buch ist ist anzunehmen das du einer der Trottel bist die das Konzept nie vollständig verstanden haben.

Ein Programm lässt sich vollständig mit GOF Patterns beschreiben. Wenn man diese generisch zusammensetzt und die Implemenationen einen Mehrwert bieten entsteht ein neues Pattern.

Alle diesen Prinzipien widersprechenden Patterns sind Anti-Patterns einer OO.

Cyberdroid 08-02-2010 23:36

AW: object.FOP() != OOP
 
Dein Fachchinesisch wird immer besser! :thumbsup: :lengleng:

Psychotronic 08-02-2010 23:39

AW: object.FOP() != OOP
 
ney... ich versuche mir gerade nur zwanghaft zu beweisen das ich keine ahnung habe, damit ich dann aus verzweiflung heraus alles vergesse und mir neu anlernen kann...

einfach ignorieren... oder bei interesse den obigen links und diesem hier folgen:

http://de.wikipedia.org/wiki/Viererb...entwicklung%29

Psychotronic 08-02-2010 23:40

AW: object.FOP() != OOP
 
so wie bruce lee mit seinem wasserglass... be water my friend. ;)

Psychotronic 09-02-2010 00:25

AW: object.FOP() != OOP
 
Regelwerke:

1. Setter für Interfaces dessen Implementationen IoC folgen. Zusammensetzen via Dependency Injection. :yes:
2. "Tell, don't ask!" beachten wo es geht. :yes: :yes:
3. Bean get/set wo es geht vermeiden... aber nicht überbewerten. :no: :yes:
4. Bei get/set verwendung bei Beans möglicherweise Facaden oder Dektoratoren implementieren, um sie über mehrere Domainen transaktional und ungekoppelt zu halten. :yes: :yes: :yes:

Psychotronic 09-02-2010 02:23

AW: object.FOP() != OOP
 
Account.appendTransactionTo(TransactionReceiver)

good point.

Psychotronic 09-02-2010 03:03

AW: object.FOP() != OOP
 
http://peripateticaxiom.blogspot.com...nd-design.html

http://martinfowler.com/bliki/GetterEradicator.html

Psychotronic 09-02-2010 06:03

AW: object.FOP() != OOP
 
http://pastebin.com/f538134e7

Psychotronic 09-03-2010 01:50

AW: object.FOP() != OOP
 
scheisse. compile time reflection... wieso bin ich da nicht schon früher drauf gekommen... holy moly! GWT-DI Framework! hammer krasse idee!

:rok:

das lernen lohnt sich!

Cyberdroid 09-03-2010 01:59

AW: object.FOP() != OOP
 
Ich mag diesen Thread nicht :squint:







Hier komme ich mir so dumm vor! :cry:

Psychotronic 09-03-2010 03:03

AW: object.FOP() != OOP
 
ach jung... ich schreib hier in abkürzungen, also nochmal für dich langsam und lesbar:

DI = Dependency Injection
Das heisst man hängt Objekte zur Laufzeit durch ein Framework ineinander, ohne das die sich vom Typ her gegenseitig kennen. Man entkoppelt die Objekte sozusagen von einander. Der Bauplan wie zusammengesetzt wird, ist normalerweise in XML definiert.

Beispiel:
Das Objekt Auto kennt Objekte vom Typ Rad, es kennt aber nicht Objekte vom Typ ContinentalSpezialGeilesRennRad
Das Dependency Injection Framework ist dann sozusagen die Werkstatt die beim Programmstart 4 ContinentalSpezialGeilesRennRad Objekte an das Objekt Auto schraubt. Auto kennt aber nur die Schnittstelle Rad und kann diese benutzen


Vorteile:
- man kann Programme zusammenkonfigurieren
- man kann Programmanteile austauschen ohne den Programmcode zu ändern
- die komplette Objekt Erzeugung für die großen Strukturen des Programms ist rausgeworfen
- man schreibt wesentlich schlankere Objekt orientiertere Programme(angenehmer Nebeneffekt)
- du hast nen Bauplan des Programms in xml dokumentiert. Wenn man gucken will wie das Programm aufgebaut ist, liest man einfach das xml


Problem:
Sowas geht nicht mit Javascript, bzw. nur über böse dynamische Sprachefeatures. Das ist ein NO - GO. Das macht den Code zum Schluss unwartbar.


Javascript in Cool = GWT
Ich für meinen Teil programmier kein javascript mehr direkt, weil die Sprache suckt! Ich programmier javascript in Java und lasse ein Compiler das Formschöne, wunderbar wartbare schlanke Programm in komprimiertes hässliches Javascript übersetzen. Das Framework dafür heisst GWT - Google Web Toolkit. Das ist das erste Framework mit dem man wirklich reine komplett asyncrone laufende Ajax Programme schreiben kann, ohne sich dabei wegen javascript einen abzubrechen. Es gibt dort auch kein HTML in dem Sinne mehr. Man setzt dort die komplette Seite via Javascript zusammen und hat volle Runtime Kontrolle. Das hat zur Folge das eine html Seite ein ganzes Programm enthält. Man muss keine weitere Seite laden wenn man was Anderes anzeigen will. Man räumt einfach kurz das <div> auf wo der inhalt rein soll und rendert ihn dann dynamisch rein.

Man programmiert also Java Programme(ähnlich wie AWT/Swing) und styled die mit CSS. Den Rest macht GWT, incl. Browserspezifischer Anpassungen.


Und wieder unser Problem:
Es gibt keine Reflection API in GWT(die gibts sogar in php god dammit :mad: ). Mit Reflection kann man dynamisch Objekte zerlegen und wieder zusammensetzen, genau das braucht man um Dependency Injection zu realisieren.


Lösung:
Und just in diesem Moment ist mir eingefallen wie ich das umgehen kann. -> GWT hat Sourcecode Generatoren die man zur Compile-Time reinhängen kann. Der wird dann das Bauplan XML lesen und mir das Programm zusammensetzen.


Warum will ich da was zusammensetzen?

Ich teile meinen GUI Code in 4 Bestandteile:

1. Composite (View oder auch GUI) -> dort ist nur GUI code enthalten. Wenn dort ein Button auf nem Formular was machen soll bekommt der via DI nen Eventhandler gesetzt. Der Handler ist generisch und steuert ein CompositeCommand an

2. CompositeCommand ( Presenter ) -> dort ist der reine Funktionscode enthalten, so ala mache was mit der dir zur geordneten Composite

3. Model -> Das sind Klassen die im grunde Daten cachen und Serverschnittstellen(servlets, php scripte, etc) anbinden

4. CompositeScript -> Das ist ne Art Macro mit dem man innerhalb der Anwendung über ne zentrale Registry Composites und Commandos fernsteuert. Dort sagts du zum Beispiel: TwitterWidget.init() oder TwitterWidget.renderIntoPage()

Mit den bestandteilen kannste in ner bleeding edge javascript only Applikation alles machen und es bleibt auf dauer wartbar.




So... und den Satz da oben hab ich nur geschrieben um mir bis morgen Abend zu merken das man DI via compile time reflection mit GWT generatoren macht. Glaubst du ich schreib jedesmal Aufsätze für nen fuckin reminder? :madjerk:

Cyberdroid 09-03-2010 11:10

AW: object.FOP() != OOP
 
Zitat:

Zitat von Psychotronic (Beitrag 350181)
Glaubst du ich schreib jedesmal Aufsätze für nen fuckin reminder? :madjerk:

Ich glaube, du wolltest deine Gedanken nur mal zu Papier bringen. Zu virtuellem Papier. :dunno:


Aber das mit dem Auto hab ich verstanden. Dummerweise hast du mir jetzt Lust gemacht auf Hochgeschwindigkeitsräder von Continental auf 17-Zoll-Alufelgen. Dabei kann ich mir die garnicht leisten. Aber Ostern werde ich zumindest meine Sommerreifen wieder draufziehen. Winterreifen sidn eben nicht das gelbe vom Ei. Im Moment vibrtiert meine ganze Karre ab 80 kmh, weil in den Felgen Eis drinsteckt. Aber das hat ja nichts mit den Reifen zu tun. Und erst rechts nichts mit dir :dunno:

Psychotronic 09-03-2010 23:09

AW: object.FOP() != OOP
 
:wtf:

Psychotronic 23-02-2011 00:25

AW: object.FOP() != OOP
 
Zitat:

Zitat von Psychotronic (Beitrag 346108)
Regelwerke:

3. Bean get/set wo es geht vermeiden... aber nicht überbewerten. :no: :yes:

korrektur: stirb getter stirb!

set nur für DI

Cyberdroid 23-02-2011 00:30

AW: object.FOP() != OOP
 
:corn:

Psychotronic 23-02-2011 00:33

AW: object.FOP() != OOP
 
Zitat:

Zitat von Psychotronic (Beitrag 350181)
Problem:
Sowas geht nicht mit Javascript, bzw. nur über böse dynamische Sprachefeatures. Das ist ein NO - GO. Das macht den Code zum Schluss unwartbar.

noch ne korrektur:

in javascript programmiert man sich via DSL seine eigene direkte sprachsyntax zusammen und zwar je anwendungsfall. das macht die programme so kurz das sie wieder wartbar werden.

es bleibt spannend.

x2mirko 23-02-2011 00:57

AW: object.FOP() != OOP
 
das hört sich verdächtig nach ner Vorlesung ausm letzten semester an. :look:

Psychotronic 23-02-2011 01:09

AW: object.FOP() != OOP
 
Zitat:

Zitat von x2mirko (Beitrag 390655)
das hört sich verdächtig nach ner Vorlesung ausm letzten semester an. :look:

auch spannend. ich hoffe du hast sie verstanden. :naughty:


Alle Zeitangaben in WEZ +2. Es ist jetzt 15:29 Uhr.

Powered by vBulletin® Version 3.7.1 (Deutsch)
Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.
Copyright ©2002 - 2017 redefining media
Background-Graphics by Nik Ainley, ShinyBinary
Impressum | Datenschutz