====== Design Patterns ======
A collection of unusual Design Patterns. 


===== Eclipse RPC4 =====

=== Objects crete themselves ===
Make UI Elements create themselves and integrate into the Application, as soon as they are created. \\
This is some kind of weird, becuase of the inversion of control: not the toolbar adds the buttons, but buttons add themselves to the toolbar.

^Pro^Contra^
|All the logic is encapsulated at one place. | The creation order of buttons can not be explicitely specified. |
|Dynamic changes. Just inject another Toolbar and the Widgets will add themselves to another place.| ? |


**Example**: 
Toolbar Buttons are created and injected into the Context. 
They retrieve the toolbar on their own and add themselves to the toolbar. 
To communicate with the applicaiton EventBroker is used.

<sxh java>
// ... Inject the only Toolbar somewhere into the context.

public class ToolbarItemDelObject {

    @Inject
    private TableToolbar tableToolbar;
    
    @Inject
    private EventBorker eventBorker;

    @PostConstruct
    void create() {
        // use injected ToolBar.
        createItem(tableToolbar.getleftPart());
    }

    private void createItem(ToolBar parent) {
        // create here
    }
}

</sxh>
===== GUI =====


==== LifeCycle Workaround ====
**Problem:**
How to work around the lifecycle dependencies?
What to do if you have GUI COmponents which need to know each to initiate themselves?

<code>
Example: 
Table A's header depends on another table B's header. 
Table B controls the functionality of Table A, initiates it's display mode.
</code>

**Pattern:**
Introduce an own lifecycle.
  - Step1: Create all the GUI components
  - Step2: Walk over all registered components. Inject other components into the current component.


===Model View Whatever===
https://www.beyondjava.net/blog/model-view-whatever/

{{https://s3.eu-central-1.amazonaws.com/alf-digital-wiki-pics/sharex/HTEJfptXmc.png}}
==== Model View Presenter (MVP) ====
Ansatz um das Modell (engl. model) und die Ansicht (engl. view) komplett voneinander zu trennen und über einen Präsentator (engl. presenter) zu verbinden.

http://de.wikipedia.org/wiki/Model_View_Presenter

**Wer ist für die Synchronisation zuständig?**

== Die View selbst - "Supervising Controller" ==

Supervising Controller (wörtlich etwa „Überwachende Steuerung“) ist ein Entwurfsmuster, das aus der ursprünglichen Variante von MVP hervorgegangen ist und von Martin Fowler definiert wurde. Hierbei übernimmt die Ansicht möglichst alle Aufgaben zur Datensynchronisation, während sich der Präsentator um alle anderen Abläufe zwischen Modell und Ansicht kümmert. Um die Synchronisation möglichst zu vereinfachen, kann auf Datenbindungen (engl. data bindings) zurückgegriffen werden. Dabei stellt der Präsentator Daten über Klassen bereit, die der Ansicht und dem Modell bekannt sind. Der Präsentator selbst sorgt nur noch für die Übertragung der Datenobjekte vom Modell zur Ansicht. Hierdurch entfällt weiterer Synchronisationsaufwand vom Präsentator, da sich die Ansicht selbstständig über die Datenobjekte synchronisiert. Das Modell kann seinerseits ebenfalls über die Datenobjekte auf innerhalb der Ansicht veränderte Daten zugreifen.

http://martinfowler.com/eaaDev/SupervisingPresenter.html

== Der Presenter - "Passive View" ==

Passive View (wörtlich etwa „Untätige Ansicht“) ist ein Entwurfsmuster, das aus der ursprünglichen Variante von MVP hervorgegangen ist und von Martin Fowler definiert wurde. Im Gegensatz zum Supervising Controller existiert keine Verbindung über ein Datenobjekt zwischen Modell und Ansicht. Dies trägt dazu bei, dass der Präsentator jegliche Datensynchronisation zwischen Modell und Ansicht selbst durchführen muss. Das Ergebnis dabei ist, dass die Ansicht nur einfachste Logik zur Anzeige beinhaltet und keine Logik zur Synchronisation von Daten. Dadurch wird der Quelltext der Ansicht äußerst vereinfacht, anders als dies beim Supervising Controller der Fall ist.

http://martinfowler.com/eaaDev/PassiveScreen.html
==== Model View ViewModel(MVVM) ====
http://de.wikipedia.org/wiki/Model_View_ViewModel


==== GUI und BroadCasts ====
Die BroadCasts eignen sich sehr gut, um innerhalb der Application zwischen Komponenten zu kommunizieren.
Es eigent sich sehr gut um auf Nutzer Aktionen zu reagieren!

Alle potentiellen EMpfänger müssen aber bereits geladen worden sein!
Deswegen eigent sich ein Brodcast schlecht für automatische Tastk, die eventuell schon beim Laden gestartet werden. \\
In diesem Fall Besser: ein Modell / State erstellen das von überall erreichbar ist. Die GUI reagiert auf Modell / State Änderungen, meldet sich selbstständig an / ab.
**(siehe MVP)**

== Gut==
  * Nutzer drückt Button "Speichern"
  * Button "Speichern" triggert ein Broadcast. 
  * BroadcastReceiver reagiert auf den Broacast.

== Schlecht ==
  * Beim Laden wird ein Task gestartet, der eine automatische Prüfung asynchron ausführt.
  * Die Prüfung ist zuende, das Ergebnis wird per Broadcast verteilt.
  * **Ein potentieller Empfänger wurde noch nicht geladen und empfängt den Broadcast nicht!**


==== Services ====
Strategie für die richtige Architektur der Services. Wie geht man das an?
	- Was will man am Ausgang bekommen? 
	- Welche Daten braucht man dafür? Wann braucht man diese Daten?
	- Was muss man übergeben?
	- Wohin soll der Service gelegt werden, damit alle die es brauchen den Service finden können?