Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

Like this presentation? Why not share!

Stoop 432-singleton

on

  • 554 views

 

Statistics

Views

Total Views
554
Views on SlideShare
554
Embed Views
0

Actions

Likes
0
Downloads
6
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Stoop 432-singleton Stoop 432-singleton Presentation Transcript

  • Singleton
  • Singleton’s Intent
    • Ensure that a class has only
    • one instance, and provide a
    • global point of access to it
  • Problem / Solution
    • Problem : We want a class with a unique instance.
    • Solution :
    • Store the first time an instance is created and return it each time a new instance is requested.
  • Example
    • db := DBConnect default.
    • db2 := DBConnect default.
    • db2 == db2
    • > true
    • Yes we get only one instance
  • Example
    • Object subclass: #DBConnect
      • instanceVariableNames: ''
      • classVariableNames: ' UniqueInstance '
      • poolDictionaries: ''
      • category: 'MyDB'
  • Implementation
    • NetworkManager class>>new
    • self error: ‘should use uniqueInstance’
    • NetworkManager class>>uniqueInstance
      • UniqueInstance isNil
      • ifTrue: [ UniqueInstance := self basicNew initialize].
      • ^UniqueInstance
  • Implementation Issues
    • Singletons may be accessed via a global variable
      • Pharo 1.1
      • Smalltalk points to SmalltalkImage current
    • Global access is good to get shorter expression
      • Smalltalk vs SmalltalkImage current
    • But this should be more the exception than the rule
  • Global Variable or Class Method Access
    • Global Variable Access is dangerous: if we reassign Smalltalk we lose all references to the current SmalltalkImage
    • Class Method Access is better because it provides a single access point. This class is responsible for the singleton instance (creation, initialization,...).
  • Implementation Issues
    • Persistent Singleton : only one instance exists and its identity does not change
    • Transient Singleton : only one instance exists at any time, but that instance changes
    • Single Active Instance Singleton : a single instance is active at any point in time, but other dormant instances may also exist.
  • classVariable or class instance variable
    • classVariable (shared variable)
      • One singleton for a complete hierarchy
    • Class instance variable
      • One singleton per class
  • Access?
    • In Smalltalk we cannot prevent a client to send a message (protected in C++). To prevent additional creation we can redefine new/new:
    • DBConnect class>>new
        • self error: ‘Class ‘, self name, ‘ cannot create new instances’
  • Access using new: not good idea
    • DBConnect class>>new
    • ^self uniqueInstance
    • The intent (uniqueness) is not clear anymore!
    • new is normally used to return newly created instances.
    • Not intention revealing
  • new vs uniqueInstance
    • The difference between #new and #uniqueInstance is that #new potentially initializes a new instance, while #uniqueInstance only returns the unique instance (there is no initialization)
    • Do we want to communicate that the class has a singleton? new? defaultInstance? uniqueInstance?
  • Favor Instance Behavior
    • When a class should only have one instance, it is tempting to define all its behavior at the class level.
    • This is not optimal:
      • Class behavior represents behavior of classes: “Ordinary objects are used to model the real world. MetaObjects describe these ordinary objects”
    • Now yes this may be tedious to type
      • DBConnect current reconnect
      • instead of DBConnect reconnect
    • What’s happens if later on an object can have multiple instances? You have to change a lot of client code!
  • Time and not Scope
    • Singleton is about time not access
      • time : only one instance is available at the same time
      • access : can’t you add an instance to refer to the object?
    • Singleton for access are as bad as global variables
    • Often we can avoid singleton by passing/referring to the object instead of favoring a global access point
    • It is worth to have one extra instance variable that refers to the right object