Professional Documents
Culture Documents
Ingleton: How Is It Done?
Ingleton: How Is It Done?
Ingleton: How Is It Done?
SINGLETON
• Restricts the instantiation of a class to one object
• The instance created can be referentiated multiple times
• Provide global access to that instance
How is it done?
1. Declare all the constructors of the class to be private
2. Static method that returns a reference to the unique instance
PRO
• Central administration of a resource thanks to the unique instance
• Good control of the instance of a class (only once)
• Cannot duplicate instances & easy to implement (Lazy instantiation)
CONS
• Problems occurring in multi-threading with sync
• Can become a bottleneck and affect app's performance
Usage examples:
1. Unique DB connection
2. Unique file administration
3. Unique shared preferences administration
FACTORY
• Implementing a centralized mechanism to create transparent objects for the client
• Solution can be extended with new types of objects, without affecting existing ones
• Common interface for the objects
1. Simple Factory
• Most used in production because of the simplity
• Not specifically described, it was born while coding
2. Factory Method
PRO
• All the objects created have a common interface
• Objects created using factory method, not directly by constructors
• Can be created new objects belonging to the same family (common interface)
• Dependency Inversion principle is implemented
CONS
• Cannot be generated "new" objects
• Private constructors, classes closed to extension
3. Abstract Factory
PRO
• Detaches the instance generator from the client that uses them
• Objects created using factory method, not directly by constructors
• Can be created new objects belonging to the same family (common interface)
• Dependency Inversion principle is implemented
CONS
• High number of classes involved
• Difficult to implement
Usage examples:
1. Managing the creation of products from an online store
2. Managing the creation of different types of reports
3. Managing the creation of different pizza types
4. Factory – conclusion
• All of the Factory patterns promote loose coopling and are based on dependency
inversion
• Factory Method: based on inheritance – object creation realized by subclasses that
implement factory method; Has the purpose to delegate object creation to subclasses
• Abstract Factory: based on composition – object creation realized by methods published
by the interface; Has the purpose to create object families, independent from their
concrete implementation
BUILDER
• Aims to separate the construction of a complex object from its representation
• Client builds complex objects specifying just the type and value, without knowing internal
details
• Objects managed through the common interface
PRO
• Complex objects created independently of the component parts
• Different object representation created through a common interface
• Flexible object creation algorithm because you choose which parts to create
CONS
• You may miss attributes at creation
Software Testing and Quality 3
Assurance
Design Patterns
PROTOTYPE
• Generates long lasting and costly objects (time and memory)
• For efficiency, the solution recycles the object by cloning it (create new instance)
• Implemented through clone()
PRO
• Fast object creation thanks to cloning
• Avoiding explicitly calling the constructor
• Can be built a collection of prototypes in order to be used for new object create
CONS
• Be careful at shallow copy!
ADAPTER (WRAPPER)
• Utilization of different classes that do not share a common interface
• The classes do not modify, an interface is created in order to use the classes
• Calls to the class interface are masked by the adapter's interface
PRO
• Existing classes are not modified in order to be used in another context
• Adding just one intermediary layer
• New adapters can be easily defined for every context
CONS
• The adapter is based on multiple class derivation, not possible in Java, so it is
mandatory to use an interface
FAÇADE (WRAPPER)
• The classes do not modify, it is added just an intermediary layer (the facade)
• Useful when the framework is growing in complexity and is not possible its simplification
PRO
• The framework remains the same
• It is added just a layer that hides the complexity of the actual code
• Easily definable methods to simplify any situation
• Least Knowledge principle
CONS
• The number of wrapper classes is increased
• The code complexity is increasing by hiding methods
• Decreased performance of the app
DECORATOR (WRAPPER)
• Static Extension (decoration) / at run-time of a functionality / state of some objects
• The object can be extended through the appliance of numerous decorators
• The extended class cannot be modified
PRO
• The extension of an object's functionalities is made dynamically, @run-time
• It is transparent for the user because the class inherits the object's interface
• Decoration is made on multiple levels, but transparent for the user
• No maximum number of decorations
CONS
• A decorator is a wrapper over the initial object, it is not identical with the object
• Excessive use generates loads of same looking objects that behave in a different
way, the code becoming hard to understand
• Needs analysis before use, because sometimes, Strategy is more indicated
COMPOSITE
• Solution has loads of classes hierarchically arranged that need unitary treatment
• There are build tree structures where intermediary and leaf nodes are treated unitary
PRO
• The framework remains the same
• Allows easy management of some class hierarchies
• Adding new components that respect the common interface do not raise extra
problems
CONS
• N/A
FLYWEIGHT
• Minimizes memory usage by sharing as much data as possible with other similar objects
• An example would be a text editor
PRO
• The memory occupied by objects is reduced by sharing their state between objects
of the same type
• For the proper management of Flyweight objects between clients, they have to be
immutable
CONS
• The classes have to be analyzed in order to determine what can be internalized
• It is effective for solutions with large number of objects
• The level of reduced memory depends on how many Flyweight object categories
are
PROXY
• Interconnecting different APIs on the same machine or in network
• Defining an interface between different frameworks
Proxy types:
1. Virtual Proxies: manages creation and initialization of costly objects. They can be created
just in need, or they share a single instance between multiple clients
2. Remote Proxies: they assure a local virtual instance for a remote object – Java RMI
3. Protection Proxies: they control the access at methods of an object or at some objects
4. Smart References: they administrate references to an object
PRO
• N/A
CONS
• N/A