Plain Old Java Object - Versionsgeschichte

Filzstift am 31. Mai 2022 um 10:25 Uhr

2022-05-31T10:25:50Z

← Nächstältere Version		Version vom 31. Mai 2022, 12:25 Uhr
Zeile 20:		Zeile 20:
	== Variationen ==		== Variationen ==

	Seit November 2005 wird der Begriff „POJO“ hauptsächlich verwendet, um ein Objekt zu beschreiben, das nicht den großen Java-Objekt-Modellen, Konventionen, oder Frameworks wie [[Enterprise JavaBeans\|EJB]] entspricht.		Seit November 2005 wird der Begriff „POJO“ hauptsächlich verwendet, um ein Objekt zu beschreiben, das nicht den großen Java-Objekt-Modellen, Konventionen, oder Frameworks wie [[Enterprise JavaBeans\|EJB]] entspricht. Von POJO abgeleitet ist der Begriff „POCO“, der im [[.NET (Oberbegriff)\|.NET-Umfeld]] verwendet wird: [[Plain old CLR object]].

	Ein POJO ist ein Java-Objekt, das keinerlei Einschränkungen bis auf die der {{lang\|en\|[[Java Language Specification]]}} hat. Das heißt, ein POJO '''sollte kein(e)''':		Ein POJO ist ein Java-Objekt, das keinerlei Einschränkungen bis auf die der {{lang\|en\|[[Java Language Specification]]}} hat. Das heißt, ein POJO '''sollte kein(e)''':

Pintsknife: /* Motivation */

2021-12-26T11:07:21Z

Motivation

← Nächstältere Version		Version vom 26. Dezember 2021, 13:07 Uhr
Zeile 2:		Zeile 2:

	== Motivation ==		== Motivation ==
	Der Ausdruck wurde im September 2000 von [[Martin Fowler]], ''Rebecca Parsons'' und ''Josh MacKenzie'' geprägt<ref>{{Internetquelle \|autor=Martin Fowler \|url=https://www.martinfowler.com/bliki/POJO.html \|titel=MF Bliki: POJO \|~~zugriff~~=~~7. Februar~~ 2008}}</ref>, um einfache Java-Objekte von Objekten mit vielfältigen externen Abhängigkeiten unterscheiden zu können. Solche externen Abhängigkeiten können beispielsweise zwingend zu implementierende [[Schnittstelle (Programmierung)\|Schnittstellen]], einzuhaltende Namenskonventionen oder notwendige [[Annotation (Programmierung)\|Annotationen]] sein.		Der Ausdruck wurde im September 2000 von [[Martin Fowler]], ''Rebecca Parsons'' und ''Josh MacKenzie'' geprägt<ref>{{Internetquelle \|autor=Martin Fowler \|url=https://www.martinfowler.com/bliki/POJO.html \|titel=MF Bliki: POJO \|abruf=2008-02-07}}</ref>, um einfache Java-Objekte von Objekten mit vielfältigen externen Abhängigkeiten unterscheiden zu können. Solche externen Abhängigkeiten können beispielsweise zwingend zu implementierende [[Schnittstelle (Programmierung)\|Schnittstellen]], einzuhaltende Namenskonventionen oder notwendige [[Annotation (Programmierung)\|Annotationen]] sein.
	Die grundlegende Idee dabei lautet: „je einfacher, desto besser“ und ist auch als [[KISS-Prinzip]] bekannt.		Die grundlegende Idee dabei lautet: „je einfacher, desto besser“ und ist auch als [[KISS-Prinzip]] bekannt.

	{{Zitat~~-en~~		{{Zitat
	\|Text=We [M. Fowler, R. Parsons, J. MacKenzie] wondered why people were so against using regular objects in their systems and concluded that it was because simple objects lacked a fancy name. So we gave them one, and it’s caught on very nicely.		\|Text=We [M. Fowler, R. Parsons, J. MacKenzie] wondered why people were so against using regular objects in their systems and concluded that it was because simple objects lacked a fancy name. So we gave them one, and it’s caught on very nicely.
			\|Sprache=en
	\|Übersetzung=Wir [M. Fowler, R. Parsons, J. MacKenzie] fragten uns, warum die Leute so dagegen waren, in ihren Systemen normale Objekte zu nutzen und kamen zu dem Schluss, dass ein origineller Name für einfache Objekte fehlte. Also gaben wir ihnen einen, und er wurde sehr gut angenommen.		\|Übersetzung=Wir [M. Fowler, R. Parsons, J. MacKenzie] fragten uns, warum die Leute so dagegen waren, in ihren Systemen normale Objekte zu nutzen und kamen zu dem Schluss, dass ein origineller Name für einfache Objekte fehlte. Also gaben wir ihnen einen, und er wurde sehr gut angenommen.
	\|Autor=Martin Fowler		\|Autor=Martin Fowler}}
	}}

	== Verwendung ==		== Verwendung ==

Aka: /* Motivation */ https, Kleinkram

2021-04-11T09:25:12Z

Motivation: https, Kleinkram

← Nächstältere Version		Version vom 11. April 2021, 11:25 Uhr
Zeile 2:		Zeile 2:

	== Motivation ==		== Motivation ==
	Der Ausdruck wurde im September 2000 von [[Martin Fowler]], ''Rebecca Parsons'' und ''Josh MacKenzie'' geprägt<ref>{{Internetquelle \|autor=Martin Fowler \|url=~~http~~://www.martinfowler.com/bliki/POJO.html \|titel=MF Bliki: POJO \|zugriff=7. Februar 2008}}</ref>, um einfache Java-Objekte von Objekten mit vielfältigen externen Abhängigkeiten unterscheiden zu können. Solche externen Abhängigkeiten können beispielsweise zwingend zu implementierende [[Schnittstelle (Programmierung)\|Schnittstellen]], einzuhaltende Namenskonventionen oder notwendige [[Annotation (Programmierung)\|Annotationen]] sein.		Der Ausdruck wurde im September 2000 von [[Martin Fowler]], ''Rebecca Parsons'' und ''Josh MacKenzie'' geprägt<ref>{{Internetquelle \|autor=Martin Fowler \|url=https://www.martinfowler.com/bliki/POJO.html \|titel=MF Bliki: POJO \|zugriff=7. Februar 2008}}</ref>, um einfache Java-Objekte von Objekten mit vielfältigen externen Abhängigkeiten unterscheiden zu können. Solche externen Abhängigkeiten können beispielsweise zwingend zu implementierende [[Schnittstelle (Programmierung)\|Schnittstellen]], einzuhaltende Namenskonventionen oder notwendige [[Annotation (Programmierung)\|Annotationen]] sein.
	Die grundlegende Idee dabei lautet: „je einfacher, desto besser“ und ist auch als [[KISS-Prinzip]] bekannt.		Die grundlegende Idee dabei lautet: „je einfacher, desto besser“ und ist auch als [[KISS-Prinzip]] bekannt.

81.221.197.207: /* Motivation */

2021-01-23T13:39:37Z

Motivation

← Nächstältere Version		Version vom 23. Januar 2021, 15:39 Uhr
Zeile 6:		Zeile 6:

	{{Zitat-en		{{Zitat-en
	\|Text=We [M. Fowler, R. Parsons, J. MacKenzie] wondered why people were so against using regular objects in their systems and concluded that it was because simple objects lacked a fancy name. So we gave them one, and ~~it's~~ caught on very nicely.		\|Text=We [M. Fowler, R. Parsons, J. MacKenzie] wondered why people were so against using regular objects in their systems and concluded that it was because simple objects lacked a fancy name. So we gave them one, and it’s caught on very nicely.
	\|Übersetzung=Wir [M. Fowler, R. Parsons, J. MacKenzie] fragten uns, warum die Leute so dagegen waren, in ihren Systemen normale Objekte zu nutzen und kamen zu dem Schluss, dass ein origineller Name für einfache Objekte fehlte. Also gaben wir ihnen einen, und er wurde sehr gut angenommen.		\|Übersetzung=Wir [M. Fowler, R. Parsons, J. MacKenzie] fragten uns, warum die Leute so dagegen waren, in ihren Systemen normale Objekte zu nutzen und kamen zu dem Schluss, dass ein origineller Name für einfache Objekte fehlte. Also gaben wir ihnen einen, und er wurde sehr gut angenommen.
	\|Autor=Martin Fowler		\|Autor=Martin Fowler

ByJavaDev: Verneinung verdeutlicht

2021-01-16T16:44:34Z

Verneinung verdeutlicht

← Nächstältere Version		Version vom 16. Januar 2021, 18:44 Uhr
Zeile 22:		Zeile 22:
	Seit November 2005 wird der Begriff „POJO“ hauptsächlich verwendet, um ein Objekt zu beschreiben, das nicht den großen Java-Objekt-Modellen, Konventionen, oder Frameworks wie [[Enterprise JavaBeans\|EJB]] entspricht.		Seit November 2005 wird der Begriff „POJO“ hauptsächlich verwendet, um ein Objekt zu beschreiben, das nicht den großen Java-Objekt-Modellen, Konventionen, oder Frameworks wie [[Enterprise JavaBeans\|EJB]] entspricht.

	Ein POJO ist ein Java-Objekt, das keinerlei Einschränkungen bis auf die der {{lang\|en\|[[Java Language Specification]]}} hat. Das heißt, ein POJO sollte kein(e):		Ein POJO ist ein Java-Objekt, das keinerlei Einschränkungen bis auf die der {{lang\|en\|[[Java Language Specification]]}} hat. Das heißt, ein POJO '''sollte kein(e)''':
	# vorspezifizierte Klasse erweitern, wie z. B. hier:<syntaxhighlight lang="java">public class Foo extends javax.servlet.http.HttpServlet { …</syntaxhighlight>		# vorspezifizierte Klasse erweitern, wie z. B. hier:<syntaxhighlight lang="java">public class Foo extends javax.servlet.http.HttpServlet { …</syntaxhighlight>
	# vorspezifiziertes Interface implementieren, wie z. B. hier:<syntaxhighlight lang="java">public class Bar implements javax.ejb.EntityBean { …</syntaxhighlight>		# vorspezifiziertes Interface implementieren, wie z. B. hier:<syntaxhighlight lang="java">public class Bar implements javax.ejb.EntityBean { …</syntaxhighlight>

Carl B aus W: /* Motivation */

2020-08-30T15:55:36Z

Motivation

← Nächstältere Version		Version vom 30. August 2020, 17:55 Uhr
Zeile 7:		Zeile 7:
	{{Zitat-en		{{Zitat-en
	\|Text=We [M. Fowler, R. Parsons, J. MacKenzie] wondered why people were so against using regular objects in their systems and concluded that it was because simple objects lacked a fancy name. So we gave them one, and it's caught on very nicely.		\|Text=We [M. Fowler, R. Parsons, J. MacKenzie] wondered why people were so against using regular objects in their systems and concluded that it was because simple objects lacked a fancy name. So we gave them one, and it's caught on very nicely.
	\|Übersetzung=Wir [M. Fowler, R. Parsons, J. MacKenzie] fragten uns, warum die Leute so dagegen waren, in ihren Systemen ~~reguläre~~ Objekte zu nutzen und kamen zu dem Schluss, dass ein origineller Name für einfache Objekte fehlte. Also gaben wir ihnen einen, und er wurde sehr gut angenommen.		\|Übersetzung=Wir [M. Fowler, R. Parsons, J. MacKenzie] fragten uns, warum die Leute so dagegen waren, in ihren Systemen normale Objekte zu nutzen und kamen zu dem Schluss, dass ein origineller Name für einfache Objekte fehlte. Also gaben wir ihnen einen, und er wurde sehr gut angenommen.
	\|Autor=Martin Fowler		\|Autor=Martin Fowler
	}}		}}

Jokep: /* Variationen */

2019-08-26T10:43:33Z

Variationen

← Nächstältere Version		Version vom 26. August 2019, 12:43 Uhr
Zeile 25:		Zeile 25:
	# vorspezifizierte Klasse erweitern, wie z. B. hier:<syntaxhighlight lang="java">public class Foo extends javax.servlet.http.HttpServlet { …</syntaxhighlight>		# vorspezifizierte Klasse erweitern, wie z. B. hier:<syntaxhighlight lang="java">public class Foo extends javax.servlet.http.HttpServlet { …</syntaxhighlight>
	# vorspezifiziertes Interface implementieren, wie z. B. hier:<syntaxhighlight lang="java">public class Bar implements javax.ejb.EntityBean { …</syntaxhighlight>		# vorspezifiziertes Interface implementieren, wie z. B. hier:<syntaxhighlight lang="java">public class Bar implements javax.ejb.EntityBean { …</syntaxhighlight>
	# vorspezifizierte [[Annotation (Java)\|Annotation]] enthalten, wie z. B. hier:		# vorspezifizierte [[Annotation (Java)\|Annotation]] enthalten, wie z. B. hier:<syntaxhighlight lang="java">
		⚫	@javax.persistence.Entity
	<syntaxhighlight lang="java">
		⚫	public class Haus { …
⚫	@javax.persistence.Entity
⚫	public class Haus { …
	</syntaxhighlight>		</syntaxhighlight>

Jokep: /* Motivation */

2019-08-26T10:41:40Z

Motivation

← Nächstältere Version		Version vom 26. August 2019, 12:41 Uhr
Zeile 6:		Zeile 6:

	{{Zitat-en		{{Zitat-en
	\|Text=We[M. Fowler, R. Parsons, J. MacKenzie] wondered why people were so against using regular objects in their systems and concluded that it was because simple objects lacked a fancy name. So we gave them one, and it's caught on very nicely.		\|Text=We [M. Fowler, R. Parsons, J. MacKenzie] wondered why people were so against using regular objects in their systems and concluded that it was because simple objects lacked a fancy name. So we gave them one, and it's caught on very nicely.
	\|Übersetzung=Wir[M. Fowler, R. Parsons, J. MacKenzie] fragten uns, warum die Leute so dagegen waren, in ihren Systemen reguläre Objekte zu nutzen und kamen zu dem Schluss, dass ein origineller Name für einfache Objekte fehlte. Also gaben wir ihnen einen, und er wurde sehr gut angenommen.		\|Übersetzung=Wir [M. Fowler, R. Parsons, J. MacKenzie] fragten uns, warum die Leute so dagegen waren, in ihren Systemen reguläre Objekte zu nutzen und kamen zu dem Schluss, dass ein origineller Name für einfache Objekte fehlte. Also gaben wir ihnen einen, und er wurde sehr gut angenommen.
	\|Autor=Martin Fowler		\|Autor=Martin Fowler
	}}		}}

95.215.212.4: /* Variationen */

2018-10-04T16:07:34Z

Variationen

← Nächstältere Version		Version vom 4. Oktober 2018, 18:07 Uhr
Zeile 22:		Zeile 22:
	Seit November 2005 wird der Begriff „POJO“ hauptsächlich verwendet, um ein Objekt zu beschreiben, das nicht den großen Java-Objekt-Modellen, Konventionen, oder Frameworks wie [[Enterprise JavaBeans\|EJB]] entspricht.		Seit November 2005 wird der Begriff „POJO“ hauptsächlich verwendet, um ein Objekt zu beschreiben, das nicht den großen Java-Objekt-Modellen, Konventionen, oder Frameworks wie [[Enterprise JavaBeans\|EJB]] entspricht.

	Ein POJO ist ein Java-Objekt, das keinerlei Einschränkungen bis auf die der {{lang\|en\|[[Java Language Specification]]}} hat. Das heißt, ein POJO sollte ~~keine~~:		Ein POJO ist ein Java-Objekt, das keinerlei Einschränkungen bis auf die der {{lang\|en\|[[Java Language Specification]]}} hat. Das heißt, ein POJO sollte kein(e):
	# vorspezifizierte Klasse erweitern, wie z. B. hier:<syntaxhighlight lang="java">public class Foo extends javax.servlet.http.HttpServlet { …</syntaxhighlight>		# vorspezifizierte Klasse erweitern, wie z. B. hier:<syntaxhighlight lang="java">public class Foo extends javax.servlet.http.HttpServlet { …</syntaxhighlight>
	# vorspezifiziertes Interface implementieren, wie z. B. hier:<syntaxhighlight lang="java">public class Bar implements javax.ejb.EntityBean { …</syntaxhighlight>		# vorspezifiziertes Interface implementieren, wie z. B. hier:<syntaxhighlight lang="java">public class Bar implements javax.ejb.EntityBean { …</syntaxhighlight>

93.132.13.133: „Mit der Absicht, um“ ist doppelt gemoppelt, außerdem hieße es „in der Absicht“. „„In der Absicht zu können“ ist wiederum schlechter Stil, also: “um zu können“.

2017-06-13T21:34:30Z

„Mit der Absicht, um“ ist doppelt gemoppelt, außerdem hieße es „in der Absicht“. „„In der Absicht zu können“ ist wiederum schlechter Stil, also: “um zu können“.

← Nächstältere Version		Version vom 13. Juni 2017, 23:34 Uhr
Zeile 2:		Zeile 2:

	== Motivation ==		== Motivation ==
	Der Ausdruck wurde im September 2000 von [[Martin Fowler]], ''Rebecca Parsons'' und ''Josh MacKenzie'' ~~mit der Absicht~~ geprägt<ref>{{Internetquelle \|autor=Martin Fowler \|url=http://www.martinfowler.com/bliki/POJO.html \|titel=MF Bliki: POJO \|zugriff=7. Februar 2008}}</ref>, um einfache Java-Objekte von Objekten mit vielfältigen externen Abhängigkeiten unterscheiden zu können. Solche externen Abhängigkeiten können beispielsweise zwingend zu implementierende [[Schnittstelle (Programmierung)\|Schnittstellen]], einzuhaltende Namenskonventionen oder notwendige [[Annotation (Programmierung)\|Annotationen]] sein.		Der Ausdruck wurde im September 2000 von [[Martin Fowler]], ''Rebecca Parsons'' und ''Josh MacKenzie'' geprägt<ref>{{Internetquelle \|autor=Martin Fowler \|url=http://www.martinfowler.com/bliki/POJO.html \|titel=MF Bliki: POJO \|zugriff=7. Februar 2008}}</ref>, um einfache Java-Objekte von Objekten mit vielfältigen externen Abhängigkeiten unterscheiden zu können. Solche externen Abhängigkeiten können beispielsweise zwingend zu implementierende [[Schnittstelle (Programmierung)\|Schnittstellen]], einzuhaltende Namenskonventionen oder notwendige [[Annotation (Programmierung)\|Annotationen]] sein.
	Die grundlegende Idee dabei lautet: „je einfacher, desto besser“ und ist auch als [[KISS-Prinzip]] bekannt.		Die grundlegende Idee dabei lautet: „je einfacher, desto besser“ und ist auch als [[KISS-Prinzip]] bekannt.