Singleton pattern

Das sieht eher aus wie eine unvollstaendige Uebungsaufgabe. Du willst 
nicht lieber auf hausaufgabenhilfe.de gehen?

1. Das sind keine Hausaufgaben sondern die implementierung vom Singleton

2. Solche Kommentare solltest du dir lieber sparen, weil es hier darum 
geht sich gegenseitig zu unterstützen und nicht zu versuchen jeden 
runter zu machen. Wieso schaust du überhaupt in die Foren rein wenn eh 
nur blödsinn geschrieben wird ?

Der constuktor und die Copy Operator sind protected, damit kann man sie 
nicht von "außen" aufrufen. Mehr ist es nicht.

Viel wichtiger ist das Konzept. Ein Singleton ist ein Konstruk, das nur 
einmal instanziert werden kann. Das erreicht man zB mit einer Semaphore. 
Wenn sie weg ist, ist sie weg.

>Ein Singleton ist ein Konstruk, das nur einmal instanziert werden kann.

Vielleicht sollte man es so formulieren: Es muss nicht instantiiert 
werden, sondern es ist schon da.
Bei Objektorientierung gibt es normalerweise Klassen, die beschreiben, 
wie ein Objekt aussieht und was für Eigenschaften ein Objekt hat. Also 
z.B. so was

Klassendefinition Dreieck
var: Kantenlänge
var: xPos
var: yPos
function: zeichne Dreieck

Instantiieren heißt, dass man mit Hilfe dieser Beschreibung eine Objekt 
erst erzeugen muss. Das geschieht normalerweise mit dem New-Operator.

Dreieck d=new Dreieck();

Schaut man sich den obigen Code an, sieht man keinen New-Operator, 
sondern das Objekt ist gleich da. Es ist ein Singleton.

1

void main(){

2

3

Singleton *a, *b;

4

5

a=Singleton::Exemplar();

6

7

b=Singleton::Exemplar();

8

9

}

chris_ schrieb:
> sondern das Objekt ist gleich da. Es ist ein Singleton.
>
> void main(){
>
> Singleton *a, *b;
>
> a=Singleton::Exemplar();
>
> b=Singleton::Exemplar();
>
> }

welchen Objekt soll denn schon da sein? Das einzige was man hier sieht 
ist das eine Statik Funktion aufgerufen wird mehr nicht. In der Funktion 
kann das New gemacht werden.

> Instantiieren heißt, dass man mit Hilfe dieser Beschreibung eine Objekt
> erst erzeugen muss. Das geschieht normalerweise mit dem New-Operator.
stimmt auch nicht so, das New braucht man sogar recht selten. OBjekte 
werden einfach wie variablen angelegt.

1

Singleton a;

unknown schrieb:
> Hallo zusammen,
>
> ich gebe mal direkt zu, dass ich kein Programmiergenie bin und nur c++
> grundlagen beherrsche. Kann mir jemand kurz und knapp anhand folgendem
> Code erklären, wie ein Singleton muster genau funktioniert ? Ich weiß
> nur, dass es darum geht eine Instanz zu managen und auf eine Instanz zu
> begrenzen was tut genau der Singleton & operator=... ? und was ist mit
> implizit aufrufbar gemeint ?:
> class Singleton {

Das wichtige beim singleton ist wie schon gesagt, dass von der 
entsprechenden Klasse maximal ein Objekt gleichzeitig existieren kann.

> public:
>
> static Singleton* Exemplar (void); // Klassenmethode

Mit dieser statischen Methode wird das Objekt erzeugt. Es kann nicht auf 
anderem Weg erzeugt werden, weil der Standard- und Kopierkonstruktor 
gesperrt sind, einen allgemeinen Konstruktor gibt es ebenfalls nicht. 
Man kann dieses Objekt also weder dynamisch noch über eine Deklaration & 
Initialisierung erzeugen. Außerdem wird über diese Methode auch auf das 
Objekt zugegriffen, denn sie gibt den Zeiger auf das Objekt 
"theExemplar" zurück.

> protected:
>
> Singleton (void); // Konstruktor, nur implizit aufrufbar

Standardkonstruktor ist gesperrt!

> Singleton (const Singleton&); // kopieren verhindern

Kopierkonstruktor ist auch gesperrt.

> Singleton& operator= (const Singleton&); // zuweisen verhindern

Zuweisungsoperator ist auch gesperrt.

> ~Singleton (void); // Destruktor, nur implizit aufrufbar
>
> private:
>
> static Singleton* theExemplar; // Klassenvariable}

Diese Variable enthält den Zeiger auf das Objekt und wird beim Aufruf 
der Methode "Exemplar" zurückgegeben. Über diesen Zeiger kann man auf 
das Objekt zugreifen.

> Singleton::Singleton(void){ // Konstruktor
>
> }
>
> Singleton::~Singleton(void){ // Destruktor
>
> }
>
> Singleton* Singleton::theExemplar = 0; // Init Klassenvariable
>
> Singleton* Singleton::Exemplar() { // Erzeugung Exemplar
>
> if (theExemplar == 0){

Hier wird das Objekt dynamisch erzeugt, denn innerhalb der Klasse kann 
auf die Konstruktoren zugegriffen werden.

> }
>
> return (theExemplar);
>
> }
>
> Void main(){
>
> Singleton *a, *b;
>
> a=Singleton::Exemplar();
>
> b=Singleton::Exemplar();

Über die statische Methode wird der Zeiger auf das singleton angefordert 
und kann dann verwendet werden. a und b zeigen auf die selbe Adresse.

> }

Hat dir das geholfen?

Vernon D. schrieb:
> So schnell wie du dieses Pattern kennen gelernt hast, so schnell
> vergess' es auch wieder. Die Benutzung wird zwar gerne diskutiert, meine
> Erfahrung hat aber gezeigt das man besser darauf verzichtet.
> Weiterführendes Material:
>
> http://stackoverflow.com/a/138012/3045049

Du solltest die Links auch mal lesen und verstehen, bevor du generell 
etwas verdammst. Zitat aus deinem Link:

"In practice the Singleton pattern is just a programming technique that 
is a useful part of your toolkit of concepts. From time to time you 
might find it is the ideal solution and so use it. But using it just so 
you can boast about using a design pattern is just as stupid as refusing 
to ever use it because it is just a global."

Vernon hatte schon recht,

Der Andere schrieb:
> Du solltest die Links auch mal lesen und verstehen, bevor du generell
> etwas verdammst. Zitat aus deinem Link:

Da tust Du Vernon unrecht. Stackoverflow ist in etwa dasselbe wie dieses 
Forum einfach für andere Themen. Dass da auch eine andere Meinung 
auftaucht, ist ja wohl normal.

Allgemein gilt schon, dass das Singleton Patter der GoF zu vermeiden ist 
wenn möglich, resp. man muss sich das schon gut überlegen, ob es 
wirklich nötig ist. Unter den Entwicklern ist es auch kein besonders 
beliebtes Pattern.

Früher habe ich das auch oft gebraucht, heute versuche ich es aus den 
genannten Gründen zu vermeiden.

Eine sehr gute Antwort finde ich zum Thema die von Aaronaught:

http://programmers.stackexchange.com/questions/40373/so-singletons-are-bad-then-what.

Allerdings geht es da mehr um Java und die Alternative sieht in Java 
natürlich anders aus (C++ bietet leider/zum Glück kein Injection).

Grüsse,
René

>> Instantiieren heißt, dass man mit Hilfe dieser Beschreibung eine Objekt
>> erst erzeugen muss. Das geschieht normalerweise mit dem New-Operator.
>stimmt auch nicht so, das New braucht man sogar recht selten. OBjekte
>werden einfach wie variablen angelegt.

Ich muss zugeben, dass ich zwar viel objektorientiert habe, aber kaum in 
C++. Wenn man es lernen will, sollte man das auf keinen Fall mit C++ 
tun, sondern mit Python.


Meine Vorstellung ist, das mit

1

Testobjekt a;

Ein Nullpointer auf 'a' erzeugt wird, wenn 'a' keine Singleton ist.
Es gibt eigentlich dann noch keine Instanz des Objekts, sonder nur einen 
Nullpointer.

Wird mit

a=new Testobjekt();

dieser Nullpointer einer initailisierten Objektstruktur zugeordnet, dann 
gibt es ein Objekt bzw. eine Instanz der Klasse.

chris_ schrieb:
> Meine Vorstellung ist, das mit
> Testobjekt a;
>
> Ein Nullpointer auf 'a' erzeugt wird, wenn 'a' keine Singleton ist.
> Es gibt eigentlich dann noch keine Instanz des Objekts, sonder nur einen
> Nullpointer.

das ist aber bei C++ nicht so. So eine Variabel kann NIE NULL sein. Nur 
Zeiger können NULL sein.

Erzeugt ein objekt:

1

Testobjekt a;

Erzeugt kein Objekt, variabel ist undefiniert - also auch nicht zwingend 
NULL

1

Testobjekt* a;

chris_ schrieb:
> Vielleicht sollte man es so formulieren: Es muss nicht instantiiert
> werden, sondern es ist schon da.

Sorry chris_, das stimmt so nicht. Man muss jede Klasse instanzieren, 
auch ein Singleton. Das hat damit nichts zu tun.

Sven B. schrieb:
> Nur dass auf Stackoverflow nicht jede Trivialfrage eines Anfängers in
> eine sinnfreie Grundstzdiskussion wie diese ausartet.

Die Überlegung, dass das nach Hausarbeit aussieht war durchaus 
vernünftig. Verstärkt durch die für Ertappte heute typische Haltung 
nochmal nachzulegen, statt Bu­ße zu tun.

unknown schrieb:
> 2. Solche Kommentare solltest du dir lieber sparen, weil es hier darum
> geht sich gegenseitig zu unterstützen und nicht zu versuchen jeden
> runter zu machen. Wieso schaust du überhaupt in die Foren rein wenn eh
> nur blödsinn geschrieben wird ?

So motiviert man erstklassig.


PS: Das Plenken und der Ton des Schreibers kommt mir bekannt vor: 
Beitrag "Nach Abschlussarbeit keine Übernahme"

Sven B. schrieb:
> Nur dass auf Stackoverflow nicht jede Trivialfrage eines Anfängers in
> eine sinnfreie Grundstzdiskussion wie diese ausartet.

Das liegt aber auch daran, dass das Bewertungssystem der Antworten IMHO 
wirklich gut ist, und die Moderatoren ein Topic sehr schnell schließen 
wenn die Antwort schon vorhanden ist oder es zu Glaubenskriegen kommt.
Sonst wären dort die gleichen unendlichen Diskussionen vorhanen.
(Wäre das nicht was für hier...?)

Jay schrieb:
> Die Überlegung, dass das nach Hausarbeit aussieht war durchaus
> vernünftig. Verstärkt durch die für Ertappte heute typische Haltung
> nochmal nachzulegen, statt Bu­ße zu tun.

Ob es eine Hausaufgabe ist oder nicht, ist in dem Fall wirklich wurscht, 
da es keine "Lösung" gibt. So wie ich das verstanden habe, geht es um 
das Verständnis und hat somit durchaus seine Berechtigung hier zu 
fragen.

Grüsse,
René

Um wieder Richtung Thema zu kommen:

Kann mir jemand ein typisches Beispiel in einem "normalen" Embedded 
System geben, in dem das Singleton pattern eine praktische/gute Lösung 
ist?
Ich finde, Pattern ohne praxisbezogenes Beispiel sind wie 
Hardwareentwicklung ohne Hardwareaufbauten...

Marc schrieb:
> Kann mir jemand ein typisches Beispiel in einem "normalen" Embedded
> System geben, in dem das Singleton pattern eine praktische/gute Lösung
> ist?

Kontrolle des Speichers/Anzahl Instanzen.
Oder, wenn nur ein LCD vorhanden ist, reicht es auch eine Instanz für 
die LCD Ansteuerung zu haben. a.s.o.

Ob das eine gute Lösung ist? Ich würde mal sagen, Geschmacksache.

Marc schrieb:

> Ich finde, Pattern ohne praxisbezogenes Beispiel sind wie
> Hardwareentwicklung ohne Hardwareaufbauten...

Das dumme an Beispielen ist, dass sie immer konstruiert sind. Da kann 
man dann beliebig am Beispiel rumstreiten. Meine 
Mikrocontroller-Anwendungen zum Beispiel bilden immer limitierte 
Resourcen durch Singletons ab. Es gibt also einen Kontext, der global 
zur Verfuegung steht und da haengt dann zum Beispiel Serial drin und LCD 
und was eben noch so an Umgebung zur Verfuegung steht. Pattern-Anbeter 
wuerden jetzt schon wieder einen Streit vom Zaun brechen, dass Serial 
und LCD gar keine Singletons sind, sondern nur der Kontext. Whatever... 
effektiv sind das global verfuegbare, nur einmal existierende Resourcen.

Was uebrigens nicht automatisch bedeutet, dass auch jede Komponente vom 
Code ueber den globalen Kontext darauf zugreifen wuerde. Nehmen wir zum 
Beispiel an, das sei ein seriell angebundenes LCD, dann muss es ja 
Serial benutzen. Da es aber eine generische Komponente ist, sollte es 
besser nichts vom Kontext wissen. Also ist LCD so implementiert, als 
waere Serial kein Singleton, es bekommt dieses Injected.

Dagegen, wenn du ueber deinen ganzen Code hinweg Serial als 
Debug-Ausgabe benutzen willst, wirst du es kaum ueberall uebergeben 
wollen.

Kurzum: Die Frage Singleton oder nicht, ist so trivial nicht zu 
beantworten. Es kommt auf den Scope und auf die Anwendung an. Und vor 
allem sollte man sich seine eigenen Gedanken machen und nicht sklavisch 
irgendwelchen Mustern folgen - so waren sie auch nicht gedacht.

Jodel schrieb:
>Meine Mikrocontroller-Anwendungen zum Beispiel bilden immer limitierte
Resourcen durch Singletons ab.

OK, bei LCD ist das OK. Aber Controller haben in der Regel mehrere 
UARTs. Habe ich mit Singleton gearbeitet, und habe beim nächsten 
Controller acht statt eine uart muss ich umstellen.

> Kurzum: Die Frage Singleton oder nicht, ist so trivial nicht zu beantworten. Es 
kommt auf den Scope und auf die Anwendung an.
Klar, das verstehe ich und ich will ja nicht unüberlegt ein Pattern 
einsetzen.
Trotzdem nochmal meine Frage: Hat jemand ein Scope / eine Anwendung in 
einem Mikrocontroller System, für die das Pattern Singleton geradezu 
prädestiniert ist?

>>chris_
>> Ein Nullpointer auf 'a' erzeugt wird, wenn 'a' keine Singleton ist.
>> Es gibt eigentlich dann noch keine Instanz des Objekts, sonder nur einen
>> Nullpointer.
> Peter II (Gast)
>das ist aber bei C++ nicht so. So eine Variabel kann NIE NULL sein. Nur
>Zeiger können NULL sein.

Kann es sein, dass Du nicht weißt, was ein Nullpointer ist?

Naja, Bernd. Ich habe nicht geschrieben, dass ich das so machen würde. 
Singleton brauche ich nie, da es meiner Meinung nach ein längst 
überholtes und obsoletes Pattern ist.

>Dein Kommentar ist ohne Erklärung, was falsch ist, wertlos, es sei denn,
>du möchtest provozieren.

Gut, es war ein wenig kurz. Aber lies doch einfach mal die zwei Sätze:

>> Es gibt eigentlich dann noch keine Instanz des Objekts, sonder nur einen
>> Nullpointer.
>das ist aber bei C++ nicht so. So eine Variabel kann NIE NULL sein. Nur
>Zeiger können NULL sein.

Siehst Du da keinen Widerspruch zwischen Satz 1 und 2?

Peter || schrieb
>> Instantiieren heißt, dass man mit Hilfe dieser Beschreibung eine Objekt
>> erst erzeugen muss. Das geschieht normalerweise mit dem New-Operator.
>stimmt auch nicht so, das New braucht man sogar recht selten. OBjekte
>werden einfach wie variablen angelegt.

>Singleton a;

Peter Du hast Recht. Ich habe gerade folgendes mit Atmle Studio 
probiert:

1

#include <avr/io.h>

2

#include <stdio.h>

3

4

class Dreieck

5

{

6

  public:

7

    int xPos;

8

    int yPos;

9

};

10

11

Dreieck globalesDreieck;

12

13

int main(void)

14

{

15

  globalesDreieck.xPos=11;

16

  globalesDreieck.yPos=12;

17

18

  printf("%d",globalesDreieck.xPos);

19

20

21

    while (1) 

22

    {

23

    }

24

}

Es wird tatsächlich eine Instanz des Dreiecks an Adresse 0x104 des 
Atmega angelegt.

>>stimmt auch nicht so, das New braucht man sogar recht selten. OBjekte
>werden einfach wie variablen angelegt.
>Singleton a;

(bin auch kein C++ Programmierer)

beides (also mit und ohne New) hat aber vor/Nachteile
und ist NICHT das selbe..

siehe  die 2 Antworten hier:

http://stackoverflow.com/questions/6337294/creating-an-object-with-or-without-new

Oliver S. schrieb:
> Ohne die
> allereinfachsten Grundlagen einer Programmiersprache geht es nunmal
> nicht.

Aber ohne Nachtreten im Forum ginge es.

Oliver S. (oliverso)
>Nun denn, außer Klammern, Semikolons, und sonstigem syntaktisch
>erforderlichem Kleinkram fehlt dem Code oben mindestens eine ganz
>entscheidende Zeile. So, wie der da steht, funktioniert er nicht. Was
>soll man also daran erklären?

Im Gegensatz zu Dir schreibe ich aber den Code hier herein, damit ich 
und die anderen was lernen können. Anstatt dass Du nur Text absonderst, 
könntest Du Dir auch die Mühe machen, die Sache an Codebeispielen zu 
erläutern, die Deiner Meinung nach passen.
Am genauesten kann man erkennen was passiert, wenn man darstellt, was im 
Speicher passiert und das habe ich oben gemacht.