Performance Frage: Objekt oder static?

Sladda

Aktives Mitglied
Hallo.

Ich habe einen Zeitkritischen Abschnitt (d.h. er muss so schnell wie möglich durchlaufen, weil er seeeeehr oft durchlaufen wird).
Nun die Frage:
ich parse in diesem Abschnitt einen String. Dazu habe ich mir eine Parse-Klasse geschrieben.
Ist es schneller innerhalb dieses Abschnitts für jeden Durchlauf ein neues Objekt dieser Parse-Klasse zu erstellen und damit zu arbeiten oder ist es schneller die Methoden der Klasse statisch zu machen und diese einfach statisch zu benutzen ?

Ich freue mich auf eure Antworten!
Viele Grüße
sladda
 
M

maki

Gast
Statisch passt nicht wirklich zu OOP, aber warum nicht nur ein einziges Obejkt erzeugen und das ständig nutzen?

Kennst du VisualVM?
Damit kannst du deine Java App Profilen und musst nicht vermuten wo die Rechenzeit bzw. der Speicher bleibt ;)
 

timbeau

Gesperrter Benutzer
Ich denke auch, dass diese Art nur einen geringen Einfluss auf die Laufzeit haben wird. Aber wenn du mal evaluierst, poste doch mal die Ergebnisse.
 

ice-breaker

Top Contributor
Wer sagt denn, dass die Objekterzeuugung überhaupt performancekritisch ist?
Ich könnte meine Hände dafür verwetten, dass der eigentliche Parser viel relevanter ist.
 

MrWhite

Bekanntes Mitglied
Wer sagt denn, dass die Objekterzeuugung überhaupt performancekritisch ist?
Ich könnte meine Hände dafür verwetten, dass der eigentliche Parser viel relevanter ist.

Unnötige Objekterzeugung ist sehr teuer und belastet auch den GC. Dessen Algorithmen sind auch nicht gerade billig.


Statisch passt nicht wirklich zu OOP

Sehe ich nicht unbedingt genauso. Kann man gelten lassen wenn man OOP auf Vererbung und Polymorphie beschränkt. In C# gibt es gar statische Klassen, Objekte die so nur einmal existieren können. Was spricht daran gegen OOP? Wir haben einen Zustand mit einem Verhalten gekoppelt und nennen das Objekt (einzig wahre Definition von OOP). Haben auch einen großen Nutzen für die OOP, z.B. Extension Methods zur Erweiterung der Funktionalität existierender Instanzen.
 
Zuletzt bearbeitet:
M

maki

Gast
Unnötige Objekterzeugung ist sehr teuer und belastet auch den GC. Dessen Algorithmen sind auch nicht gerade billig.
Das ist so falsch, kommt immer auf den Kontext an.
Objekte mit kleinem "Scope" belasten den GC zB. gar nicht.

Sehe ich nicht unbedingt genauso. Kann man gelten lassen wenn man OOP auf Vererbung und Polymorphie beschränkt. In C# gibt es gar statische Klassen, Objekte die so nur einmal existieren können. Was spricht daran gegen OOP? Wir haben einen Zustand mit einem Verhalten gekoppelt und nennen das Objekt (einzig wahre Definition von OOP). Haben auch einen großen Nutzen für die OOP, z.B. Extension Methods zur Erweiterung der Funktionalität existierender Instanzen.
Du musst bedenken dass das hier ein Javaforum ist, kein generelles OO Forum.
In Java gibt es eben enorme Einschränkungen was Vererbung von statischen Methoden betrifft, dazu kommt noch das "shadowing" Problem und natürlich der globale Scope von static Variablen.
Klar kann man dass auch zu einem Pseudo-OOP Konzept ummünzen und "statische Klassen" einführen.. spart man sich dadurch eine getInstance Methode in einem GoF Singleton? ;)
Erweiterung der funktionalität von existierenden Klassen gehen auch ohne statische Methoden, imho sogar sauberer, siehe mixins, allerdings gibt es sowas nicht in Java, dafür in anderen Sprachen die auf der JVM laufen.

Deine "einzig wahre Deifnition von OOP" sehe ich als unzureichend an.
 

FArt

Top Contributor
Unnötige Objekterzeugung ist sehr teuer und belastet auch den GC. Dessen Algorithmen sind auch nicht gerade billig.

So pauschale Aussagen sind oft gefährlich, weil nicht immer zutreffend.

ice-breaker hatte seine Aussage in Relation zum Rest gesetzt und hat mit dieser Aussage durchaus Recht. Wenn Objekte in einem kleinen Scope im EdenSpace erstellt werden, sind sie auch schnell wieder gelöscht. Dafür braucht es nämlich keinen Full GC.
 

MrWhite

Bekanntes Mitglied
Das ist so falsch, kommt immer auf den Kontext an.
Objekte mit kleinem "Scope" belasten den GC zB. gar nicht.

Mag wohl sein. Sollte man trotzdem nicht machen.


Klar kann man dass auch zu einem Pseudo-OOP Konzept ummünzen und "statische Klassen" einführen.. spart man sich dadurch eine getInstance Methode in einem GoF Singleton? ;)

Ja die spart man sich. Die braucht es auch nicht und die ist redundant. Baue ich mir eine Util-Klasse mit diversen Routinen, ist eine Singleton Implementierung unnötig. Ich werde nie von dieser Klasse erben, ich werde sie nie instanziieren und ich möchte auch nicht, dass einer je den Design-Fehler begeht und davon erbt. Die Routinen sind statisch und damit performant, die Benutzung so, wie ich es in meinem OOP Programm geplant habe. Meine Domäne freut sich.

Erweiterung der funktionalität von existierenden Klassen gehen auch ohne statische Methoden, imho sogar sauberer, siehe mixins, allerdings gibt es sowas nicht in Java, dafür in anderen Sprachen die auf der JVM laufen.

Deine "einzig wahre Deifnition von OOP" sehe ich als unzureichend an.

Ist meiner Ansicht nach, Data-Hiding miteingeschlossen, für die Wartbarkeit wichtiger als Polymorphie und Vererbung. Die sind natürlich auch wichtig. Aber das war schon weitergedacht. Der Grundgedanke war Zustand gekoppelt an Verhalten zugunsten der Wartbarkeit.
 

ice-breaker

Top Contributor
ice-breaker hatte seine Aussage in Relation zum Rest gesetzt und hat mit dieser Aussage durchaus Recht. Wenn Objekte in einem kleinen Scope im EdenSpace erstellt werden, sind sie auch schnell wieder gelöscht. Dafür braucht es nämlich keinen Full GC.

stimmt, eigentlich wollte ich aber darauf hinaus, dass sein Parser wahrscheinlich mehr Performance schluckt als eine Objekterzeuugung und der GC zusammen je benötigen werden, er also dort optimieren soll.
 
Zuletzt bearbeitet:
M

maki

Gast
Ja die spart man sich. Die braucht es auch nicht und die ist redundant. Baue ich mir eine Util-Klasse mit diversen Routinen, ist eine Singleton Implementierung unnötig. Ich werde nie von dieser Klasse erben, ich werde sie nie instanziieren und ich möchte auch nicht, dass einer je den Design-Fehler begeht und davon erbt. Die Routinen sind statisch und damit performant, die Benutzung so, wie ich es in meinem OOP Programm geplant habe. Meine Domäne freut sich.
"Die Routinen sind statisch und damit performant" ist reine Mutmassung, sorry.
Solltest das mal versuchen zu messen, ob eine statische Methode schneller ist als eine nicht statische von einem Objekt dass nur ein einziges mal instatiiert wird.
Du wirst rausfinden, dass du das nciht rausfinden kannst ;)
Ausser natürlich in total unrealistischen Anwendungsfällen.
Abgesehen davon halte ich das sog. "Perfomance Argument" für reine Einbildung/Verwirrung, wenn das so wichig würden wir keine abstrakte Highlevelsprachen mit riesigem Overhead verwenden, sondern unsere Programme in Assembler (am besten Opcode) schreiben :D

Das Problem mit GoF Singletons: Sie vermischen verschiedene Aspekte, SRP wird verletzt, namentlich: Obejkterzeugung und Zugriff, und dann wird man auch noch an eine statische Methode "gekettet".
DI Frameworks lösen diese alten Problem doch sehr gut, ein Spring Singleton zB. ist ein ganz normales POJO ohne spezielle Schnittstelle, es wird eben nur einmal erzeugt.
 

MrWhite

Bekanntes Mitglied
"Die Routinen sind statisch und damit performant" ist reine Mutmassung, sorry

Solltest das mal versuchen zu messen, ob eine statische Methode schneller ist als eine nicht statische von einem Objekt dass nur ein einziges mal instatiiert wird.
Du wirst rausfinden, dass du das nciht rausfinden kannst ;)
Ausser natürlich in total unrealistischen Anwendungsfällen.

Jaja, touche.

Das Problem mit GoF Singletons: Sie vermischen verschiedene Aspekte, SRP wird verletzt, namentlich: Obejkterzeugung und Zugriff, und dann wird man auch noch an eine statische Methode "gekettet".
DI Frameworks lösen diese alten Problem doch sehr gut, ein Spring Singleton zB. ist ein ganz normales POJO ohne spezielle Schnittstelle, es wird eben nur einmal erzeugt.

Fuer solche Zugriffe bau ich ein generisches Singleton (geht das ueberhaupt in Java?).

Code:
Singleton<SomeClass>.Instance.DoSomething();

DI Frameworks (essentiell Microkernel-Pattern) sind teilweise schwerfaellig in der Konfiguration und dem Deployment. Blanke Object-Builder machen das natuerlich anders, klar, wer das nicht ausnutzt ist selber schuld. Nicht wegen dem Singleton (s.o.), sondern hauptsaechlich wegen Proxies und Interception.

Aber ich moechte eigentlich nur festhalten, dass es voellig legitim und auch im Sinne der OOP ist zu sagen:

Alle Objekte einer Art besitzen gemeinschaftlich ein unveraenderliches Verhalten, dass sie durchfuehren koennen.

Edit:

A Generic Singleton Pattern in C# - Sanity Free Coding - C#, .NET, PHP
Und da sagt noch einer, static sei nicht sehr OOP. Was fuer ein wundervolles Konstrukt! Welch wunderbare Problemloesung. Static ist hoechstens ein bissal vererbungsfeindlich.
 
Zuletzt bearbeitet:
M

maki

Gast
Fuer solche Zugriffe bau ich ein generisches Singleton (geht das ueberhaupt in Java?).
Nein, in Java geht das nicht, weil static und Vererbung sich beissen, man bekommt höchstens einen unschönen Nebeneffekt: Shadowing

DI Frameworks (essentiell Microkernel-Pattern) sind teilweise schwerfaellig in der Konfiguration und dem Deployment.
Nicht in Java, siehe Spring bzw. Guice, oder gleich die Standards für DI in JEE

Und da sagt noch einer, static sei nicht sehr OOP. Was fuer ein wundervolles Konstrukt! Welch wunderbare Problemloesung. Static ist hoechstens ein bissal vererbungsfeindlich.
Ich behaupte immer noch static ist nicht wirklich OOP, in Java ;)

Zu deinem Link aus Java Sicht: Ist genau das Gegenteil von einem "wundervollen Konstrukt", sondern eine Missgeburt im Sinne des Designs.
Das ist keine Lösung, sondern das ist das Problem.
Wenn man mehr als ein einziges GoF Singleton braucht, hat man etwas falsch gemacht.
Dafür einen isolierten Unittest zu schreiben ist nicht schön, muss schon tricksen bzw. Frameworks nehmen die intern tricksen.
Das ist aber die Java Sicht der Dinge, die nicht unbedingt auf alle OOP Sprachen übertragbar ist, ausser natürlich die OOP Sprachen die gar kein static Konstrukt haben ;)
 

tfa

Top Contributor
Zu deinem Link aus Java Sicht: Ist genau das Gegenteil von einem "wundervollen Konstrukt", sondern eine Missgeburt im Sinne des Designs.
Das ist keine Lösung, sondern das ist das Problem.
Gruselig. Aber im Grunde ist das gar kein Singleton, sondern nur ein generischer Wrapper für beliebige Objekte mit einer ziemlich schwerfälligen, Mutex-synchronisierten Lazy-Initialization.
 

MrWhite

Bekanntes Mitglied
Es bringt nichts hier weiter zu diskutieren. Du bist meiner Ansicht nach ein Dogmatiker, das ist nicht zwingenderweise etwas schlechtes.

Diese Singleton-Implementierung ist so einfach testbar wie Klassen mit Injections, da braucht man auch Mock-Framworks etc. pp.

Wenn man mehr als ein einziges GoF Singleton braucht, hat man etwas falsch gemacht

Ich brauche genau eine Singleton Implementierung fuer eine Applikation. Da muss sich bei mir nicht zwingenderweise ein Container drum kuemmern. Wenn ich etwas in der Applikation als Singleton haben will, Schnittstelle hin oder her, dann werd ich auch mit Container sicherlich kein Lebenszyklusmanagement spaeter mehr umdefinieren. Letztendlich geht es bei der Singleton-Pattern um Zugriff und der ist wunderbar implementiert (SRP). Der Aufruf ist auch schoen, auch schoener, als ueber einen Container an das Objekt zu kommen und die Vererbungshierachien bleiben sauber. Was will man mehr.

Eine derartige Singleton Implementierung ist einfach nur elegant, wenn man das static-Schluesselwort nicht stiefmuetterlich betrachtet. Es ist eine technisch elegante und extrem simple Loesung, die ohne Container auskommt. Nuechtern betrachtet bietet sie sehr viele Vorteile.

Natuerlich nicht fuer einen Dogmatiker.

In Java koennte man so etwas durchaus auch schreiben, ist halt leider dort ueber Reflection nicht zur Compile-Time pruefbar.
 

MrWhite

Bekanntes Mitglied
Gruselig. Aber im Grunde ist das gar kein Singleton, sondern nur ein generischer Wrapper für beliebige Objekte mit einer ziemlich schwerfälligen, Mutex-synchronisierten Lazy-Initialization.

Jaja, ihr Java Leute.

EJB, JSF, XML-Hell ...

... um einige der Dinge zu nennen, zu denen eure Ansichten fuehren. ;)
 
M

maki

Gast
Es bringt nichts hier weiter zu diskutieren. Du bist meiner Ansicht nach ein Dogmatiker, das ist nicht zwingenderweise etwas schlechtes.
Ich denke wir sehen das ganze nur aus unterschiedlichen Perspektiven ;)

Ich brauche genau eine Singleton Implementierung fuer eine Applikation.
Da sind wir uns ja einig.

Diese Singleton-Implementierung ist so einfach testbar wie Klassen mit Injections, da braucht man auch Mock-Framworks etc. pp.
Eben nicht, zumindest nicht in Java.
Mock Frameworks sind ja nicht das Problem(schliesslich gibt es ja einige), aber die Auswahl darunter die es schaffen eine statische Referenz umzubiegen ist nicht mehr so groß und diese haben andere Nachteile.
JMock2, meine bevorzugte Mock Lib unterstützt das zB. nicht.

Letztendlich geht es bei der Singleton-Pattern um Zugriff und der ist wunderbar implementiert (SRP).
Beim Singleton Pattern geht es eben nicht um den Zugriff (globale Variable über eine statische Referenz/Methode) sondern um die Tatsache dass es davon nur ein einziges gibt.

Eine derartige Singleton Implementierung ist einfach nur elegant, wenn man das static-Schluesselwort nicht stiefmuetterlich betrachtet. Es ist eine technisch elegante und extrem simple Loesung, die ohne Container auskommt. Nuechtern betrachtet bietet sie sehr viele Vorteile.
Deine Einschätzung von Elegant kann ich nicht teilen und Container & Frameworks sind ja nichts unübliches in Java.
Abgesehen davon hatte ich ja bereits gesagt dass static nütlich ist, aber eben nicht 100% OOP, und genau darum ging es doch?

Natuerlich nicht fuer einen Dogmatiker.
Wie gesagt, ich denke wir sehen das ganze nur aus unterschiedlichen Persepktiven, ich sehe es eben aus der Java Perspektive.

In Java koennte man so etwas durchaus auch schreiben, ist halt leider dort ueber Reflection nicht zur Compile-Time pruefbar.
Sicher kann man sich auch seinen eigenen "Container" schreiben, aber davon gibt es ja schon so viele, und ob das so richtig Elegant ist..? ;)
 

tfa

Top Contributor
Diese Singleton-Implementierung ist so einfach testbar wie Klassen mit Injections, da braucht man auch Mock-Framworks etc. pp.
[...]
Letztendlich geht es bei der Singleton-Pattern um Zugriff
Ich kann mich irren, aber möglicherweise gibt es hier ein Verständnisproblem bezgl. Sinn und Zweck eines Singleton. Das GoF-Singleton (also das ursprüngliche Pattern) muss sicherstellen, dass genau ein Objekt der Klasse existiert - sonst geht die Welt unter. Das ist schon eine Einschränkung, die einem das Leben schwer machen kann. Sowas braucht man sehr selten, und vor allem muss man sich Fragen, wieso.
Wenn es dir vordergründig um Zugrifff geht, missbrauchst du das Pattern vielleicht als globale Variable (weil es so schon einfach ist, da ran zu kommen). Falls ich falsch liege, bitte ich um Entschuldigung.
Das Scope "Singleton", wie es manche DI-Frameworks kennen, ist was völlig anderes.

Der Aufruf ist auch schoen, auch schoener, als ueber einen Container an das Objekt zu kommen und die Vererbungshierachien bleiben sauber.
Du kommst nicht über den Container an das Singleton, der Container gibt dir das Singleton. Es ist einfach da, ohne dass man seinen Client-Code an eine bestimmte Implementierung oder statischen Aufruf binden muss. Das ist elegant.

Jaja, ihr Java Leute.
Vielleicht sind wir Java-Leute nur etwas weiter in der Entwicklung? Immerhin kommen viele gute Frameworks aus der Java-Welt - ganz ohne statisch-generische Singleton-Wrapper. Da profitieren auch andere von. Hibernate und Spring gibt es z.B. sogar für dot.net.

EJB, JSF, XML-Hell ...
... um einige der Dinge zu nennen, zu denen eure Ansichten fuehren.
Hm, da seh ich jetzt überhaupt keinen Zusammenhang zum Thema Singleton (zumal das alles völlig überholt ist). Falls das ein Kunstgriff der eristischen Dialektik sein sollte, war das ziemlich plump. Das üben wir noch...
 

MrWhite

Bekanntes Mitglied
Ich kann mich irren, aber möglicherweise gibt es hier ein Verständnisproblem bezgl. Sinn und Zweck eines Singleton. Das GoF-Singleton (also das ursprüngliche Pattern) muss sicherstellen, dass genau ein Objekt der Klasse existiert - sonst geht die Welt unter.

...missbrauchst du das Pattern vielleicht als globale Variable...

Ja, du irrst dich:

... ensure a class has only one instance, and provide a global point of access to it...

(aus Design Patterns).

Genau dafür war das Singleton gedacht.


Das Scope "Singleton", wie es manche DI-Frameworks kennen, ist was völlig anderes.

Sehe ich anders, aber ich habe sowieso das Gefühl, dass wir hier Haare spalten.

Du kommst nicht über den Container an das Singleton, der Container gibt dir das Singleton. Es ist einfach da, ohne dass man seinen Client-Code an eine bestimmte Implementierung oder statischen Aufruf binden muss. Das ist elegant.

Aber dafür bindest du dich an eine Konfiguration oder eine Annotation. Ersteres kann zur Compile-Time wieder nicht überprüft werden und führt bei uns in der Firma (größtenteils Java-Schmiede) auch immer wieder zu Problemen, die Stunden kosten.


Vielleicht sind wir Java-Leute nur etwas weiter in der Entwicklung? Immerhin kommen viele gute Frameworks aus der Java-Welt - ganz ohne statisch-generische Singleton-Wrapper. Da profitieren auch andere von. Hibernate und Spring gibt es z.B. sogar für dot.net.

Das ist schon wahr! Die Java-Welt hat auch viel Pionier Arbeit geleistet. Ich mag aber keinen Trampelpfad sondern bevorzuge gepflasterte Straßen. Was kümmern mich aber die tollen Konzepte wenn sie total überzogen umgesetzt werden. Beispielsweise sind EJB und JSF in der Benutzung und Handhabung einfach schmerzhaft. Das wurde jetzt über viele Jahre etwas besser. Derartig designte Frameworks/Technologien findet man in der .NET Welt irgendwie nicht. Im Gegenteil, neuartige Technologien sind meist von Anfang an hervorragend umgesetzt (WPF, LinQ).


Hm, da seh ich jetzt überhaupt keinen Zusammenhang zum Thema Singleton (zumal das alles völlig überholt ist). Falls das ein Kunstgriff der eristischen Dialektik sein sollte, war das ziemlich plump. Das üben wir noch...

Plump ist es, eine elegante Lösung für ein technisches Problem als gruselig abzutun weil es nicht ins Dogma passt.

Die Diskussion war ursprünglich nicht so geplant. Ich gebe ja zu, dass ich etwas pauschalisiert habe. Aber ihr seid das, was Martin Fowler als besessene Objekt-Puristen bezeichnen würde, die sonstige technische Lösungen ablehnen. Da muss ich einfach den Teufels Advokaten spielen.
 
Zuletzt bearbeitet:
M

maki

Gast
Genau dafür war das Singleton gedacht.
Autsch!
Das ist genau der Fehler den so viele gemacht haben, da wird SRP verletzt.

Sehen wir uns doch das Original statement zum Thema Singelton im Detail an:
Ensure a class has only one instance and provide a global point of access to it.
Da werden 2 Dinge vermischt: Wie oft darf ein Objekt erzeugt werden, und wie greife ich darauf zu.

Typischer Anfängerfehler imho, Globale Variablen nutzen, diese ein Design Pattern nennen und denken die Welt wäre in Ordnung und man hätte eine elegante Lösung *g*

Wenn man das sauber trennt, hat man keinen static zugriff mehr, eben wie ein Singleton in Spring/Guice/CDI.

Aber dafür bindest du dich an eine Konfiguration oder eine Annotation. Ersteres kann zur Compile-Time wieder nicht überprüft werden und führt bei uns in der Firma (größtenteils Java-Schmiede) auch immer wieder zu Problemen, die Stunden kosten.
Schon mal etwas von Unittests gehört, und vielleicht nicht nur gehört sondern auch angewendet?
Denn dann wüsstest dass das kein Argument mehr ist.

Plump ist es, eine elegante Lösung für ein technisches Problem als gruselig abzutun weil es nicht ins Dogma passt.
Plump ist es, mit unzureichendem Verständnis die primitiven Mittel die man hat als "gut/elegant" zu bezeichnen.

Die Diskussion war ursprünglich nicht so geplant. Ich gebe ja zu, dass ich etwas pauschalisiert habe. Aber ihr seid das, was Martin Fowler als besessene Objekt-Puristen bezeichnen würde, die sonstige technische Lösungen ablehnen. Da muss ich einfach den Teufels Advokaten spielen.
Du zeigst doch nur deine Lücken was OOP und Java betrifft, deine Argumentation hat sich von "static ist Objektorientiert" zu "Singleton ist toll" bis zu "OOP ist umständlich" verschoben.

Du bist ein Dogmatiker, der leider sein Fach nicht versteht, sorry.

Wie kann man einerseits auf die GoF Stein und Bein schwören was zB. Singleton betrifft, aber dabei die Grundsätze der OO ignorien, wie SRP?
Man muss alles immer in Frage stellen, und da ist dem SRP ganz klar der Vorzug zu geben zu dem, was die GoF mal in den 90er jahren als Best Practices bzw. "häufig verwendete Muster" zusammengeschrieben hatte.
 

tfa

Top Contributor
Vielen Dank maki für die Antwort. Das spart mir eine Menge Zeit. Du hast praktisch alles schon gesagt.

Ich finde es schon bedenklich, hier mitreden zu wollen und dabei den Unterschied zwischen einem GoF-Singleton und einem "DI-Singleton" nicht zu erkennen und das als Haarspalterei abzutun. Das sind zwei völlig verschiedene Dinge!
 

MrWhite

Bekanntes Mitglied
blabla Dogma blabla

Wenn man das sauber trennt, hat man keinen static zugriff mehr, eben wie ein Singleton in Spring/Guice/CDI.

Zeig mal ein Beispiel.

Schon mal etwas von Unittests gehört, und vielleicht nicht nur gehört sondern auch angewendet?
Denn dann wüsstest dass das kein Argument mehr ist.

Sicher kann man die entstandenen Lücken durch erheblichen Mehraufwand abdecken.

Du zeigst doch nur deine Lücken was OOP und Java betrifft, deine Argumentation hat sich von "static ist Objektorientiert" zu "Singleton ist toll" bis zu "OOP ist umständlich" verschoben.

Stimmt doch gar nicht. In wie fern habe ich OOP als umständlich bezeichnet? Es gibt keinen Grund, das Singleton als Pattern abzulehnen und static ist ein probates Mittel in der OOP. Es kommt immer auf den Einsatzzweck an und das ist Objektpurismus nicht unbedingt immer die beste Lösung.

Wenn du das nicht kapierst, dann kann ich dir auch nicht helfen.

Du bist ein Dogmatiker, der leider sein Fach nicht versteht, sorry.

Freudsch?
 
M

maki

Gast
..mindless dribble.. yaddi.. yaddi.. ya
Können das Niveau gerne in den Keller versenken wenn du dich dann wohler fühlst *g*

Zeig mal ein Beispiel.
Extra für dich:
Java:
public class MySingleton {
// instanz methoden, keine einzige davon static
}
Fertig, für Spring/Guice etc. reicht das, kein spez. Interface, gar nix.

Sicher kann man die entstandenen Lücken durch erheblichen Mehraufwand abdecken.
Was für Lücken und was für Mehraufwand?
Entweder man testet und stellt sicher dass der Code funktioniert, oder man arbeitet wie in den 90'er Jahren: Wenn Bugs gefunden werden vom Kunden, fixen wir die.

Stimmt doch gar nicht. In wie fern habe ich OOP als umständlich bezeichnet? Es gibt keinen Grund, das Singleton als Pattern abzulehnen und static ist ein probates Mittel in der OOP. Es kommt immer auf den Einsatzzweck an und das ist Objektpurismus nicht unbedingt immer die beste Lösung.
static ist kein Mittel der OO, aber dass ist dir wohl sowieso zu hoch.

Wenn du das nicht kapierst...
Psychological projection - Wikipedia, the free encyclopedia
 

MrWhite

Bekanntes Mitglied
Ich werd hier nicht weiter mit euch beiden diskutieren. Ich sehe die Dinge teilweise anders und bleibe auch dabei.

Ich glaub, so viele Posts wie du hast, hast du seit den 90ern kein echtes Projekt mehr durchgezogen. Wer soviel schreibt hat doch keine Zeit für Projektarbeit.
 
M

maki

Gast
Ich werd hier nicht weiter mit euch beiden diskutieren. Ich sehe die Dinge teilweise anders und bleibe auch dabei.
Hättest ja gleich zugeben können dass du weder von Java noch von OO Ahnung hast anstatt mit Pseudoargumenten zu versuchen längst wiederlegte Binsenweisheiten als Tatsachen darzustellen.

Ich glaub, so viele Posts wie du hast, hast du seit den 90ern kein echtes Projekt mehr durchgezogen. Wer soviel schreibt hat doch keine Zeit für Projektarbeit.
Das hiesse ja im Umkehrschluss dass du ständig vollbeschäftigt bist weil dein Blog insgesamt 2 Einträge enthält ;)
 

KSG9|sebastian

Top Contributor
Uh...Singleton, Static und Objekterzeugung in einem Thread, war klar dass das so ausartet. :)

Mal ein paar Statements von mir (ja, ich arbeite tatsächlich in dem Bereich, an einer extrem kritischen Anwendung im Finanzbereich).

Objekterzeugung ist teuer
Dieses Märchen hält sich hartnäckig. Das war mit Java < 1.3 mal so. Auch in den EJB 2.x-Zeiten stimmte das teilweise. Deshalb wurden die Objekte auch über einen Pool verwaltet um so wenig wie möglich neu zu erzeugen. Bei EJB lag es aber in keinster weise daran das die Objekterzeung per se teuer war, mehr an dem ganzen Laufzeitkram drum herum.
Das Märchen das Objekterzeugung im "normalen" JSE/JEE-Umfeld teuer ist ist absoluter Quatsch und schlicht falsch.

Singleton
Das Singleton-Pattern wird für alles Mögliche missbraucht, aber meist nicht als das für was es gedacht war. Das Singletonpattern soll sicherstellen das ein Objekt nur einmal existiert. In keinster Weise geht es darum ein Objekt global zur Verfügung zu stellen. Leider habe ich glaub noch nie in irgendeinem Projekt eine richtige Singletonimplementierung gesehen. Dort wurde das Singleton immer als globales Objekt missbraucht.

static or not
Static ist nunmal nicht im Sinne der OOP. Statischer Code ist schwer zu testen und vor allem führt es sehr oft zu Problemen. Beispiel gefällig?
Sobald Preloading am Server ins Spiel kommt gibt es schon Probleme, da die static(-Blöcke) dann sofort durchlaufen werden. Leider ist beim Preloading per Definition noch nicht alles vorhanden. Und schon knallt es und man verbringt Stunden mit der Suche. Nächstes Problem sind z.B. Umfeldern mit verschiedenen Classloadern - auch da ist static != static weil ein statisches Objekt trotzdem in jedem Classloader einmal lebt - was auch zu vielen Problemen führt.
Ich könnte noch zig weitere Beispiele aufführen, aber das ist glaub nicht nötig

Generisches Singleton
Gibt es irgend einen sinnvollen Einsatz dafür? Ich bin froh wenn die Projekte möglichst keine Singletons verwenden und damit biete ich noch einen Weg die Dinger für alles zu mißbrauchen. Der erste Schritt zum Objekt-Pooling.

GC/Compiler können statische Objekte besser aufräumen
Also du unterstellst hier Leuten Unwissenheit und dann kommst du mit so einem Spruch? In Zeiten von Hotspot und Co. hat das null komma null Auswirkungen....und ab dem 1000x (ca.) Aufruf hat sich's eh erledigt..


Zum Thema Optimierung/Performance mal ein schönes Zitat

Micro-Optimization doesn't matter

Der Satz sagt schon alles und ist zu 100% korrekt.

Wenn ich solchen Code hab

Java:
public void runLongTime(){
   new A();
   new B();

   parseOneGigabyteXML();

   new C();
   new D();

}

dann stellt sich mir doch folgende Frage:

Optimiere ich 4x Objekterzeugung welche effektiv nix kostet oder optimiere ich den Parser der 2GB XML-Dateien parst und dafür gefühlte Stunden benötigt?

Wir gehen mal davon aus das der ganze Vorgang 10 Sekunden läuft. Was hilft es mir wenn ich bei der Objekterzeugung 100ms rausholen kann (wobei 100ms enorm unrealistisch sind bei reiner Objekterzeugung)? Welchen Nutzen hat denn der Kunde davon?
 

ARadauer

Top Contributor
Leute jetzt streitets doch nicht! Es kommt doch aufs Beispiel an oder?

Hab ich vor kurzem gebraucht, wollte mir die Differenz von zwei Images berechnen...

Java:
 public static long getDifference(BufferedImage image1, BufferedImage image2) throws Exception {
      if(image1.getWidth() != image2.getWidth() || image1.getHeight() != image2.getHeight()){
        throw new Exception("bilder nicht gleich groß");         
      }      
      
      long dif = 0;
      for(int x = 0 ; x < image1.getWidth(); x++){
         for(int y = 0 ; y < image1.getHeight(); y++){
            
            
            //Variante 1 mit static
            int rgb1 = image1.getRGB(x, y); 
            int rgb2 = image2.getRGB(x, y);
            dif +=Math.abs(getRed(rgb1)-getRed(rgb2));
            dif +=Math.abs(getGreen(rgb1)-getGreen(rgb2));
            dif +=Math.abs(getBlue(rgb1)-getBlue(rgb2));
            
            
            //Variante 2 mit Color Objekt
            Color c1 = new Color( image1.getRGB(x, y));
            Color c2 = new Color( image2.getRGB(x, y));
            dif +=Math.abs(c1.getRed()-c2.getRed());
            dif +=Math.abs(c1.getGreen()-c2.getGreen());
            dif +=Math.abs(c1.getBlue()-c2.getBlue());
            
            //Variante 3: Color Objekt wiederverwenden...
            //color kann man den rgb wert nicht setzen ;-)           
            
         }
      }
      return dif;
   }

   public static int getRed(int rgb) {
      return (rgb >> 16) & 0xFF;
   }

   public static int getGreen(int rgb) {
      return (rgb >> 8) & 0xFF;
   }

   public static int getBlue(int rgb) {
      return (rgb >> 0) & 0xFF;
   }
Was ist schneller bei einem 2 Mega Pixel Bild?

Wir haben hier 4 Mio Color Objekt Instanzierungen dir wir uns sparen können!

Ich weiß das eine gängige Meinung ist, dass man nicht optimieren soll. Aber es gibt Ausnahmen!!!
 
M

maki

Gast
Leute jetzt streitets doch nicht!
Hast ja recht, die Diskussion ist schnell ins emotionale Abgewandert, wie eigentliche alle Threads in denen es um Singletons geht.

Es kommt doch aufs Beispiel an oder?
Eben.

Wäre dein Beispiel nicht mit einer statischen Methode, bräuchtest du auch getRed etc. Methoden nicht statisch, du hättest dann ein Objekt welches diese Werte auch nur ein einziges mal erzeugen würde, müsstest halt nur dafür sorgen dass dieses Obejkt wiederverwendet würde ;)
Der vollständikeit halber sei das Flyweight APttern noch erwähnt, geht in genau die gleiche Richtung.

Die Methode die du da zeigst ist auch prinizipiell einfach zu testen mit einem isolierten Unittest, weil sie eben keinen "kontext" hat, also keine (statischen/instanz) Variablen.
 
Ähnliche Java Themen
  Titel Forum Antworten Datum
8u3631984 Frage Performance bei Linked List und Array List Allgemeine Java-Themen 5
M Runtime.exec() - Performance / Frage zu Threads Allgemeine Java-Themen 5
H Performance einer Monte-Carlo-Simulation verbessern Allgemeine Java-Themen 6
goldmensch Datentypen Welche Methode hat die bessere Performance? Allgemeine Java-Themen 12
H Watson-Crick-Complement Performance Allgemeine Java-Themen 18
L Best Practice Auslagerung von Code = Performance Optimierung? Allgemeine Java-Themen 4
B Performance Messungen Allgemeine Java-Themen 4
J Threads verbessern die Performance NICHT ? Allgemeine Java-Themen 8
X Performance für Tomcat / Apache optimieren Allgemeine Java-Themen 2
I Performance - JDBC UPC PoolDataSoure Allgemeine Java-Themen 0
E Lambda filter performance Allgemeine Java-Themen 2
D Performance-Probleme mit Joda-Time Allgemeine Java-Themen 3
A Jasper Report Performance bei PDF erzeugen Allgemeine Java-Themen 0
A Best Practice Variablen vertauschen - Performance Allgemeine Java-Themen 1
R DBUnit Performance Probleme Allgemeine Java-Themen 0
P Performance: super explizit erwähnen oder weglassen? Allgemeine Java-Themen 5
S starke performance probleme des forums Allgemeine Java-Themen 10
C Performance Tips Allgemeine Java-Themen 13
A Performance/Speicherplatz-Nutzung bei Tests Allgemeine Java-Themen 6
R Java Performance testen Allgemeine Java-Themen 18
StrikeTom Java Performance Fragen Allgemeine Java-Themen 5
V Performance steigern Allgemeine Java-Themen 7
D Reflection-Performance Allgemeine Java-Themen 7
M Einfluss von Caching auf die Performance (große Arrays) Allgemeine Java-Themen 24
R Collections Performance einer HashMap Allgemeine Java-Themen 26
i<3java [Groovy/Grails](oder auch java) Mögliche Performance Probleme bei Mailversendung Allgemeine Java-Themen 2
D Performance Objektallokation Allgemeine Java-Themen 28
J Java Performance nicht nachvollziehbar Allgemeine Java-Themen 3
I Library für High Performance Mime Type Erkennung Allgemeine Java-Themen 8
M Performance Allgemeine Java-Themen 6
M Performance Allgemeine Java-Themen 5
E Performance website download Allgemeine Java-Themen 13
MQue Performance Methodenaufruf - if Abfrage Allgemeine Java-Themen 19
hdi Was frisst in meinem Programm den Speicher / verschlechtert die Performance Allgemeine Java-Themen 11
J Performance von Java GUI-Anwendungen Allgemeine Java-Themen 2
U Java Performance im Vergleich zu C++ in speziellem Anwendungsfall Allgemeine Java-Themen 6
S Performance und Function Call Depth Allgemeine Java-Themen 6
H Performance Vorteil durch Wechsel der JVM? Allgemeine Java-Themen 6
A Performance: byte[] in byte[][][] konvertieren Allgemeine Java-Themen 2
T Performance ArrayList#remove Allgemeine Java-Themen 8
ARadauer Performance Pptimierung -Lesen/Schreiben Allgemeine Java-Themen 10
Chris81T Performance Problem durch mehrfaches Starten eines JAVA Prog Allgemeine Java-Themen 8
G Hibernate, JTable und Performance Allgemeine Java-Themen 17
M Listener und Performance Allgemeine Java-Themen 9
P Performance: Ziehen ohne Zurücklegen (große Datenmenge) Allgemeine Java-Themen 10
D Performance: ArrayList vs. Array vs. "Eigene Liste&quot Allgemeine Java-Themen 8
M nichtreferenzierte Objekte auf NULL setzen -> Performance Allgemeine Java-Themen 4
S Ursache für schlechte Performance Allgemeine Java-Themen 2
L Java Performance Check Tool Allgemeine Java-Themen 3
S Performance von Comparator Allgemeine Java-Themen 3
egrath Performance Problem mit File-I/O Allgemeine Java-Themen 6
S Performance Problem Allgemeine Java-Themen 11
X Java Performance auf Sun Systemen bzw. generell Allgemeine Java-Themen 4
T Performance String-Operationen und StringBuffer (1.4und 1.5) Allgemeine Java-Themen 18
P miese performance bei nem BufferedImage + repaint :( Allgemeine Java-Themen 6
T Performance-Grundlagen Allgemeine Java-Themen 4
G Performance Problem bei der Übertragung Server zum Client Allgemeine Java-Themen 3
V Performance Leck finden Allgemeine Java-Themen 3
T Tile Game Performance Allgemeine Java-Themen 32
M Performance enorm langsam Allgemeine Java-Themen 26
F Performance von Reflection vs Statisches Coden Allgemeine Java-Themen 4
M Performance: Java zu C/C++ bei Datenbankanwendung Allgemeine Java-Themen 3
Y unnecessary cast & Performance Allgemeine Java-Themen 29
conan2 Performance von paint() Allgemeine Java-Themen 2
G Performance JDOM - DOM - eigene HashMap (SAX) Allgemeine Java-Themen 2
F Bilder als "Thumbnails" laden - Performance Allgemeine Java-Themen 6
S Java3D Performance optimieren Allgemeine Java-Themen 5
F Wenn ihr Performance wollt nehmt C++ Allgemeine Java-Themen 39
N Performance-Test (Geschwindigkeit von Methoden vergleichen)? Allgemeine Java-Themen 4
S Performance Test mit JMeter Allgemeine Java-Themen 2
T Performance Allgemeine Java-Themen 8
J Anfängerliste für gute Performance? Allgemeine Java-Themen 3
Luma Performance-Problem mit RandomAcces File Allgemeine Java-Themen 4
I Performance bei "String <-> Byte"-Umwandlung Allgemeine Java-Themen 4
I Performance-Probleme bei Schleife Allgemeine Java-Themen 3
C Performance von FOR Schleifen Allgemeine Java-Themen 25
C Performance Vergleich, Java vs. Tcl/Tk Allgemeine Java-Themen 3
KonradN Mal eine Frage zu Binary Serialization Allgemeine Java-Themen 15
8u3631984 Frage zu Java Streams min / max Allgemeine Java-Themen 17
H Frage regex greater than less than Allgemeine Java-Themen 7
berserkerdq2 Frage zu IntelliJ und JavaFX Allgemeine Java-Themen 1
W Timer Konzept-Frage Allgemeine Java-Themen 16
T Eine Frage des Designs Allgemeine Java-Themen 2
C Frage zu eigenem TableCellRenderer Allgemeine Java-Themen 11
C Programmvorstellung & Frage zum Thema Geschäftsform Allgemeine Java-Themen 51
J Frage zu System.getproperties. Allgemeine Java-Themen 60
molat100 wie kann man die Frage beantworten Allgemeine Java-Themen 1
pkm Frage zur Präzision von Calendar.WEEK_OF_YEAR Allgemeine Java-Themen 12
J Eine Frage zu den Threads und Task Allgemeine Java-Themen 1
pkm Frage nach eventuellem syntaktischen Zucker bei der Konkatenation von ArrayLists Allgemeine Java-Themen 4
M Frage-Antwortspiel wie Wer wird Millionär Allgemeine Java-Themen 1
F Frage zu System.in Allgemeine Java-Themen 3
marcooooo Frage zum Beispiel im Anhang Allgemeine Java-Themen 16
T Meine Frage lautet wie ich 2 CSV Dateien miteinander in Java verbinde und Spalten die zueinander gehören durch den gleichen Key zusammen ausgebe? Allgemeine Java-Themen 5
S Noch eine Design-Frage zu Setter Allgemeine Java-Themen 6
B For-Loop Frage Allgemeine Java-Themen 21
L Java frage Allgemeine Java-Themen 3
bueseb84 Frage zu Mock und UpperBound Allgemeine Java-Themen 2
M Frage zum Konstruktor Allgemeine Java-Themen 2
W Best Practice Frage zur Umsetzung MVC Allgemeine Java-Themen 9

Ähnliche Java Themen

Neue Themen


Oben