Springen naar inhoud

Uml: singleton


  • Log in om te kunnen reageren

#1

English

    English


  • >100 berichten
  • 126 berichten
  • Ervaren gebruiker

Geplaatst op 19 december 2010 - 17:09

http://zenit.senecac...ngleton_UML.png

Beste,

hierboven het standaard UML-diagram voor het patroon "singleton". De eerste methode van de klasse Singleton (- Singleton) betreft de constructor, die typerend in dit geval ofwel private ofwel protected staat gedefinieerd (in dit geval private). De reden hiervoor: andere klassen mogen de constructor niet zo maar aanroepen, aangezien er dan meerdere objecten kunnen worden aangemaakt van de klasse Singleton, wat nu juist niet de bedoeling is. Bedoeling = slechts 1 object aanmaken.

Onze prof Systeemontwerp stelde ons echter recent de vraag hoe je nu zou kunnen hetzelfde resultaat bekomen indien de constructor toch als publiek zou worden gedefinieerd. Hij gaf er zelf geen antwoord op en zei dat dit een mogelijk examenvraag zou kunnen zijn voor de "hogere punten". Een incentive als dat is, heb ik me aan het denken gezet, maar ik geraak er niet echt uit.

Volgens de assistent ben ik juist op weg wanneer ik vertrek vanuit de volgende standpunten:

* Een methode om een constructor te beschermen bestaat niet
* Er moet een soort tellermechanisme,dat bijhoudt hoeveel objecten van de klasse er zijn aangemaakt, worden geÔmplementeerd

Mijn ingeving
---------------

Structureel gezien is het erg simpel, de teller moet maar van twee zaken uitgaan:

IF teller = 0 THEN create object --> aanroepen constructor
IF teller = 1 THEN do not create object --> weigeren om constructor aan te roepen

Nu vermits het maar om een 0 of een 1 gaat (hoger zal de waarde van de teller toch nooit komen), vermoed ik dat met een boolean zal moeten gewerkt worden.

Mijn vraag naar jullie toe is echter, hoe implementeer ik dit? De constructor wordt aangeroepen, maar indien dit gebeurt moet die teller (een methode binnen een methode) ook worden aangeroepen. Ik mag toch niet het volgende schrijven:

+Singleton(+teller:boolean)

Een dergelijke constructie heb ik immers nog nooit gezien binnen object-oriŽntatie, aldus vermoed ik dat dit fout is.

Enige hulp is meer dan welkom! ;)

Alvast bedankt, English

Dit forum kan gratis blijven vanwege banners als deze. Door te registeren zal de onderstaande banner overigens verdwijnen.

#2

Jan van de Velde

    Jan van de Velde


  • >5k berichten
  • 44893 berichten
  • Moderator

Geplaatst op 20 december 2010 - 00:29

verplaatst naar Programmeren
ALS WIJ JE GEHOLPEN HEBBEN....
help ons dan eiwitten vouwen, en help mee ziekten als kanker en zo te bestrijden in de vrije tijd van je chip...
http://www.wetenscha...showtopic=59270

#3

317070

    317070


  • >5k berichten
  • 5567 berichten
  • Moderator

Geplaatst op 20 december 2010 - 00:54

Singletons ara Pure Evil! ;)

Maar behalve dat. (Ik ken helaas nog niets van UML)
Die teller kun je statisch maken in je klasse. Zodoende kan je constructor zelf kijken of hij zichzelf mag maken of niet. Indien hij zichzelf niet mag maken is de enige oplossing een Exception throwen. Een constructor kan zichzelf namelijk niet 'niet initialiseren'...

Maar het blijft heel lelijke code voor iets waarvan je normaal gezien een statische klasse (of een namespace) van maakt.
What it all comes down to, is that I haven't got it all figured out just yet
And I've got one hand in my pocket and the other one is giving the peace sign
-Alanis Morisette-

#4

English

    English


  • >100 berichten
  • 126 berichten
  • Ervaren gebruiker

Geplaatst op 20 december 2010 - 07:33

Ik had ook inderdaad wat research online gedaan naar concrete oplossingen voor dit probleem en zowel in C++ als in Java wordt vaak gebruik gemaakt van een statische constructor, vermits er dan geen visibility moet worden gedefinieerd. Jammer genoeg is dit nu niet toegelaten als oplossing voor dit probleem. We moeten er dus echt wel vanuit gaan dat de constructor een niet-statische methode is met een publieke visibiliteit.

Ik las online iets over een programmacode genaamd double locking, die desondanks ze niet thread-free is, toch wel soms wordt toegepast om op een eenvoudige manier dit op te lossen. De werking ervan sluit alleszins erg dicht aan bij hetgeen ik in gedachten had:

* indien de constructor mag worden uitgevoerd (==null), dan lockt het lockmechanisme zichzelf
* indien de constructor niet mag worden uitgevoerd (==one), dan lockt het lockmechanisme de constructor

Hoe zou je dit dan concreet implementeren in UML of in Javacode? Iemand? ;)

Alvast bedankt.

#5

EvilBro

    EvilBro


  • >5k berichten
  • 6703 berichten
  • VIP

Geplaatst op 20 december 2010 - 08:16

Ik las online iets over een programmacode genaamd double locking

Double-checked locking werkt meestal niet goed.

#6

English

    English


  • >100 berichten
  • 126 berichten
  • Ervaren gebruiker

Geplaatst op 20 december 2010 - 09:22

Wat stelt u dan voor? ;)
Ik ben echt wel nieuwsgierig naar een uniforme oplossing die niet impliceert dat de methode statisch moet worden gemaakt. Leuk om mee 'uit te pakken' (excuses voor het taalgebruik) op feestjes natuurlijk!

#7

317070

    317070


  • >5k berichten
  • 5567 berichten
  • Moderator

Geplaatst op 20 december 2010 - 11:55

Ik had ook inderdaad wat research online gedaan naar concrete oplossingen voor dit probleem en zowel in C++ als in Java wordt vaak gebruik gemaakt van een statische constructor, vermits er dan geen visibility moet worden gedefinieerd. Jammer genoeg is dit nu niet toegelaten als oplossing voor dit probleem. We moeten er dus echt wel vanuit gaan dat de constructor een niet-statische methode is met een publieke visibiliteit.

Awel, dit is een oplossing.
public class Singleton{
	private static volatile boolean cnt= false;
	public synchronized Singleton(){
		if(cnt){
			throw new Exception();
		}else{
			cnt = true;
		}
		//rest van constructor
	}
}
What it all comes down to, is that I haven't got it all figured out just yet
And I've got one hand in my pocket and the other one is giving the peace sign
-Alanis Morisette-

#8

EvilBro

    EvilBro


  • >5k berichten
  • 6703 berichten
  • VIP

Geplaatst op 20 december 2010 - 12:25

Wat stel je je precies voor bij een 'synchronized constructor'? (in Java is dit volgens mij niet eens mogelijk...)

#9

317070

    317070


  • >5k berichten
  • 5567 berichten
  • Moderator

Geplaatst op 20 december 2010 - 20:00

Wat stel je je precies voor bij een 'synchronized constructor'? (in Java is dit volgens mij niet eens mogelijk...)

Daar heb je een punt. Bij constructors staat die static er niet expliciet, vandaar de verwarring...
public class Singleton{
	private static volatile Boolean cnt= false;
	public Singleton(){
		synchronized(cnt){
			if(cnt){
				throw new Exception();
			}else{
				cnt = true;
			}
			//rest van constructor
		}
	}
}
What it all comes down to, is that I haven't got it all figured out just yet
And I've got one hand in my pocket and the other one is giving the peace sign
-Alanis Morisette-

#10

English

    English


  • >100 berichten
  • 126 berichten
  • Ervaren gebruiker

Geplaatst op 20 december 2010 - 20:25

De volledige code zou dan neerkomen op het volgende:

/*Implementation of a publicly-defined constructor in a Singleton class*/

public class Singleton {
public class Singleton{
private static volatile Boolean cnt= false;
public Singleton(){
synchronized(cnt){
if(cnt){
throw new Exception();
}else{
cnt = true;
}
static private Singleton _instance = null;
static public Singleton instance() {
if(null == _instance) {
_instance = new Singleton();
}
return _instance;
}
}
}
}
}


Juist? ;) Alvast bedankt voor de vele moeite!

#11

317070

    317070


  • >5k berichten
  • 5567 berichten
  • Moderator

Geplaatst op 20 december 2010 - 20:48

Juist? ;) Alvast bedankt voor de vele moeite!

Nog net niet helemaal. Als er nu extern de constructor wordt aangeroepen, en vervolgens ergens iets anders getInstance()?

Je moet in je constructor zelf de _instance instellen.
What it all comes down to, is that I haven't got it all figured out just yet
And I've got one hand in my pocket and the other one is giving the peace sign
-Alanis Morisette-

#12

English

    English


  • >100 berichten
  • 126 berichten
  • Ervaren gebruiker

Geplaatst op 21 december 2010 - 07:56

Dus in feite impliceert dit dat de _getInstance binnen de accolades van de constructor zich moet bevinden, niet? ;) Dit is mijn eerste semester object-oriŽntatie nog maar, programmeren hebben we in principe nog niet gezien (in het tweede semester programmeren we in java, nu zien we de kernconcepten en hoe dit vervat zit binnen UML, dus de implementatie ervan, daar ben ik nog niet erg sterk in)

#13

317070

    317070


  • >5k berichten
  • 5567 berichten
  • Moderator

Geplaatst op 22 december 2010 - 21:29

Dit is mijn eerste semester object-oriŽntatie nog maar, programmeren hebben we in principe nog niet gezien (in het tweede semester programmeren we in java, nu zien we de kernconcepten en hoe dit vervat zit binnen UML, dus de implementatie ervan, daar ben ik nog niet erg sterk in)

Holy shit, wie heeft dat systeem bedacht? Zoiets zou je maar aan moeten beginnen als je al een hoop programmeerervaring hebt, lijkt mij. Ik heb het toch zo gedaan...

Dus in feite impliceert dit dat de _getInstance binnen de accolades van de constructor zich moet bevinden, niet? ;)

Nee, zoiets kan niet. Je kan geen functie binnen een andere functie definiŽren in de meeste talen.

Waar ik aan dacht is dit, hoogstwaarschijnlijk is het dan wel niet waar de professor op doelde, lijkt mij. Deze code is ongelofelijk lelijk en ondoeltreffend. (But then again, singletons zijn lelijk).

Misschien toch maar eens vragen aan de prof of hij aan iets dergelijk dacht. ;)
/*Implementation of a publicly-defined constructor in a Singleton class*/

public class Singleton{
	private static volatile Boolean cnt= false;
	public Singleton(){
		synchronized(cnt){
			if(cnt){
				throw new Exception();
			}else{
				cnt = true;
			}
			_instance = this;
		}
	}
	
	static private Singleton _instance = null;

	static public Singleton instance() {
		if(null == _instance) {
			try{
				_instance = new Singleton();
			catch(Exception e){}
		}
		synchronized(cnt){
			return _instance;
		}
	}
}
What it all comes down to, is that I haven't got it all figured out just yet
And I've got one hand in my pocket and the other one is giving the peace sign
-Alanis Morisette-





0 gebruiker(s) lezen dit onderwerp

0 leden, 0 bezoekers, 0 anonieme gebruikers

Ook adverteren op onze website? Lees hier meer!

Gesponsorde vacatures

Vacatures