Software Engineering Design Patterns Singleton Single instance of

Software Engineering Design Patterns

Singleton • Single instance of class • Constructor is private • static final Class instance constructed when application loads • or loaded only when need (lazy initialization) • Examples of usage – to access database so that all threads go through one control point – Font class keeps memory load low

Singleton Example in Java public class Dbase. Connector { private static final Dbase. Connector instance=new Dbase. Connector(); private Dbase. Connector() { // database construction code…. . } public static Dbase. Connector get. Instance() { return(instance); } }

Singleton Example (lazy initialization) public class Dbase. Connector { private static Dbase. Connector instance; private Dbase. Connector() { // database construction code…. . } public static Dbase. Connector synchronized get. Instance() { if (instance==null) { instance=new Dbase. Connector(); } return(instance); } }

Wrapper/Adapter classes • Problem – Different external technologies to connect to – Example for database connection • ODBC • JDBC (Microsoft) (Java standard) – Other examples • External Credit card payment • Network connection (Java and Microsoft) • Data structure libraries

Wrapper classes • Problem with coding directly – Code will end up messy – Hard to port – Hard to understand • Benefits of wrapping code – easier to swap modules (e. g. CC function) – easier to implement standard functions (e. g. accountancy, error logs)

Wrapper example (unwrapped code) String sql="select * from customers"; try { java. sql. Statement s=db. Connection. create. Statement(); int rows=s. execute. Update(sql); } catch (Exception e) { status=sql+" "+e. to. String(); };

Wrapped code public class SQLHelper { public void execute. SQL(String sql) { try { java. sql. Statement s=db. Connection. create. Statement(); int rows=s. execute. Update(sql); } catch (Exception e) { status=sql+" "+e. to. String(); }; } }

Adapter interface (top level) • Defines all common services and constants • ICard. Provider, IEmail. Provider • All methods are virtual (no body) • E. g. • take. Card. Payment(String cardno,

Abstract base • Contains common code that will be used by all providers • Card. Provider. Base implements ICard. Provider – Details validation – HTTP request code • Email. Provider. Base implements IEmail. Provider – Code to connect to standard SMTP server – Code to handle store, addresses, contents, attachements

Common functionality on base class • • Name of service Priority Enabled or not Cost of service Blacklists (email or CC card) Risk management (card payment) Audit trails and logging

Implementation • The actual providers need to implement the code to connect to particular service • e. g. • Metacharge. Card. Provider extends Card. Provider. Base • Gmail. Email. Provider extends Email. Provider. Base

Provider manager • This will be a class which creates instances of providers and handles the requests • Card payment – Might try more than 1 provider in turn until payment goes through • Email – Again, tries different providers, some providers might be on or offline at any time

Summary • Design patterns can help – code structure – code quality • Using design patterns – look at design patterns example code – adapt design patterns for your own code – reference design pattern texts when designing your system