added dependency injection description
This commit is contained in:
parent
58abce35ff
commit
a14d68acab
|
@ -377,10 +377,16 @@ mode="advanced" label="Add document (.pdf .jpg .docx)">
|
||||||
\includegraphics[width=0.8\textwidth]{pics/dependency_inj_pat.jpg}
|
\includegraphics[width=0.8\textwidth]{pics/dependency_inj_pat.jpg}
|
||||||
\end{figure}
|
\end{figure}
|
||||||
\begin{itemize}
|
\begin{itemize}
|
||||||
\item Grundidee sind loose gekoppelte Objekte
|
\item ein Hauptgrund für Dependency Injection ist die Trennung zwischen Business- und Instanzierungslogik
|
||||||
\item Objekte werden mittels externem Assembler verknüpft
|
\item Klassen sollen nur noch Abhängigkeiten auf Interfaces haben
|
||||||
\item Abhängigkeiten bestehen nur auf Interfaces
|
\item die Verwendung des new Operators stattdessen würde eine Abhängigkeit zur Implementierungsklasse herstellen
|
||||||
\item Assembler Objekt (Framework) erzeugt die Interface-Implementierungen (z.B.: durch Factory)
|
\item Implementierungsklassen sollen auf Interfaces referenzieren, wobei es ihnen egal wie diese Referenz hergestellt wird
|
||||||
|
\item Die Instanziierung wird in die sogenannte Assembler Klasse "`herausgezogen"'
|
||||||
|
\item Objekte werden mittels des Assembler "`gebaut"'.
|
||||||
|
\item Zudem instanziiert er die Objekte und injected die Referenzen
|
||||||
|
\item So hat er Client nur mehr eine Abhängigkeit auf das Interface
|
||||||
|
\item wird die Implementierung getauscht, so geschieht das direkt im Assembler ohne den Client zu beeinflussen
|
||||||
|
\item der Container erledigt DI über @Inject indem er prüft welche Klasse das Interface implementiert und entsprechende Referenz bei der Annotation einhängt
|
||||||
\item Es wird zwischen Constructor Injection und Setter Injection unterschiedlichen
|
\item Es wird zwischen Constructor Injection und Setter Injection unterschiedlichen
|
||||||
\begin{minted}[linenos,breaklines=true]{java}
|
\begin{minted}[linenos,breaklines=true]{java}
|
||||||
// Constructor Injection
|
// Constructor Injection
|
||||||
|
@ -399,26 +405,12 @@ mode="advanced" label="Add document (.pdf .jpg .docx)">
|
||||||
}}
|
}}
|
||||||
\end{minted}
|
\end{minted}
|
||||||
\end{itemize}
|
\end{itemize}
|
||||||
\begin{itemize}
|
|
||||||
\item Im Spring Context:
|
|
||||||
\begin{itemize}
|
|
||||||
\item Dependency Injection mit XML-Datei
|
|
||||||
\item alle Beans sind dort gelistet und werden verknüpft
|
|
||||||
\item Context wird geladen damit alles verknüpft ist
|
|
||||||
\item erspart Factories
|
|
||||||
\end{itemize}
|
|
||||||
\end{itemize}
|
|
||||||
\subsection{Nenne die Konsequenzen der Anwendung}
|
\subsection{Nenne die Konsequenzen der Anwendung}
|
||||||
\begin{itemize}
|
\begin{itemize}
|
||||||
\item loose gekoppelte Objekte
|
\item loose gekoppelte Objekte
|
||||||
\item Referenzen nur noch auf Interfaces
|
\item Referenzen nur noch auf Interfaces
|
||||||
\item hohe Flexibilität (Strategy, Proxy,..)
|
\item hohe Flexibilität (Strategy, Proxy,..)
|
||||||
\item bessere Erweiterbarkeit und Testbarkeit
|
\item bessere Erweiterbarkeit und Testbarkeit
|
||||||
\item bei Spring kann Dependency Injection mittels XML oder Annotation erfolgen
|
|
||||||
\begin{itemize}
|
|
||||||
\item Vorteil Annotation: Typ-Sicherheit (Tippfehler passieren schnell im XML)
|
|
||||||
\item Nachteil Annotation: nicht so flexibel wie XML
|
|
||||||
\end{itemize}
|
|
||||||
\end{itemize}
|
\end{itemize}
|
||||||
\section{Data Transfer Object (DTO) Pattern}
|
\section{Data Transfer Object (DTO) Pattern}
|
||||||
\subsection{Erkläre die Funktion (Skizze - ein Grund für DTO)}
|
\subsection{Erkläre die Funktion (Skizze - ein Grund für DTO)}
|
||||||
|
|
Loading…
Reference in New Issue