Asynchronous module definition - Versionsgeschichte

Trustable: catfix

2025-05-11T17:27:42Z

catfix

← Nächstältere Version		Version vom 11. Mai 2025, 19:27 Uhr
Zeile 40:		Zeile 40:
	<references />		<references />

	[[Kategorie:~~ECMAScript~~]]		[[Kategorie:JavaScript]]
	[[Kategorie:Programmierschnittstelle]]		[[Kategorie:Programmierschnittstelle]]

DerMaxdorfer: Wikilink Latenzzeit korrigiert; weitere Wikilinks aktualisiert

2023-11-26T16:52:17Z

Wikilink Latenzzeit korrigiert; weitere Wikilinks aktualisiert

← Nächstältere Version		Version vom 26. November 2023, 18:52 Uhr
Zeile 1:		Zeile 1:
	'''Asynchronous module definition''' ('''AMD''') ist eine [[JavaScript]]-[[Programmierschnittstelle]], mit deren Hilfe [[Modul (Software)\|Module]] und ihre Abhängigkeiten asynchron geladen werden können. Es bildet dadurch zwei grundlegende Konzepte der Software-Entwicklung, Modularisierung und Wiederverwendung, in der ansonsten [[Funktionale Programmierung\|funktional]] und [[Monolith#Weitere Verwendungen der Ausdrücke Monolith und monolithisch\|monolithisch]] aufgebauten JavaScript-Umgebung ab. Die Modularisierung erlaubt die Aufteilung einer Javascript-Anwendung in einzelne Teilkomponenten, welche separat entwickelt und getestet werden können ([[Teile und herrsche ~~(Informatik)\|Teile und Herrsche~~]]). Aufgrund von klaren Schnittstellen können AMD-Module in anderen Softwareprojekten wiederverwendet werden.		'''Asynchronous module definition''' ('''AMD''') ist eine [[JavaScript]]-[[Programmierschnittstelle]], mit deren Hilfe [[Modul (Software)\|Module]] und ihre Abhängigkeiten asynchron geladen werden können. Es bildet dadurch zwei grundlegende Konzepte der Software-Entwicklung, Modularisierung und Wiederverwendung, in der ansonsten [[Funktionale Programmierung\|funktional]] und [[Monolith#Weitere Verwendungen der Ausdrücke Monolith und monolithisch\|monolithisch]] aufgebauten JavaScript-Umgebung ab. Die Modularisierung erlaubt die Aufteilung einer Javascript-Anwendung in einzelne Teilkomponenten, welche separat entwickelt und getestet werden können ([[Teile-und-herrsche-Verfahren]]). Aufgrund von klaren Schnittstellen können AMD-Module in anderen Softwareprojekten wiederverwendet werden.

	Die Vorgehensweise basiert weitestgehend auf dem [[Inversion of Control\|Inversion-of-Control]]-[[Entwurfsmuster]] (IoC Pattern). Das Modul entspricht dabei dem Begriff der Bean in IoC.<ref>{{Webarchiv\|url=https://docs.jboss.org/author/display/GTNPORTAL34/GDG-Asynchronous+Module+Definition \|wayback=20160304121006 \|text=Archivierte Kopie \|archiv-bot=2022-10-05 21:59:22 InternetArchiveBot }}</ref> Dadurch wird es ermöglicht, dass auch JavaScript modular aufgebaut werden kann. Das Resultat sind Module, die vergleichbar mit [[Java (Programmiersprache)\|Java]]-[[Klasse (~~Programmierung~~)\|Klassen]] sind, und auch genauso durch Vererbung erweitert werden können.<ref>{{Webarchiv\|url=http://docs.weejot.com/developer/reference/amd.html \|wayback=20130718212018 \|text=Archivierte Kopie \|archiv-bot=2023-03-10 05:21:49 InternetArchiveBot }}</ref> Jedes Modul muss dabei – analog zur Java-Klasse – in einer eigenen [[Datei]] gespeichert sein.		Die Vorgehensweise basiert weitestgehend auf dem [[Inversion of Control\|Inversion-of-Control]]-[[Entwurfsmuster]] (IoC Pattern). Das Modul entspricht dabei dem Begriff der Bean in IoC.<ref>{{Webarchiv\|url=https://docs.jboss.org/author/display/GTNPORTAL34/GDG-Asynchronous+Module+Definition \|wayback=20160304121006 \|text=Archivierte Kopie \|archiv-bot=2022-10-05 21:59:22 InternetArchiveBot }}</ref> Dadurch wird es ermöglicht, dass auch JavaScript modular aufgebaut werden kann. Das Resultat sind Module, die vergleichbar mit [[Java (Programmiersprache)\|Java]]-[[Klasse (Objektorientierung)\|Klassen]] sind, und auch genauso durch Vererbung erweitert werden können.<ref>{{Webarchiv\|url=http://docs.weejot.com/developer/reference/amd.html \|wayback=20130718212018 \|text=Archivierte Kopie \|archiv-bot=2023-03-10 05:21:49 InternetArchiveBot }}</ref> Jedes Modul muss dabei – analog zur Java-Klasse – in einer eigenen [[Datei]] gespeichert sein.

	Vorteile der Modularisierung bestehen besonders im [[Webbrowser\|Browser]]-Umfeld, wo JavaScript besonders häufig genutzt wird. Es werden nur die benötigten Module geladen, nicht jedoch alles, wie es beim synchronen Laden der Fall wäre. Das erhöht einerseits die Performanz des Codes und erleichtert andererseits das [[Debugger\|Debuggen]], insbesondere bei Cross-Domain-Zugriffsproblemen.<ref>https://github.com/amdjs/amdjs-api/wiki/AMD</ref> Weiterhin ermöglicht es eine bessere Wiederverwendbarkeit einzelner Codefragmente, ohne diese per Kopieren und Einfügen oder serverseitige Verkettung (''server side concatenation'') transportieren zu müssen. Daraus ergibt sich eine Verringerung der Nutzung [[Variable (Programmierung)#Variablen in einer Blockstruktur\|globaler Variablen]] auf ein Minimum und reduziert so die durch Namespace Pollution entstehenden Probleme signifikant.		Vorteile der Modularisierung bestehen besonders im [[Webbrowser\|Browser]]-Umfeld, wo JavaScript besonders häufig genutzt wird. Es werden nur die benötigten Module geladen, nicht jedoch alles, wie es beim synchronen Laden der Fall wäre. Das erhöht einerseits die Performanz des Codes und erleichtert andererseits das [[Debugger\|Debuggen]], insbesondere bei Cross-Domain-Zugriffsproblemen.<ref>https://github.com/amdjs/amdjs-api/wiki/AMD</ref> Weiterhin ermöglicht es eine bessere Wiederverwendbarkeit einzelner Codefragmente, ohne diese per Kopieren und Einfügen oder serverseitige Verkettung (''server side concatenation'') transportieren zu müssen. Daraus ergibt sich eine Verringerung der Nutzung [[Variable (Programmierung)#Variablen in einer Blockstruktur\|globaler Variablen]] auf ein Minimum und reduziert so die durch Namespace Pollution entstehenden Probleme signifikant.

	Durch die Vorgabe der Verteilung des Codes auf viele einzelne Dateien ergeben sich jedoch auch Nachteile. Jede Datei muss vom Browser in einem separaten [[Hypertext Transfer Protocol\|HTTP]]-Aufruf geladen werden, was bei vielen kleinen Dateien sehr viel [[Kommunikationsprotokoll\|Protokoll]]-[[Overhead (EDV)\|Overhead]] erzeugen kann. Dadurch kann insbesondere bei Verbindungen mit hoher [[~~Verzögerungszeit~~\|Latenzzeit]] eine Verzögerung bemerkbar werden.<ref>https://tomdale.net/2012/01/amd-is-not-the-answer/</ref>		Durch die Vorgabe der Verteilung des Codes auf viele einzelne Dateien ergeben sich jedoch auch Nachteile. Jede Datei muss vom Browser in einem separaten [[Hypertext Transfer Protocol\|HTTP]]-Aufruf geladen werden, was bei vielen kleinen Dateien sehr viel [[Kommunikationsprotokoll\|Protokoll]]-[[Overhead (EDV)\|Overhead]] erzeugen kann. Dadurch kann insbesondere bei Verbindungen mit hoher [[Verzögerung (Telekommunikation)\|Latenzzeit]] eine Verzögerung bemerkbar werden.<ref>https://tomdale.net/2012/01/amd-is-not-the-answer/</ref> Dieser Overhead beim Abruf von verschiedenen Javascript-Dateien kann allerdings durch die Verwendung eines serverseitigen Bundlings kompensiert werden.<ref>https://requirejs.org/docs/api.html</ref>
	Dieser Overhead beim Abruf von verschiedenen Javascript-Dateien kann allerdings durch die Verwendung eines serverseitigen Bundlings kompensiert werden.<ref>https://requirejs.org/docs/api.html</ref>

	Zur Umsetzung des AMD-Formats existieren verschiedene AMD-Frameworks wie z. B. [[RequireJS]], [[Dojo Toolkit\|The Dojo Loader]] oder [[curl.js]].		Zur Umsetzung des AMD-Formats existieren verschiedene AMD-Frameworks wie zum Beispiel [[RequireJS]], [[Dojo Toolkit\|The Dojo Loader]] oder [[curl.js]].

	== Einsatz ==		== Einsatz ==

	Das AMD-Format sieht eine spezielle Moduldefinition bzw. Komponentendefinition vor, welche die Deklaration und das korrekte Laden von Abhängigkeiten ermöglicht. Die Moduldefinition erfolgt somit auf der Basis von Programmierkonventionen. Diese Konvention hat sich bei vielen frei verfügbaren Javascript-Bibliotheken, wie ~~z. B.~~ [[jQuery]] oder [[Socket.IO]], durchgesetzt.		Das AMD-Format sieht eine spezielle Moduldefinition bzw. Komponentendefinition vor, welche die Deklaration und das korrekte Laden von Abhängigkeiten ermöglicht. Die Moduldefinition erfolgt somit auf der Basis von Programmierkonventionen. Diese Konvention hat sich bei vielen frei verfügbaren Javascript-Bibliotheken, wie zum Beispiel [[jQuery]] oder [[Socket.IO]], durchgesetzt.
	<syntaxhighlight lang="javascript">		<syntaxhighlight lang="javascript">
	define("Name des Moduls", ["Abhängigkeit1", "Abhängigkeit2"], factory);		define("Name des Moduls", ["Abhängigkeit1", "Abhängigkeit2"], factory);

Aka: https, Links normiert, Kleinkram

2023-03-12T12:21:01Z

https, Links normiert, Kleinkram

InternetArchiveBot: InternetArchiveBot hat 1 Archivlink(s) ergänzt und 0 Link(s) als defekt/tot markiert.) #IABot (v2.0.9.3

2023-03-10T05:21:49Z

InternetArchiveBot hat 1 Archivlink(s) ergänzt und 0 Link(s) als defekt/tot markiert.) #IABot (v2.0.9.3

← Nächstältere Version		Version vom 10. März 2023, 07:21 Uhr
Zeile 1:		Zeile 1:
	'''Asynchronous module definition''' ('''AMD''') ist eine [[JavaScript]]-[[Programmierschnittstelle]], mit deren Hilfe [[Modul (Software)\|Module]] und ihre Abhängigkeiten asynchron geladen werden können. Es bildet dadurch zwei grundlegende Konzepte der Software-Entwicklung, Modularisierung und Wiederverwendung, in der ansonsten [[Funktionale Programmierung\|funktional]] und [[Monolith#Weitere_Verwendungen_der_Ausdrücke_Monolith_und_monolithisch\|monolithisch]] aufgebauten JavaScript-Umgebung ab. Die Modularisierung erlaubt die Aufteilung einer Javascript-Anwendung in einzelne Teilkomponenten, welche separat entwickelt und getestet werden können ([[Teile_und_herrsche_(Informatik)\|Teile und Herrsche]]). Aufgrund von klaren Schnittstellen können AMD-Module in anderen Softwareprojekten wiederverwendet werden.		'''Asynchronous module definition''' ('''AMD''') ist eine [[JavaScript]]-[[Programmierschnittstelle]], mit deren Hilfe [[Modul (Software)\|Module]] und ihre Abhängigkeiten asynchron geladen werden können. Es bildet dadurch zwei grundlegende Konzepte der Software-Entwicklung, Modularisierung und Wiederverwendung, in der ansonsten [[Funktionale Programmierung\|funktional]] und [[Monolith#Weitere_Verwendungen_der_Ausdrücke_Monolith_und_monolithisch\|monolithisch]] aufgebauten JavaScript-Umgebung ab. Die Modularisierung erlaubt die Aufteilung einer Javascript-Anwendung in einzelne Teilkomponenten, welche separat entwickelt und getestet werden können ([[Teile_und_herrsche_(Informatik)\|Teile und Herrsche]]). Aufgrund von klaren Schnittstellen können AMD-Module in anderen Softwareprojekten wiederverwendet werden.

	Die Vorgehensweise basiert weitestgehend auf dem [[Inversion of Control\|Inversion-of-Control]]-[[Entwurfsmuster]] (IoC Pattern). Das Modul entspricht dabei dem Begriff der Bean in IoC.<ref>{{Webarchiv\|url=https://docs.jboss.org/author/display/GTNPORTAL34/GDG-Asynchronous+Module+Definition \|wayback=20160304121006 \|text=Archivierte Kopie \|archiv-bot=2022-10-05 21:59:22 InternetArchiveBot }}</ref> Dadurch wird es ermöglicht, dass auch JavaScript modular aufgebaut werden kann. Das Resultat sind Module, die vergleichbar mit [[Java (Programmiersprache)\|Java]]-[[Klasse_(Programmierung)\|Klassen]] sind, und auch genauso durch Vererbung erweitert werden können.<ref>http://docs.weejot.com/developer/reference/amd.html</ref> Jedes Modul muss dabei – analog zur Java-Klasse – in einer eigenen [[Datei]] gespeichert sein.		Die Vorgehensweise basiert weitestgehend auf dem [[Inversion of Control\|Inversion-of-Control]]-[[Entwurfsmuster]] (IoC Pattern). Das Modul entspricht dabei dem Begriff der Bean in IoC.<ref>{{Webarchiv\|url=https://docs.jboss.org/author/display/GTNPORTAL34/GDG-Asynchronous+Module+Definition \|wayback=20160304121006 \|text=Archivierte Kopie \|archiv-bot=2022-10-05 21:59:22 InternetArchiveBot }}</ref> Dadurch wird es ermöglicht, dass auch JavaScript modular aufgebaut werden kann. Das Resultat sind Module, die vergleichbar mit [[Java (Programmiersprache)\|Java]]-[[Klasse_(Programmierung)\|Klassen]] sind, und auch genauso durch Vererbung erweitert werden können.<ref>{{Webarchiv\|url=http://docs.weejot.com/developer/reference/amd.html \|wayback=20130718212018 \|text=Archivierte Kopie \|archiv-bot=2023-03-10 05:21:49 InternetArchiveBot }}</ref> Jedes Modul muss dabei – analog zur Java-Klasse – in einer eigenen [[Datei]] gespeichert sein.

	Vorteile der Modularisierung bestehen besonders im [[Webbrowser\|Browser]]-Umfeld, wo JavaScript besonders häufig genutzt wird. Es werden nur die benötigten Module geladen, nicht jedoch alles, wie es beim synchronen Laden der Fall wäre. Das erhöht einerseits die Performanz des Codes und erleichtert andererseits das [[Debugger\|Debuggen]], insbesondere bei Cross-Domain-Zugriffsproblemen.<ref>https://github.com/amdjs/amdjs-api/wiki/AMD</ref> Weiterhin ermöglicht es eine bessere Wiederverwendbarkeit einzelner Codefragmente, ohne diese per Kopieren und Einfügen oder serverseitige Verkettung (''server side concatenation'') transportieren zu müssen. Daraus ergibt sich eine Verringerung der Nutzung [[Variable (Programmierung)#Variablen in einer Blockstruktur\|globaler Variablen]] auf ein Minimum und reduziert so die durch Namespace Pollution entstehenden Probleme signifikant.		Vorteile der Modularisierung bestehen besonders im [[Webbrowser\|Browser]]-Umfeld, wo JavaScript besonders häufig genutzt wird. Es werden nur die benötigten Module geladen, nicht jedoch alles, wie es beim synchronen Laden der Fall wäre. Das erhöht einerseits die Performanz des Codes und erleichtert andererseits das [[Debugger\|Debuggen]], insbesondere bei Cross-Domain-Zugriffsproblemen.<ref>https://github.com/amdjs/amdjs-api/wiki/AMD</ref> Weiterhin ermöglicht es eine bessere Wiederverwendbarkeit einzelner Codefragmente, ohne diese per Kopieren und Einfügen oder serverseitige Verkettung (''server side concatenation'') transportieren zu müssen. Daraus ergibt sich eine Verringerung der Nutzung [[Variable (Programmierung)#Variablen in einer Blockstruktur\|globaler Variablen]] auf ein Minimum und reduziert so die durch Namespace Pollution entstehenden Probleme signifikant.

At40mha: Abschnittlink korrigiert

2022-11-06T14:06:59Z

Abschnittlink korrigiert

← Nächstältere Version		Version vom 6. November 2022, 16:06 Uhr
Zeile 1:		Zeile 1:
	'''Asynchronous module definition''' ('''AMD''') ist eine [[JavaScript]]-[[Programmierschnittstelle]], mit deren Hilfe [[Modul (Software)\|Module]] und ihre Abhängigkeiten asynchron geladen werden können. Es bildet dadurch zwei grundlegende Konzepte der Software-Entwicklung, Modularisierung und Wiederverwendung, in der ansonsten [[Funktionale Programmierung\|funktional]] und [[Monolith#~~Weitere Verwendungen der Ausdrücke „Monolith“ und „monolithisch“~~\|monolithisch]] aufgebauten JavaScript-Umgebung ab. Die Modularisierung erlaubt die Aufteilung einer Javascript-Anwendung in einzelne Teilkomponenten, welche separat entwickelt und getestet werden können ([[Teile_und_herrsche_(Informatik)\|Teile und Herrsche]]). Aufgrund von klaren Schnittstellen können AMD-Module in anderen Softwareprojekten wiederverwendet werden.		'''Asynchronous module definition''' ('''AMD''') ist eine [[JavaScript]]-[[Programmierschnittstelle]], mit deren Hilfe [[Modul (Software)\|Module]] und ihre Abhängigkeiten asynchron geladen werden können. Es bildet dadurch zwei grundlegende Konzepte der Software-Entwicklung, Modularisierung und Wiederverwendung, in der ansonsten [[Funktionale Programmierung\|funktional]] und [[Monolith#Weitere_Verwendungen_der_Ausdrücke_Monolith_und_monolithisch\|monolithisch]] aufgebauten JavaScript-Umgebung ab. Die Modularisierung erlaubt die Aufteilung einer Javascript-Anwendung in einzelne Teilkomponenten, welche separat entwickelt und getestet werden können ([[Teile_und_herrsche_(Informatik)\|Teile und Herrsche]]). Aufgrund von klaren Schnittstellen können AMD-Module in anderen Softwareprojekten wiederverwendet werden.

	Die Vorgehensweise basiert weitestgehend auf dem [[Inversion of Control\|Inversion-of-Control]]-[[Entwurfsmuster]] (IoC Pattern). Das Modul entspricht dabei dem Begriff der Bean in IoC.<ref>{{Webarchiv\|url=https://docs.jboss.org/author/display/GTNPORTAL34/GDG-Asynchronous+Module+Definition \|wayback=20160304121006 \|text=Archivierte Kopie \|archiv-bot=2022-10-05 21:59:22 InternetArchiveBot }}</ref> Dadurch wird es ermöglicht, dass auch JavaScript modular aufgebaut werden kann. Das Resultat sind Module, die vergleichbar mit [[Java (Programmiersprache)\|Java]]-[[Klasse_(Programmierung)\|Klassen]] sind, und auch genauso durch Vererbung erweitert werden können.<ref>http://docs.weejot.com/developer/reference/amd.html</ref> Jedes Modul muss dabei – analog zur Java-Klasse – in einer eigenen [[Datei]] gespeichert sein.		Die Vorgehensweise basiert weitestgehend auf dem [[Inversion of Control\|Inversion-of-Control]]-[[Entwurfsmuster]] (IoC Pattern). Das Modul entspricht dabei dem Begriff der Bean in IoC.<ref>{{Webarchiv\|url=https://docs.jboss.org/author/display/GTNPORTAL34/GDG-Asynchronous+Module+Definition \|wayback=20160304121006 \|text=Archivierte Kopie \|archiv-bot=2022-10-05 21:59:22 InternetArchiveBot }}</ref> Dadurch wird es ermöglicht, dass auch JavaScript modular aufgebaut werden kann. Das Resultat sind Module, die vergleichbar mit [[Java (Programmiersprache)\|Java]]-[[Klasse_(Programmierung)\|Klassen]] sind, und auch genauso durch Vererbung erweitert werden können.<ref>http://docs.weejot.com/developer/reference/amd.html</ref> Jedes Modul muss dabei – analog zur Java-Klasse – in einer eigenen [[Datei]] gespeichert sein.

InternetArchiveBot: InternetArchiveBot hat 1 Archivlink(s) ergänzt und 0 Link(s) als defekt/tot markiert.) #IABot (v2.0.9.2

2022-10-05T21:59:24Z

InternetArchiveBot hat 1 Archivlink(s) ergänzt und 0 Link(s) als defekt/tot markiert.) #IABot (v2.0.9.2

← Nächstältere Version		Version vom 5. Oktober 2022, 23:59 Uhr
Zeile 1:		Zeile 1:
	'''Asynchronous module definition''' ('''AMD''') ist eine [[JavaScript]]-[[Programmierschnittstelle]], mit deren Hilfe [[Modul (Software)\|Module]] und ihre Abhängigkeiten asynchron geladen werden können. Es bildet dadurch zwei grundlegende Konzepte der Software-Entwicklung, Modularisierung und Wiederverwendung, in der ansonsten [[Funktionale Programmierung\|funktional]] und [[Monolith#Weitere Verwendungen der Ausdrücke „Monolith“ und „monolithisch“\|monolithisch]] aufgebauten JavaScript-Umgebung ab. Die Modularisierung erlaubt die Aufteilung einer Javascript-Anwendung in einzelne Teilkomponenten, welche separat entwickelt und getestet werden können ([[Teile_und_herrsche_(Informatik)\|Teile und Herrsche]]). Aufgrund von klaren Schnittstellen können AMD-Module in anderen Softwareprojekten wiederverwendet werden.		'''Asynchronous module definition''' ('''AMD''') ist eine [[JavaScript]]-[[Programmierschnittstelle]], mit deren Hilfe [[Modul (Software)\|Module]] und ihre Abhängigkeiten asynchron geladen werden können. Es bildet dadurch zwei grundlegende Konzepte der Software-Entwicklung, Modularisierung und Wiederverwendung, in der ansonsten [[Funktionale Programmierung\|funktional]] und [[Monolith#Weitere Verwendungen der Ausdrücke „Monolith“ und „monolithisch“\|monolithisch]] aufgebauten JavaScript-Umgebung ab. Die Modularisierung erlaubt die Aufteilung einer Javascript-Anwendung in einzelne Teilkomponenten, welche separat entwickelt und getestet werden können ([[Teile_und_herrsche_(Informatik)\|Teile und Herrsche]]). Aufgrund von klaren Schnittstellen können AMD-Module in anderen Softwareprojekten wiederverwendet werden.

	Die Vorgehensweise basiert weitestgehend auf dem [[Inversion of Control\|Inversion-of-Control]]-[[Entwurfsmuster]] (IoC Pattern). Das Modul entspricht dabei dem Begriff der Bean in IoC.<ref>https://docs.jboss.org/author/display/GTNPORTAL34/GDG-Asynchronous+Module+Definition</ref> Dadurch wird es ermöglicht, dass auch JavaScript modular aufgebaut werden kann. Das Resultat sind Module, die vergleichbar mit [[Java (Programmiersprache)\|Java]]-[[Klasse_(Programmierung)\|Klassen]] sind, und auch genauso durch Vererbung erweitert werden können.<ref>http://docs.weejot.com/developer/reference/amd.html</ref> Jedes Modul muss dabei – analog zur Java-Klasse – in einer eigenen [[Datei]] gespeichert sein.		Die Vorgehensweise basiert weitestgehend auf dem [[Inversion of Control\|Inversion-of-Control]]-[[Entwurfsmuster]] (IoC Pattern). Das Modul entspricht dabei dem Begriff der Bean in IoC.<ref>{{Webarchiv\|url=https://docs.jboss.org/author/display/GTNPORTAL34/GDG-Asynchronous+Module+Definition \|wayback=20160304121006 \|text=Archivierte Kopie \|archiv-bot=2022-10-05 21:59:22 InternetArchiveBot }}</ref> Dadurch wird es ermöglicht, dass auch JavaScript modular aufgebaut werden kann. Das Resultat sind Module, die vergleichbar mit [[Java (Programmiersprache)\|Java]]-[[Klasse_(Programmierung)\|Klassen]] sind, und auch genauso durch Vererbung erweitert werden können.<ref>http://docs.weejot.com/developer/reference/amd.html</ref> Jedes Modul muss dabei – analog zur Java-Klasse – in einer eigenen [[Datei]] gespeichert sein.

	Vorteile der Modularisierung bestehen besonders im [[Webbrowser\|Browser]]-Umfeld, wo JavaScript besonders häufig genutzt wird. Es werden nur die benötigten Module geladen, nicht jedoch alles, wie es beim synchronen Laden der Fall wäre. Das erhöht einerseits die Performanz des Codes und erleichtert andererseits das [[Debugger\|Debuggen]], insbesondere bei Cross-Domain-Zugriffsproblemen.<ref>https://github.com/amdjs/amdjs-api/wiki/AMD</ref> Weiterhin ermöglicht es eine bessere Wiederverwendbarkeit einzelner Codefragmente, ohne diese per Kopieren und Einfügen oder serverseitige Verkettung (''server side concatenation'') transportieren zu müssen. Daraus ergibt sich eine Verringerung der Nutzung [[Variable (Programmierung)#Variablen in einer Blockstruktur\|globaler Variablen]] auf ein Minimum und reduziert so die durch Namespace Pollution entstehenden Probleme signifikant.		Vorteile der Modularisierung bestehen besonders im [[Webbrowser\|Browser]]-Umfeld, wo JavaScript besonders häufig genutzt wird. Es werden nur die benötigten Module geladen, nicht jedoch alles, wie es beim synchronen Laden der Fall wäre. Das erhöht einerseits die Performanz des Codes und erleichtert andererseits das [[Debugger\|Debuggen]], insbesondere bei Cross-Domain-Zugriffsproblemen.<ref>https://github.com/amdjs/amdjs-api/wiki/AMD</ref> Weiterhin ermöglicht es eine bessere Wiederverwendbarkeit einzelner Codefragmente, ohne diese per Kopieren und Einfügen oder serverseitige Verkettung (''server side concatenation'') transportieren zu müssen. Daraus ergibt sich eine Verringerung der Nutzung [[Variable (Programmierung)#Variablen in einer Blockstruktur\|globaler Variablen]] auf ein Minimum und reduziert so die durch Namespace Pollution entstehenden Probleme signifikant.

Wruedt: Abschnittlink korrigiert

2019-12-25T08:37:18Z

Abschnittlink korrigiert

← Nächstältere Version		Version vom 25. Dezember 2019, 10:37 Uhr
Zeile 1:		Zeile 1:
	'''Asynchronous module definition''' ('''AMD''') ist eine [[JavaScript]]-[[Programmierschnittstelle]], mit deren Hilfe [[Modul (Software)\|Module]] und ihre Abhängigkeiten asynchron geladen werden können. Es bildet dadurch zwei grundlegende Konzepte der Software-Entwicklung, Modularisierung und Wiederverwendung, in der ansonsten [[Funktionale Programmierung\|funktional]] und [[Monolith#~~Allgemein~~\|monolithisch]] aufgebauten JavaScript-Umgebung ab. Die Modularisierung erlaubt die Aufteilung einer Javascript-Anwendung in einzelne Teilkomponenten, welche separat entwickelt und getestet werden können ([[Teile_und_herrsche_(Informatik)\|Teile und Herrsche]]). Aufgrund von klaren Schnittstellen können AMD-Module in anderen Softwareprojekten wiederverwendet werden.		'''Asynchronous module definition''' ('''AMD''') ist eine [[JavaScript]]-[[Programmierschnittstelle]], mit deren Hilfe [[Modul (Software)\|Module]] und ihre Abhängigkeiten asynchron geladen werden können. Es bildet dadurch zwei grundlegende Konzepte der Software-Entwicklung, Modularisierung und Wiederverwendung, in der ansonsten [[Funktionale Programmierung\|funktional]] und [[Monolith#Weitere Verwendungen der Ausdrücke „Monolith“ und „monolithisch“\|monolithisch]] aufgebauten JavaScript-Umgebung ab. Die Modularisierung erlaubt die Aufteilung einer Javascript-Anwendung in einzelne Teilkomponenten, welche separat entwickelt und getestet werden können ([[Teile_und_herrsche_(Informatik)\|Teile und Herrsche]]). Aufgrund von klaren Schnittstellen können AMD-Module in anderen Softwareprojekten wiederverwendet werden.

	Die Vorgehensweise basiert weitestgehend auf dem [[Inversion of Control\|Inversion-of-Control]]-[[Entwurfsmuster]] (IoC Pattern). Das Modul entspricht dabei dem Begriff der Bean in IoC.<ref>https://docs.jboss.org/author/display/GTNPORTAL34/GDG-Asynchronous+Module+Definition</ref> Dadurch wird es ermöglicht, dass auch JavaScript modular aufgebaut werden kann. Das Resultat sind Module, die vergleichbar mit [[Java (Programmiersprache)\|Java]]-[[Klasse_(Programmierung)\|Klassen]] sind, und auch genauso durch Vererbung erweitert werden können.<ref>http://docs.weejot.com/developer/reference/amd.html</ref> Jedes Modul muss dabei – analog zur Java-Klasse – in einer eigenen [[Datei]] gespeichert sein.		Die Vorgehensweise basiert weitestgehend auf dem [[Inversion of Control\|Inversion-of-Control]]-[[Entwurfsmuster]] (IoC Pattern). Das Modul entspricht dabei dem Begriff der Bean in IoC.<ref>https://docs.jboss.org/author/display/GTNPORTAL34/GDG-Asynchronous+Module+Definition</ref> Dadurch wird es ermöglicht, dass auch JavaScript modular aufgebaut werden kann. Das Resultat sind Module, die vergleichbar mit [[Java (Programmiersprache)\|Java]]-[[Klasse_(Programmierung)\|Klassen]] sind, und auch genauso durch Vererbung erweitert werden können.<ref>http://docs.weejot.com/developer/reference/amd.html</ref> Jedes Modul muss dabei – analog zur Java-Klasse – in einer eigenen [[Datei]] gespeichert sein.

Wikinger08: /* Einsatz */

2018-05-15T18:47:10Z

Einsatz

← Nächstältere Version		Version vom 15. Mai 2018, 20:47 Uhr
Zeile 12:		Zeile 12:
	== Einsatz ==		== Einsatz ==

	Das AMD-Format sieht eine spezielle Moduldefinition bzw. Komponentendefinition vor, welche die Deklaration und das korrekte Laden von Abhängigkeiten ermöglicht. Die Moduldefinition erfolgt somit auf der Basis von Programmierkonventionen. Diese Konvention hat sich bei vielen frei verfügbaren Javascript-Bibliotheken, wie z. B. jQuery oder Socket.io, durchgesetzt.		Das AMD-Format sieht eine spezielle Moduldefinition bzw. Komponentendefinition vor, welche die Deklaration und das korrekte Laden von Abhängigkeiten ermöglicht. Die Moduldefinition erfolgt somit auf der Basis von Programmierkonventionen. Diese Konvention hat sich bei vielen frei verfügbaren Javascript-Bibliotheken, wie z. B. [[jQuery]] oder [[Socket.IO]], durchgesetzt.
	<syntaxhighlight lang="javascript">		<syntaxhighlight lang="javascript">
	define("Name des Moduls", ["Abhängigkeit1", "Abhängigkeit2"], factory);		define("Name des Moduls", ["Abhängigkeit1", "Abhängigkeit2"], factory);

WA1TF0R am 3. März 2017 um 20:33 Uhr

2017-03-03T20:33:08Z

← Nächstältere Version		Version vom 3. März 2017, 22:33 Uhr
Zeile 1:		Zeile 1:
	'''Asynchronous module definition''' ('''AMD''') ist eine [[JavaScript]]–[[Programmierschnittstelle]], mit deren Hilfe [[Modul (Software)\|Module]] und ihre Abhängigkeiten asynchron geladen werden können. Es bildet dadurch zwei grundlegende Konzepte der Software-Entwicklung, Modularisierung und Wiederverwendung, in der ansonsten [[Funktionale Programmierung\|funktional]] und [[Monolith#Allgemein\|monolithisch]] aufgebauten JavaScript-Umgebung ab. Die Modularisierung erlaubt die Aufteilung einer Javascript-Anwendung in einzelne Teilkomponenten, welche separat entwickelt und getestet werden können ([[Teile_und_herrsche_(Informatik)\|Teile und Herrsche]]). Aufgrund von klaren Schnittstellen können AMD-Module in anderen Softwareprojekten wiederverwendet werden.		'''Asynchronous module definition''' ('''AMD''') ist eine [[JavaScript]]-[[Programmierschnittstelle]], mit deren Hilfe [[Modul (Software)\|Module]] und ihre Abhängigkeiten asynchron geladen werden können. Es bildet dadurch zwei grundlegende Konzepte der Software-Entwicklung, Modularisierung und Wiederverwendung, in der ansonsten [[Funktionale Programmierung\|funktional]] und [[Monolith#Allgemein\|monolithisch]] aufgebauten JavaScript-Umgebung ab. Die Modularisierung erlaubt die Aufteilung einer Javascript-Anwendung in einzelne Teilkomponenten, welche separat entwickelt und getestet werden können ([[Teile_und_herrsche_(Informatik)\|Teile und Herrsche]]). Aufgrund von klaren Schnittstellen können AMD-Module in anderen Softwareprojekten wiederverwendet werden.

	Die Vorgehensweise basiert weitestgehend auf dem [[Inversion of Control\|Inversion-of-Control]]-[[Entwurfsmuster]] (IoC Pattern). Das Modul entspricht dabei dem Begriff der Bean in IoC.<ref>https://docs.jboss.org/author/display/GTNPORTAL34/GDG-Asynchronous+Module+Definition</ref> Dadurch wird es ermöglicht, dass auch JavaScript modular aufgebaut werden kann. Das Resultat sind Module, die vergleichbar mit [[Java (Programmiersprache)\|Java]]-[[Klasse_(Programmierung)\|Klassen]] sind, und auch genauso durch Vererbung erweitert werden können.<ref>http://docs.weejot.com/developer/reference/amd.html</ref> Jedes Modul muss dabei – analog zur Java-Klasse – in einer eigenen [[Datei]] gespeichert sein.		Die Vorgehensweise basiert weitestgehend auf dem [[Inversion of Control\|Inversion-of-Control]]-[[Entwurfsmuster]] (IoC Pattern). Das Modul entspricht dabei dem Begriff der Bean in IoC.<ref>https://docs.jboss.org/author/display/GTNPORTAL34/GDG-Asynchronous+Module+Definition</ref> Dadurch wird es ermöglicht, dass auch JavaScript modular aufgebaut werden kann. Das Resultat sind Module, die vergleichbar mit [[Java (Programmiersprache)\|Java]]-[[Klasse_(Programmierung)\|Klassen]] sind, und auch genauso durch Vererbung erweitert werden können.<ref>http://docs.weejot.com/developer/reference/amd.html</ref> Jedes Modul muss dabei – analog zur Java-Klasse – in einer eigenen [[Datei]] gespeichert sein.

178.203.38.116: /* Einsatz */ Fehler im Programmcode (überzählige geschweifte Klammer) entfernt

2016-10-08T10:46:02Z

Einsatz: Fehler im Programmcode (überzählige geschweifte Klammer) entfernt

← Nächstältere Version		Version vom 8. Oktober 2016, 12:46 Uhr
Zeile 30:		Zeile 30:
	return plotModuleExport;		return plotModuleExport;
	};		};
	});		);
	</syntaxhighlight>		</syntaxhighlight>

← Nächstältere Version		Version vom 10. März 2023, 07:21 Uhr
Zeile 1:		Zeile 1:
	'''Asynchronous module definition''' ('''AMD''') ist eine [[JavaScript]]-[[Programmierschnittstelle]], mit deren Hilfe [[Modul (Software)\|Module]] und ihre Abhängigkeiten asynchron geladen werden können. Es bildet dadurch zwei grundlegende Konzepte der Software-Entwicklung, Modularisierung und Wiederverwendung, in der ansonsten [[Funktionale Programmierung\|funktional]] und [[Monolith#Weitere_Verwendungen_der_Ausdrücke_Monolith_und_monolithisch\|monolithisch]] aufgebauten JavaScript-Umgebung ab. Die Modularisierung erlaubt die Aufteilung einer Javascript-Anwendung in einzelne Teilkomponenten, welche separat entwickelt und getestet werden können ([[Teile_und_herrsche_(Informatik)\|Teile und Herrsche]]). Aufgrund von klaren Schnittstellen können AMD-Module in anderen Softwareprojekten wiederverwendet werden.		'''Asynchronous module definition''' ('''AMD''') ist eine [[JavaScript]]-[[Programmierschnittstelle]], mit deren Hilfe [[Modul (Software)\|Module]] und ihre Abhängigkeiten asynchron geladen werden können. Es bildet dadurch zwei grundlegende Konzepte der Software-Entwicklung, Modularisierung und Wiederverwendung, in der ansonsten [[Funktionale Programmierung\|funktional]] und [[Monolith#Weitere_Verwendungen_der_Ausdrücke_Monolith_und_monolithisch\|monolithisch]] aufgebauten JavaScript-Umgebung ab. Die Modularisierung erlaubt die Aufteilung einer Javascript-Anwendung in einzelne Teilkomponenten, welche separat entwickelt und getestet werden können ([[Teile_und_herrsche_(Informatik)\|Teile und Herrsche]]). Aufgrund von klaren Schnittstellen können AMD-Module in anderen Softwareprojekten wiederverwendet werden.

	Die Vorgehensweise basiert weitestgehend auf dem [[Inversion of Control\|Inversion-of-Control]]-[[Entwurfsmuster]] (IoC Pattern). Das Modul entspricht dabei dem Begriff der Bean in IoC.<ref>{{Webarchiv\|url=https://docs.jboss.org/author/display/GTNPORTAL34/GDG-Asynchronous+Module+Definition \|wayback=20160304121006 \|text=Archivierte Kopie \|archiv-bot=2022-10-05 21:59:22 InternetArchiveBot }}</ref> Dadurch wird es ermöglicht, dass auch JavaScript modular aufgebaut werden kann. Das Resultat sind Module, die vergleichbar mit [[Java (Programmiersprache)\|Java]]-[[Klasse_(Programmierung)\|Klassen]] sind, und auch genauso durch Vererbung erweitert werden können.<ref>http://docs.weejot.com/developer/reference/amd.html</ref> Jedes Modul muss dabei – analog zur Java-Klasse – in einer eigenen [[Datei]] gespeichert sein.		Die Vorgehensweise basiert weitestgehend auf dem [[Inversion of Control\|Inversion-of-Control]]-[[Entwurfsmuster]] (IoC Pattern). Das Modul entspricht dabei dem Begriff der Bean in IoC.<ref>{{Webarchiv\|url=https://docs.jboss.org/author/display/GTNPORTAL34/GDG-Asynchronous+Module+Definition \|wayback=20160304121006 \|text=Archivierte Kopie \|archiv-bot=2022-10-05 21:59:22 InternetArchiveBot }}</ref> Dadurch wird es ermöglicht, dass auch JavaScript modular aufgebaut werden kann. Das Resultat sind Module, die vergleichbar mit [[Java (Programmiersprache)\|Java]]-[[Klasse_(Programmierung)\|Klassen]] sind, und auch genauso durch Vererbung erweitert werden können.<ref>{{Webarchiv\|url=http://docs.weejot.com/developer/reference/amd.html \|wayback=20130718212018 \|text=Archivierte Kopie \|archiv-bot=2023-03-10 05:21:49 InternetArchiveBot }}</ref> Jedes Modul muss dabei – analog zur Java-Klasse – in einer eigenen [[Datei]] gespeichert sein.

	Vorteile der Modularisierung bestehen besonders im [[Webbrowser\|Browser]]-Umfeld, wo JavaScript besonders häufig genutzt wird. Es werden nur die benötigten Module geladen, nicht jedoch alles, wie es beim synchronen Laden der Fall wäre. Das erhöht einerseits die Performanz des Codes und erleichtert andererseits das [[Debugger\|Debuggen]], insbesondere bei Cross-Domain-Zugriffsproblemen.<ref>https://github.com/amdjs/amdjs-api/wiki/AMD</ref> Weiterhin ermöglicht es eine bessere Wiederverwendbarkeit einzelner Codefragmente, ohne diese per Kopieren und Einfügen oder serverseitige Verkettung (''server side concatenation'') transportieren zu müssen. Daraus ergibt sich eine Verringerung der Nutzung [[Variable (Programmierung)#Variablen in einer Blockstruktur\|globaler Variablen]] auf ein Minimum und reduziert so die durch Namespace Pollution entstehenden Probleme signifikant.		Vorteile der Modularisierung bestehen besonders im [[Webbrowser\|Browser]]-Umfeld, wo JavaScript besonders häufig genutzt wird. Es werden nur die benötigten Module geladen, nicht jedoch alles, wie es beim synchronen Laden der Fall wäre. Das erhöht einerseits die Performanz des Codes und erleichtert andererseits das [[Debugger\|Debuggen]], insbesondere bei Cross-Domain-Zugriffsproblemen.<ref>https://github.com/amdjs/amdjs-api/wiki/AMD</ref> Weiterhin ermöglicht es eine bessere Wiederverwendbarkeit einzelner Codefragmente, ohne diese per Kopieren und Einfügen oder serverseitige Verkettung (''server side concatenation'') transportieren zu müssen. Daraus ergibt sich eine Verringerung der Nutzung [[Variable (Programmierung)#Variablen in einer Blockstruktur\|globaler Variablen]] auf ein Minimum und reduziert so die durch Namespace Pollution entstehenden Probleme signifikant.

← Nächstältere Version		Version vom 5. Oktober 2022, 23:59 Uhr
Zeile 1:		Zeile 1:
	'''Asynchronous module definition''' ('''AMD''') ist eine [[JavaScript]]-[[Programmierschnittstelle]], mit deren Hilfe [[Modul (Software)\|Module]] und ihre Abhängigkeiten asynchron geladen werden können. Es bildet dadurch zwei grundlegende Konzepte der Software-Entwicklung, Modularisierung und Wiederverwendung, in der ansonsten [[Funktionale Programmierung\|funktional]] und [[Monolith#Weitere Verwendungen der Ausdrücke „Monolith“ und „monolithisch“\|monolithisch]] aufgebauten JavaScript-Umgebung ab. Die Modularisierung erlaubt die Aufteilung einer Javascript-Anwendung in einzelne Teilkomponenten, welche separat entwickelt und getestet werden können ([[Teile_und_herrsche_(Informatik)\|Teile und Herrsche]]). Aufgrund von klaren Schnittstellen können AMD-Module in anderen Softwareprojekten wiederverwendet werden.		'''Asynchronous module definition''' ('''AMD''') ist eine [[JavaScript]]-[[Programmierschnittstelle]], mit deren Hilfe [[Modul (Software)\|Module]] und ihre Abhängigkeiten asynchron geladen werden können. Es bildet dadurch zwei grundlegende Konzepte der Software-Entwicklung, Modularisierung und Wiederverwendung, in der ansonsten [[Funktionale Programmierung\|funktional]] und [[Monolith#Weitere Verwendungen der Ausdrücke „Monolith“ und „monolithisch“\|monolithisch]] aufgebauten JavaScript-Umgebung ab. Die Modularisierung erlaubt die Aufteilung einer Javascript-Anwendung in einzelne Teilkomponenten, welche separat entwickelt und getestet werden können ([[Teile_und_herrsche_(Informatik)\|Teile und Herrsche]]). Aufgrund von klaren Schnittstellen können AMD-Module in anderen Softwareprojekten wiederverwendet werden.

	Die Vorgehensweise basiert weitestgehend auf dem [[Inversion of Control\|Inversion-of-Control]]-[[Entwurfsmuster]] (IoC Pattern). Das Modul entspricht dabei dem Begriff der Bean in IoC.<ref>https://docs.jboss.org/author/display/GTNPORTAL34/GDG-Asynchronous+Module+Definition</ref> Dadurch wird es ermöglicht, dass auch JavaScript modular aufgebaut werden kann. Das Resultat sind Module, die vergleichbar mit [[Java (Programmiersprache)\|Java]]-[[Klasse_(Programmierung)\|Klassen]] sind, und auch genauso durch Vererbung erweitert werden können.<ref>http://docs.weejot.com/developer/reference/amd.html</ref> Jedes Modul muss dabei – analog zur Java-Klasse – in einer eigenen [[Datei]] gespeichert sein.		Die Vorgehensweise basiert weitestgehend auf dem [[Inversion of Control\|Inversion-of-Control]]-[[Entwurfsmuster]] (IoC Pattern). Das Modul entspricht dabei dem Begriff der Bean in IoC.<ref>{{Webarchiv\|url=https://docs.jboss.org/author/display/GTNPORTAL34/GDG-Asynchronous+Module+Definition \|wayback=20160304121006 \|text=Archivierte Kopie \|archiv-bot=2022-10-05 21:59:22 InternetArchiveBot }}</ref> Dadurch wird es ermöglicht, dass auch JavaScript modular aufgebaut werden kann. Das Resultat sind Module, die vergleichbar mit [[Java (Programmiersprache)\|Java]]-[[Klasse_(Programmierung)\|Klassen]] sind, und auch genauso durch Vererbung erweitert werden können.<ref>http://docs.weejot.com/developer/reference/amd.html</ref> Jedes Modul muss dabei – analog zur Java-Klasse – in einer eigenen [[Datei]] gespeichert sein.

	Vorteile der Modularisierung bestehen besonders im [[Webbrowser\|Browser]]-Umfeld, wo JavaScript besonders häufig genutzt wird. Es werden nur die benötigten Module geladen, nicht jedoch alles, wie es beim synchronen Laden der Fall wäre. Das erhöht einerseits die Performanz des Codes und erleichtert andererseits das [[Debugger\|Debuggen]], insbesondere bei Cross-Domain-Zugriffsproblemen.<ref>https://github.com/amdjs/amdjs-api/wiki/AMD</ref> Weiterhin ermöglicht es eine bessere Wiederverwendbarkeit einzelner Codefragmente, ohne diese per Kopieren und Einfügen oder serverseitige Verkettung (''server side concatenation'') transportieren zu müssen. Daraus ergibt sich eine Verringerung der Nutzung [[Variable (Programmierung)#Variablen in einer Blockstruktur\|globaler Variablen]] auf ein Minimum und reduziert so die durch Namespace Pollution entstehenden Probleme signifikant.		Vorteile der Modularisierung bestehen besonders im [[Webbrowser\|Browser]]-Umfeld, wo JavaScript besonders häufig genutzt wird. Es werden nur die benötigten Module geladen, nicht jedoch alles, wie es beim synchronen Laden der Fall wäre. Das erhöht einerseits die Performanz des Codes und erleichtert andererseits das [[Debugger\|Debuggen]], insbesondere bei Cross-Domain-Zugriffsproblemen.<ref>https://github.com/amdjs/amdjs-api/wiki/AMD</ref> Weiterhin ermöglicht es eine bessere Wiederverwendbarkeit einzelner Codefragmente, ohne diese per Kopieren und Einfügen oder serverseitige Verkettung (''server side concatenation'') transportieren zu müssen. Daraus ergibt sich eine Verringerung der Nutzung [[Variable (Programmierung)#Variablen in einer Blockstruktur\|globaler Variablen]] auf ein Minimum und reduziert so die durch Namespace Pollution entstehenden Probleme signifikant.

← Nächstältere Version		Version vom 12. März 2023, 14:21 Uhr
Zeile 1:		Zeile 1:
	'''Asynchronous module definition''' ('''AMD''') ist eine [[JavaScript]]-[[Programmierschnittstelle]], mit deren Hilfe [[Modul (Software)\|Module]] und ihre Abhängigkeiten asynchron geladen werden können. Es bildet dadurch zwei grundlegende Konzepte der Software-Entwicklung, Modularisierung und Wiederverwendung, in der ansonsten [[Funktionale Programmierung\|funktional]] und [[Monolith#~~Weitere_Verwendungen_der_Ausdrücke_Monolith_und_monolithisch~~\|monolithisch]] aufgebauten JavaScript-Umgebung ab. Die Modularisierung erlaubt die Aufteilung einer Javascript-Anwendung in einzelne Teilkomponenten, welche separat entwickelt und getestet werden können ([[~~Teile_und_herrsche_~~(Informatik)\|Teile und Herrsche]]). Aufgrund von klaren Schnittstellen können AMD-Module in anderen Softwareprojekten wiederverwendet werden.		'''Asynchronous module definition''' ('''AMD''') ist eine [[JavaScript]]-[[Programmierschnittstelle]], mit deren Hilfe [[Modul (Software)\|Module]] und ihre Abhängigkeiten asynchron geladen werden können. Es bildet dadurch zwei grundlegende Konzepte der Software-Entwicklung, Modularisierung und Wiederverwendung, in der ansonsten [[Funktionale Programmierung\|funktional]] und [[Monolith#Weitere Verwendungen der Ausdrücke Monolith und monolithisch\|monolithisch]] aufgebauten JavaScript-Umgebung ab. Die Modularisierung erlaubt die Aufteilung einer Javascript-Anwendung in einzelne Teilkomponenten, welche separat entwickelt und getestet werden können ([[Teile und herrsche (Informatik)\|Teile und Herrsche]]). Aufgrund von klaren Schnittstellen können AMD-Module in anderen Softwareprojekten wiederverwendet werden.

	Die Vorgehensweise basiert weitestgehend auf dem [[Inversion of Control\|Inversion-of-Control]]-[[Entwurfsmuster]] (IoC Pattern). Das Modul entspricht dabei dem Begriff der Bean in IoC.<ref>{{Webarchiv\|url=https://docs.jboss.org/author/display/GTNPORTAL34/GDG-Asynchronous+Module+Definition \|wayback=20160304121006 \|text=Archivierte Kopie \|archiv-bot=2022-10-05 21:59:22 InternetArchiveBot }}</ref> Dadurch wird es ermöglicht, dass auch JavaScript modular aufgebaut werden kann. Das Resultat sind Module, die vergleichbar mit [[Java (Programmiersprache)\|Java]]-[[~~Klasse_~~(Programmierung)\|Klassen]] sind, und auch genauso durch Vererbung erweitert werden können.<ref>{{Webarchiv\|url=http://docs.weejot.com/developer/reference/amd.html \|wayback=20130718212018 \|text=Archivierte Kopie \|archiv-bot=2023-03-10 05:21:49 InternetArchiveBot }}</ref> Jedes Modul muss dabei – analog zur Java-Klasse – in einer eigenen [[Datei]] gespeichert sein.		Die Vorgehensweise basiert weitestgehend auf dem [[Inversion of Control\|Inversion-of-Control]]-[[Entwurfsmuster]] (IoC Pattern). Das Modul entspricht dabei dem Begriff der Bean in IoC.<ref>{{Webarchiv\|url=https://docs.jboss.org/author/display/GTNPORTAL34/GDG-Asynchronous+Module+Definition \|wayback=20160304121006 \|text=Archivierte Kopie \|archiv-bot=2022-10-05 21:59:22 InternetArchiveBot }}</ref> Dadurch wird es ermöglicht, dass auch JavaScript modular aufgebaut werden kann. Das Resultat sind Module, die vergleichbar mit [[Java (Programmiersprache)\|Java]]-[[Klasse (Programmierung)\|Klassen]] sind, und auch genauso durch Vererbung erweitert werden können.<ref>{{Webarchiv\|url=http://docs.weejot.com/developer/reference/amd.html \|wayback=20130718212018 \|text=Archivierte Kopie \|archiv-bot=2023-03-10 05:21:49 InternetArchiveBot }}</ref> Jedes Modul muss dabei – analog zur Java-Klasse – in einer eigenen [[Datei]] gespeichert sein.

	Vorteile der Modularisierung bestehen besonders im [[Webbrowser\|Browser]]-Umfeld, wo JavaScript besonders häufig genutzt wird. Es werden nur die benötigten Module geladen, nicht jedoch alles, wie es beim synchronen Laden der Fall wäre. Das erhöht einerseits die Performanz des Codes und erleichtert andererseits das [[Debugger\|Debuggen]], insbesondere bei Cross-Domain-Zugriffsproblemen.<ref>https://github.com/amdjs/amdjs-api/wiki/AMD</ref> Weiterhin ermöglicht es eine bessere Wiederverwendbarkeit einzelner Codefragmente, ohne diese per Kopieren und Einfügen oder serverseitige Verkettung (''server side concatenation'') transportieren zu müssen. Daraus ergibt sich eine Verringerung der Nutzung [[Variable (Programmierung)#Variablen in einer Blockstruktur\|globaler Variablen]] auf ein Minimum und reduziert so die durch Namespace Pollution entstehenden Probleme signifikant.		Vorteile der Modularisierung bestehen besonders im [[Webbrowser\|Browser]]-Umfeld, wo JavaScript besonders häufig genutzt wird. Es werden nur die benötigten Module geladen, nicht jedoch alles, wie es beim synchronen Laden der Fall wäre. Das erhöht einerseits die Performanz des Codes und erleichtert andererseits das [[Debugger\|Debuggen]], insbesondere bei Cross-Domain-Zugriffsproblemen.<ref>https://github.com/amdjs/amdjs-api/wiki/AMD</ref> Weiterhin ermöglicht es eine bessere Wiederverwendbarkeit einzelner Codefragmente, ohne diese per Kopieren und Einfügen oder serverseitige Verkettung (''server side concatenation'') transportieren zu müssen. Daraus ergibt sich eine Verringerung der Nutzung [[Variable (Programmierung)#Variablen in einer Blockstruktur\|globaler Variablen]] auf ein Minimum und reduziert so die durch Namespace Pollution entstehenden Probleme signifikant.

	Durch die Vorgabe der Verteilung des Codes auf viele einzelne Dateien ergeben sich jedoch auch Nachteile. Jede Datei muss vom Browser in einem separaten [[Hypertext Transfer Protocol\|HTTP]]-Aufruf geladen werden, was bei vielen kleinen Dateien sehr viel [[Kommunikationsprotokoll\|Protokoll]]-[[~~Overhead_~~(EDV)\|Overhead]] erzeugen kann. Dadurch kann insbesondere bei Verbindungen mit hoher [[Verzögerungszeit\|Latenzzeit]] eine Verzögerung bemerkbar werden.<ref>~~http~~://tomdale.net/2012/01/amd-is-not-the-answer/</ref>		Durch die Vorgabe der Verteilung des Codes auf viele einzelne Dateien ergeben sich jedoch auch Nachteile. Jede Datei muss vom Browser in einem separaten [[Hypertext Transfer Protocol\|HTTP]]-Aufruf geladen werden, was bei vielen kleinen Dateien sehr viel [[Kommunikationsprotokoll\|Protokoll]]-[[Overhead (EDV)\|Overhead]] erzeugen kann. Dadurch kann insbesondere bei Verbindungen mit hoher [[Verzögerungszeit\|Latenzzeit]] eine Verzögerung bemerkbar werden.<ref>https://tomdale.net/2012/01/amd-is-not-the-answer/</ref>
	Dieser Overhead beim Abruf von verschiedenen Javascript-Dateien kann allerdings durch die Verwendung eines serverseitigen Bundlings kompensiert werden.<ref>~~http~~://requirejs.org/docs/api.html</ref>		Dieser Overhead beim Abruf von verschiedenen Javascript-Dateien kann allerdings durch die Verwendung eines serverseitigen Bundlings kompensiert werden.<ref>https://requirejs.org/docs/api.html</ref>

	Zur Umsetzung des AMD-Formats existieren verschiedene AMD-Frameworks wie z. B. [[RequireJS]], [[~~Dojo_Toolkit~~\|The Dojo Loader]] oder [[curl.js]].		Zur Umsetzung des AMD-Formats existieren verschiedene AMD-Frameworks wie z. B. [[RequireJS]], [[Dojo Toolkit\|The Dojo Loader]] oder [[curl.js]].

	== Einsatz ==		== Einsatz ==

	Das AMD-Format sieht eine spezielle Moduldefinition bzw. Komponentendefinition vor, welche die Deklaration und das korrekte Laden von Abhängigkeiten ermöglicht. Die Moduldefinition erfolgt somit auf der Basis von Programmierkonventionen. Diese Konvention hat sich bei vielen frei verfügbaren Javascript-Bibliotheken, wie z. B. [[jQuery]] oder [[Socket.IO]], durchgesetzt.		Das AMD-Format sieht eine spezielle Moduldefinition bzw. Komponentendefinition vor, welche die Deklaration und das korrekte Laden von Abhängigkeiten ermöglicht. Die Moduldefinition erfolgt somit auf der Basis von Programmierkonventionen. Diese Konvention hat sich bei vielen frei verfügbaren Javascript-Bibliotheken, wie z. B. [[jQuery]] oder [[Socket.IO]], durchgesetzt.
	<syntaxhighlight lang="javascript">		<syntaxhighlight lang="javascript">
	define("Name des Moduls", ["Abhängigkeit1", "Abhängigkeit2"], factory);		define("Name des Moduls", ["Abhängigkeit1", "Abhängigkeit2"], factory);
	</syntaxhighlight>		</syntaxhighlight>
	Der oben stehende Programmcode veranschaulicht die Moduldefinition im AMD-Format. Neben dem Namen des Moduls und den Abhängigkeiten wird eine Factory-Methode definiert, über die das Modul erzeugt wird. Diese Factory-Methode dient dazu, die Komponente zu instanziieren und mögliche Schnittstellen-Objekte zu exportieren. Wie erkenntlich wird, ist für den Einsatz des AMD-Formats eine Javascript-Bibliothek erforderlich, welche die define-Methode anbietet und die verschiedenen Komponenten instanziiert, sowie die Abhängigkeiten injizieren. Im AMD-Umfeld wird hierbei von einem AMD-Loader gesprochen. Die Vorgehensweise entspricht weitestgehend dem Muster der [[Abstrakte Fabrik\|abstrakten Fabrik]] und der [[Dependency Injection]] mit einem IoC-Container. Auf diese Weise können beliebige Komponenten instanziiert und die benötigten Abhängigkeiten können in der entsprechenden Reihenfolge bereitgestellt werden. Die einzelnen Komponenten einer JS-Anwendung können voneinander entkoppelt werden.		Der oben stehende Programmcode veranschaulicht die Moduldefinition im AMD-Format. Neben dem Namen des Moduls und den Abhängigkeiten wird eine Factory-Methode definiert, über die das Modul erzeugt wird. Diese Factory-Methode dient dazu, die Komponente zu instanziieren und mögliche Schnittstellen-Objekte zu exportieren. Wie erkenntlich wird, ist für den Einsatz des AMD-Formats eine Javascript-Bibliothek erforderlich, welche die define-Methode anbietet und die verschiedenen Komponenten instanziiert, sowie die Abhängigkeiten injizieren. Im AMD-Umfeld wird hierbei von einem AMD-Loader gesprochen. Die Vorgehensweise entspricht weitestgehend dem Muster der [[Abstrakte Fabrik\|abstrakten Fabrik]] und der [[Dependency Injection]] mit einem IoC-Container. Auf diese Weise können beliebige Komponenten instanziiert und die benötigten Abhängigkeiten können in der entsprechenden Reihenfolge bereitgestellt werden. Die einzelnen Komponenten einer JS-Anwendung können voneinander entkoppelt werden.

	<syntaxhighlight lang="javascript">		<syntaxhighlight lang="javascript">
	define('PieChartModule', ['area', 'graph'],		define('PieChartModule', ['area', 'graph'],
	function ( area, graph ) {		function ( area, graph ) {
	// Beschreibung des Plot-Modules		// Beschreibung des Plot-Modules
	var plotModuleExport = {		var plotModuleExport = {
Zeile 26:		Zeile 26:
	// Einfache Nutzung der Module “graph” und “area”		// Einfache Nutzung der Module “graph” und “area”
	return graph.drawPie(area.randomGrid(width, height), data);		return graph.drawPie(area.randomGrid(width, height), data);
	}		}
	};		};
	return plotModuleExport;		return plotModuleExport;
Zeile 35:		Zeile 35:
	== Weblinks ==		== Weblinks ==
	* [https://github.com/amdjs/amdjs-api/wiki/AMD AMD API wiki]		* [https://github.com/amdjs/amdjs-api/wiki/AMD AMD API wiki]
	* [~~http~~://requirejs.org/docs/whyamd.html Why AMD? (Require.js)]		* [https://requirejs.org/docs/whyamd.html Why AMD? (Require.js)]
	* [~~http~~://addyosmani.com/writing-modular-js/ Writing Modular JavaScript With AMD, CommonJS & ES Harmony]		* [https://addyosmani.com/writing-modular-js/ Writing Modular JavaScript With AMD, CommonJS & ES Harmony]

	== Einzelnachweise ==		== Einzelnachweise ==