1. Software Engineering Design Patterns

2. 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

3. Singleton Example in Java public class DbaseConnector { private static final DbaseConnector instance=new DbaseConnector(); private DbaseConnector() { // database construction code….. } public static DbaseConnector getInstance() { return(instance); }

4. Singleton Example (lazy initialization) public class DbaseConnector { private static DbaseConnector instance; private DbaseConnector() { // database construction code….. } public static DbaseConnector synchronized getInstance() { if (instance==null) { instance=new DbaseConnector(); } return(instance); }

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

6. 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)

7. Wrapper example (unwrapped code) String sql="select * from customers"; try { java.sql.Statement s=dbConnection.createStatement(); int rows=s.executeUpdate(sql); } catch (Exception e) { status=sql+" "+e.toString(); };

8. Wrapped code public class SQLHelper { public void executeSQL(String sql) { try { java.sql.Statement s=dbConnection.createStatement(); int rows=s.executeUpdate(sql); } catch (Exception e) { status=sql+" "+e.toString(); }; }

9. Adapter interface (top level) Defines all common services and constants ICardProvider, IEmailProvider All methods are virtual (no body) E.g. takeCardPayment(String cardno,

10. Abstract base Contains common code that will be used by all providers CardProviderBase implements ICardProvider –Details validation –HTTP request code EmailProviderBase implements IEmailProvider –Code to connect to standard SMTP server –Code to handle store, addresses, contents, attachements

11. 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

12. Implementation The actual providers need to implement the code to connect to particular service e.g. MetachargeCardProvider extends CardProviderBase GmailEmailProvider extends EmailProviderBase

13. 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

14. 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