0
Lecture 04
Base Patterns
Agenda
 Base Patterns
– Gateway, Mapper, Layerd Supertype, Separated
Interface, Registry, Value Object, Plugin, Service
S...
Reading
 Fowler 18
Gateway (466)
An object that encapsulates access to an external
system or resource
 Wrap external APIs into an interface
...
Gateway (466)
 How It Works
– Create a simple API and use it access the external
API through a Gateway
– All access is ea...
Gateway (466)
 When to Use It
– Gateway is useful when accessing external service
– Can be applied with Service Stub (504...
Mapper (473)
An object that sets up communiction between
two independent objects
 Create communication between two system...
Mapper (473)
 How it Works
– A Mapper is an insulating layer between subsystems
– It controls the details of communicatio...
Layer Supertype (475)
A type that acts as the supertype
for all types in its layer
 Super class that contains common func...
Layer Supertype (475)
 When to use it
– When you have common features from all objects in a
layer.
 Example
– Domain obj...
Example: Drawing system
 Shape class revisited
– All objects in the drawing layer must have an origin (x
and y) and imple...
Separated Interface (476)
Defines an interface in a separate
package from its implementation
 Decouples parts of a system...
Separated Interface
 Layered System
– Domain layer depends on Data Source layer
– Data Source layer cannot access Domain ...
Separated Interface (476)
 Implementation is placed in a separate package
Developers of the client
package are responsibl...
Separated Interface (476)
 Placing the Separated
Interfaced in a
third package
 When to use it
– When you need to break ...
Separated Interface (476)
Separated Interface (476)
 Instantiating the implementation
– User of the interface should not know the
implementation
 ...
Separated Interface (476)
public interface FeedHandler
{
public void processObject (FeedEntry entry);
}
public class Reade...
Registry (480)
A well-known object that other objects can use
to find common objects and services
 A registry is a global...
Singleton Registry (480)
 Only one instance running
 When to Use It
– As a last resort
public class Registry
{
private s...
Value Object (486)
A small simple object, like money or date
range, whose equality isn’t based on identity
 Small and eas...
Value Object (486)
 Examples
– Date, Money
class Money...
private long amount;
private Currency currency;
public Money(do...
Value Object Example: Date
GregorianCalendar cal = new GregorianCalendar();
cal.set(1865, Calendar.APRIL, 14);
Date d1 = c...
Plugin (499)
Links classes during configuration
rather than compilation
 Use plugin to provide specific implantation
– Pl...
Plugin (499)
caller a plugin factory a plugin configuration
getPlugin
lookupPluginByType
new
a plugin
 A caller obtains a...
Plugin (499)
 ReaderClient uses ReaderFactory to get an
interface to FeedReader
 reader.properties define the name of th...
Plugin (499)
public ReaderClient()
{
FeedReader reader = ReaderFactory.getFeedReader();
...
} public class ReaderFactory
{...
Service Stub (504)
Removes dependence upon problematic
services during testing
 Enterprise systems often need to access
e...
Service Stub (504)
 Service stub provides implementation for
development and testing purposes
– Runs locally and in-memor...
Service Stub Examples
public class ReaderStub extends AbstractFeedReader
{
public void read(String url)
{
feedHandler.proc...
Record Set (508)
An in-memory representation of tabular data
 Allows you to access database data from other
objects
– Scr...
Record Set (508)
 How it Works
– Record set are usually provide by database classes
(JDBC or ADO.NET)
– Look exactly like...
Summary
 Base Patterns
– Gateway, Mapper, Layerd Supertype, Separated
Interface, Registry, Value Object, Plugin, Service
...
QUIZ
Question #1
 You use this patterns when you need to break
a dependency between two parts of the
system
A) Registry
B) Gat...
Question #2
 Intent of a pattern is this: An object that sets
up communication between two objects
A) Gateway
B) Mapper
C...
Question #3
 Sketch of a pattern is his
A) Plugin
B) Mapper
C) Registry
D) Service Stub
Question #4
 Use this pattern when you find that dependence
on a particular service is hindering your
development and tes...
Using Design Patterns
Using Design Patterns
 Normally we don’t start with patterns
– We start with problems to solve
– From Problem to Pattern
...
From Problem to Pattern
 How do I reuse common functionality of my
objects?
–Layered Supertype
 How do I access an exter...
From Problem to Pattern
 How do I test my client code using a service that
I don’t have access to?
–Service Stub
 How do...
Refactoring
 Design, redesign, refactor
– Make the design as complete as possible
– But be prepared to change design as y...
Refactoring
 Refactoring is the process of improving design in
little steps at a time
– Minimizes risks – calculated
– Ch...
The Danger
 Code Dept
“I’ll fix it later”
The four most dangerous and expensive words in
programming
MailService
Mail Service
 We are building an web application
– One important service is sending messages in email
– We need to access...
Mail Service
 We decide to use JavaMail API
– Problem is that this API is pretty low-level and
complicated
– Lots of “noi...
Mail Service Gateway
 We build a simple gateway to handle mail
– Domain developers don’t worry about the service
– We can...
Gateway (466)
An object that encapsulates access to an external
system or resource
 Wrap external APIs into an interface
...
MailSender (1/2)
 Class that sends the mail
– Method send that takes care of sending the mail
public class MailSender
{
p...
MailSender (2/2)
Properties props = System.getProperties();
props.put("mail.smtp.host", smtpServer);
Session session = Ses...
MailSender
 Name the problem with his class
public class MailSender {
public void send(String from, String to, String sub...
MailSender
 Problem
– Many parameters instead of an object
– Mail server is hard-coded
– Exception handling is bad
public...
MailService
 Interface for the domain developers
– Program-to-interfaces Principle
– So let MailSender implement this int...
Testing
 Testing MailService and MainSender is easy
public class TestMail
{
public static void main(String[] args)
{
Mail...
Testing
TestMail: sending mail.
Done.
NOTE: mail.ru.is is not good for testing!
Testing
 What is the problem with clients like this?
public class TestMail
{
public static void main(String[] args)
{
Mai...
Improvements
 Problem
– MailSender implementation class is exposed to the
domain layer
 Solution
– Use the Plugin Patter...
Plugin (499)
Links classes during configuration
rather than compilation
 Use plugin to provide specific implantation
– Pl...
Factory with a Plugin
 Create a MailFactory class
– Loads mail.properties file
– Creates the class specified in the prope...
Improvements
 Problem
– Can we make the loading of properties and class more
generic?
– Other factories might need this f...
Layer Supertype (475)
A type that acts as the supertype
for all types in its layer
 Super class that contains common func...
Layer Supertype (475)
A type that acts as the supertype
for all types in its layer
 Super class that contains common func...
Plugin Pattern
Factory
 Has two methods
– loadProperties
– loadClass
 Exception handling
– Create a new exception class that we will us...
FactoryException
 Extends Exception
– Checked exception
– Callers must catch this exception or explicitly throw it
public...
Factory
public class Factory {
Logger logger = Logger.getLogger(LogInfo.LOG_NAME);
protected Properties loadProperties(Str...
Testing Fails
 Exception is thrown and message is logged
2.9.2007 16:49:34 is.ru.honn.rubook.factory.Factory loadClass
SE...
Testing Fails
 Problem
– MailService implementation classes have to
handle FactoryException or pass it on
– Do we want cl...
MailFactory
public class MailFactory extends Factory
{
public MailService getMailService()
{
MailService service;
try
{
se...
MailServiceException
 Extends RuntimeException
– Unchecked exception
– Callers decide if they want to catch it
public cla...
Testing
 Using the MailFactory class
– We can catch the MailServiceException or ignore it
– Notice we have not only abstr...
Improvements
 Problem
– Exception handling in our original MailSender is bad
 Solution
– Use the MailServiceException
pu...
Improvements
 Problem
– What if we don’t have access to the SMTP server
at this time?
 Solution
– Use a Service Stub
– C...
Service Stub (504)
Removes dependence upon problematic
services during testing
 Enterprise systems often need to access
e...
MailServiceStub
public class MailServiceStub implements MailService
{
Logger logger = Logger.getLogger(LogInfo.LOG_NAME);
...
Improvements
 Problem
– What if we need to add new parameter?
 Solution
– Use an object to group parameters
– Easy to ch...
MailMessage
 Typical Data Transfer Object
public class MailMessage {
private String from;
private String to;
private Stri...
Improvements
 Problem
– The mail server in MailSender is still hardcoded
 Solution
– Place in the configuration file
– L...
Injecting the Mail Server Name
New MailFactoy
 getMailService injects the name into the service
public class MailFactory extends Factory
{
public MailSe...
Improvements
 Problem
– loadProperties loads the file each time used
 Solution
– Load once then use
public class Factory...
Improvements
 Problem
– All mail server implementations must store server name
and set function
– Common functionality in...
AbstractMailService
 Implements MailService
– Provides handling of the mail server property
public abstract class Abstrac...
MailSender
 Extends AbstractMailService
– Does not have to implement the MailServer interface
– Can use the getMailServer...
Summary
 Base Patterns
• Gateway, Mapper, Layerd Supertype, Separated Interface, Registry,
Value Object, Plugin, Service ...
L04 base patterns
Upcoming SlideShare
Loading in...5
×

L04 base patterns

306

Published on

In this lecture we look at the patterns in chapter 18 in the textbook (Patterns of Enterprise Application Architecture). The lecture is in two parts. First we go through each of the patterns and explain each.

Then in the second part we look at a problem we have to solve and try to get the patterns to show themselves at the time they are needed.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
306
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
20
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "L04 base patterns"

  1. 1. Lecture 04 Base Patterns
  2. 2. Agenda  Base Patterns – Gateway, Mapper, Layerd Supertype, Separated Interface, Registry, Value Object, Plugin, Service Stub, Record Set  From Problem to Patterns – Using design patterns
  3. 3. Reading  Fowler 18
  4. 4. Gateway (466) An object that encapsulates access to an external system or resource  Wrap external APIs into an interface – API is usually for accessing some external resource • Examples: JDBC, JDom, financial software
  5. 5. Gateway (466)  How It Works – Create a simple API and use it access the external API through a Gateway – All access is easily defined – Change in the resource does not require changes in the client software – Gateways should be simple – complex logic should not be in the clients of the Gateway – Gateways can be generated
  6. 6. Gateway (466)  When to Use It – Gateway is useful when accessing external service – Can be applied with Service Stub (504) – Clear benefit is that is makes it easy to swap out one kind of resource for another
  7. 7. Mapper (473) An object that sets up communiction between two independent objects  Create communication between two systems but you still need to make them independent
  8. 8. Mapper (473)  How it Works – A Mapper is an insulating layer between subsystems – It controls the details of communication between them without either subsystem being aware of it – Mappers are fairly easy as they are well-defined – The tricky part is what system invokes them – third party system or make the Mapper an Observer  When to Use it – When you want to decouple different parts of a system
  9. 9. Layer Supertype (475) A type that acts as the supertype for all types in its layer  Super class that contains common functionality in a layer  How it works – Use this pattern when you have common features from all objects in a layer
  10. 10. Layer Supertype (475)  When to use it – When you have common features from all objects in a layer.  Example – Domain objects can have a common superclass for ID handling class DomainObject... private Long ID; public Long getID() { return ID; } public void setID(Long ID) { this.ID = ID; } public DomainObject(Long ID) { this.ID = ID; }
  11. 11. Example: Drawing system  Shape class revisited – All objects in the drawing layer must have an origin (x and y) and implement Drawable public abstract class Shape implements Drawable { protected int x,y; }
  12. 12. Separated Interface (476) Defines an interface in a separate package from its implementation  Decouples parts of a system – Controls the dependencies between packages – Implementation can easily be changed  How it works – Interface and implementation is placed in separate packages – Client uses the interface – Implementation can be determined at configuration time
  13. 13. Separated Interface  Layered System – Domain layer depends on Data Source layer – Data Source layer cannot access Domain layer Data Source Layer Domain Layer JDBC Code Interface RowCallBackHandler processRow(ResultSet rs) Concreate class RowCallBackHandler processRow(ResultSet rs) implements Code reading SQL Execution calls Separated interface
  14. 14. Separated Interface (476)  Implementation is placed in a separate package Developers of the client package are responsible for the interface
  15. 15. Separated Interface (476)  Placing the Separated Interfaced in a third package  When to use it – When you need to break a dependency between two parts of a system
  16. 16. Separated Interface (476)
  17. 17. Separated Interface (476)  Instantiating the implementation – User of the interface should not know the implementation  Solutions – Use a Factory and Plugin method – Use Dependency Injection
  18. 18. Separated Interface (476) public interface FeedHandler { public void processObject (FeedEntry entry); } public class ReaderClient implements FeedHandler { ... public ReaderClient() { FeedReader reader = ReaderFactory.getFeedReader(); reader.setFeedHandler(this); reader.read("http://rss.news.yahoo.com/rss/tech"); } public void processObject(FeedEntry entry) { System.out.println(entry); } } Callback
  19. 19. Registry (480) A well-known object that other objects can use to find common objects and services  A registry is a global object  How It Works – Object that can easily be accessed at any time – Only one object available at any time – Provides services or information – Can have different scopes – Usually not mutable data – Example: System Settings, Loggers
  20. 20. Singleton Registry (480)  Only one instance running  When to Use It – As a last resort public class Registry { private static Registry soleInstance = new Registry(); public static Registry getInstance() { return soleInstance; } private Registry() { } ... } Registry registry = Registry.getInstance(); //registry = new Registry (); Does not work
  21. 21. Value Object (486) A small simple object, like money or date range, whose equality isn’t based on identity  Small and easily created objects that hold and represent some data  How it works – Not based on identity – Equality is based on comparing values of the object – Can be immutable (example is the Date class)  When to use it – When you’re basing equality on something other than identify
  22. 22. Value Object (486)  Examples – Date, Money class Money... private long amount; private Currency currency; public Money(double amount, Currency currency) { this.currency = currency; this.amount = Math.round(amount * centFactor()); } ...
  23. 23. Value Object Example: Date GregorianCalendar cal = new GregorianCalendar(); cal.set(1865, Calendar.APRIL, 14); Date d1 = cal.getTime(); cal.set(1963, Calendar.NOVEMBER, 22); Date d2 = cal.getTime(); System.out.println(d1.equals(d2)); cal.set(1756, Calendar.JANUARY, 27); Date d3 = cal.getTime(); Date d4 = cal.getTime(); System.out.println(d3.equals(d4)); false true
  24. 24. Plugin (499) Links classes during configuration rather than compilation  Use plugin to provide specific implantation – Plugins implement specific interface use by the client application code – Decision at configuration time or run time – Use factory to load in the plugin – For example: on plugin for test, another for production
  25. 25. Plugin (499) caller a plugin factory a plugin configuration getPlugin lookupPluginByType new a plugin  A caller obtains a Plugin implementation of a separated interface  When to Use It – Use plugin when you have behavior that requires different implementations based on runtime environment
  26. 26. Plugin (499)  ReaderClient uses ReaderFactory to get an interface to FeedReader  reader.properties define the name of the actual implementation class ReaderClient ReaderFactory reader.properties getFeedReader props.getProperty("reader") new FeedReader
  27. 27. Plugin (499) public ReaderClient() { FeedReader reader = ReaderFactory.getFeedReader(); ... } public class ReaderFactory { public static FeedReader getFeedReader() { ... try { props.load(new FileInputStream(new File("reader.properties"))); instanceClass = Class.forName(props.getProperty("reader")); reader = (FeedReader)instanceClass.newInstance(); } ... return reader; } } reader=RssFeedReader
  28. 28. Service Stub (504) Removes dependence upon problematic services during testing  Enterprise systems often need to access external system – Can be out of developers control
  29. 29. Service Stub (504)  Service stub provides implementation for development and testing purposes – Runs locally and in-memory – Implements the same interface of the gateway used to access the real service  When to Use It – Service stub is useful when dependence on a particular service is hindering development or testing – Called “Mock Object” in the extreme programming world
  30. 30. Service Stub Examples public class ReaderStub extends AbstractFeedReader { public void read(String url) { feedHandler.processEntry(new FeedEntry("title1", "Bla bla bla")); feedHandler.processEntry(new FeedEntry("title2", "Bla bla bla")); feedHandler.processEntry(new FeedEntry("title3", "Bla bla bla")); } } title1 Bla bla bla title2 Bla bla bla title3 Bla bla bla reader=ReaderStub reader.properties
  31. 31. Record Set (508) An in-memory representation of tabular data  Allows you to access database data from other objects – Scroll through a list of data
  32. 32. Record Set (508)  How it Works – Record set are usually provide by database classes (JDBC or ADO.NET) – Look exactly like the results of a database query – Provides abstraction from the database code  When to Use It – When you need a common way to manipulate data from a relational database
  33. 33. Summary  Base Patterns – Gateway, Mapper, Layerd Supertype, Separated Interface, Registry, Value Object, Plugin, Service Stub, Record Set  Next: From Problem to Patterns – Using design patterns
  34. 34. QUIZ
  35. 35. Question #1  You use this patterns when you need to break a dependency between two parts of the system A) Registry B) Gateway C) Separated Interface D) Plugin
  36. 36. Question #2  Intent of a pattern is this: An object that sets up communication between two objects A) Gateway B) Mapper C) Registry D) Value Object
  37. 37. Question #3  Sketch of a pattern is his A) Plugin B) Mapper C) Registry D) Service Stub
  38. 38. Question #4  Use this pattern when you find that dependence on a particular service is hindering your development and testing A) Mapper B) Record Set C) Service Stub D) Gateway
  39. 39. Using Design Patterns
  40. 40. Using Design Patterns  Normally we don’t start with patterns – We start with problems to solve – From Problem to Pattern  Must have clear objectives for the design – The patterns will come as they are needed  Establish Design Principles – This applies to your application  Remember the separation of concern
  41. 41. From Problem to Pattern  How do I reuse common functionality of my objects? –Layered Supertype  How do I access an external service without becoming too dependant on it? –Gateway  How do I avoid creating unwanted dependencies? –Separated Interface
  42. 42. From Problem to Pattern  How do I test my client code using a service that I don’t have access to? –Service Stub  How do I link to my implementation class using configuration –Plugin  How can I keep common object available within the application –Registry
  43. 43. Refactoring  Design, redesign, refactor – Make the design as complete as possible – But be prepared to change design as you code – Unit tests become very important  Code Smell – Think of your code as a baby: “If it smells, change it!”
  44. 44. Refactoring  Refactoring is the process of improving design in little steps at a time – Minimizes risks – calculated – Changes are controlled – Code can improve – Less likely to smell
  45. 45. The Danger  Code Dept “I’ll fix it later” The four most dangerous and expensive words in programming
  46. 46. MailService
  47. 47. Mail Service  We are building an web application – One important service is sending messages in email – We need to access the e-mail service
  48. 48. Mail Service  We decide to use JavaMail API – Problem is that this API is pretty low-level and complicated – Lots of “noise” – not good to have the domain developers worry about that What Design Pattern can we use here?
  49. 49. Mail Service Gateway  We build a simple gateway to handle mail – Domain developers don’t worry about the service – We can easily change to a different mail API
  50. 50. Gateway (466) An object that encapsulates access to an external system or resource  Wrap external APIs into an interface – API is usually for accessing some external resource • Examples: JDBC, JDom, financial software
  51. 51. MailSender (1/2)  Class that sends the mail – Method send that takes care of sending the mail public class MailSender { public void send(String from, String to, String subject, String body) { String smtpServer = "mail.ru.is"; try {
  52. 52. MailSender (2/2) Properties props = System.getProperties(); props.put("mail.smtp.host", smtpServer); Session session = Session.getDefaultInstance(props, null); Message msg = new MimeMessage(session); msg.setFrom(new InternetAddress(from)); msg.setRecipients(Message.RecipientType.TO, InternetAddress.parse(to, false)); msg.setSubject(subject); msg.setText(body); msg.setSentDate(new Date()); Transport.send(msg); } catch (Exception ex) { ex.printStackTrace(); } } }
  53. 53. MailSender  Name the problem with his class public class MailSender { public void send(String from, String to, String subject, String body) { String smtpServer = "mail.ru.is"; try { Properties props = System.getProperties(); props.put("mail.smtp.host", smtpServer); Session session = Session.getDefaultInstance(props, null); Message msg = new MimeMessage(session); msg.setFrom(new InternetAddress(from)); msg.setRecipients(Message.RecipientType.TO,InternetAddress.parse(to, false)); msg.setSubject(subject); msg.setText(body); msg.setSentDate(new Date()); Transport.send(msg); } catch (Exception ex) { ex.printStackTrace(); } } }
  54. 54. MailSender  Problem – Many parameters instead of an object – Mail server is hard-coded – Exception handling is bad public void send(String from, String to, String subject, String body) { String smtpServer = ”smtp.ru.is"; try { ... } catch (Exception ex) { ex.printStackTrace(); } } }
  55. 55. MailService  Interface for the domain developers – Program-to-interfaces Principle – So let MailSender implement this interface public interface MailService { public void send(String from, String to, String subject, String body); } public class MailSender implements MailService { public void send(String from, String to, String subject, String body) { ...
  56. 56. Testing  Testing MailService and MainSender is easy public class TestMail { public static void main(String[] args) { MailService mail = new MailSender(); mail.send("andri@ru.is", // from "andri@ru.is", // to "Hallo", // subject "So does this stuff work"); // body } }
  57. 57. Testing TestMail: sending mail. Done. NOTE: mail.ru.is is not good for testing!
  58. 58. Testing  What is the problem with clients like this? public class TestMail { public static void main(String[] args) { MailService mail = new MailSender(); mail.send("andri@ru.is", // from "andri@ru.is", // to "Hallo", // subject "So does this stuff work"); // body } }
  59. 59. Improvements  Problem – MailSender implementation class is exposed to the domain layer  Solution – Use the Plugin Pattern – Create a factory that will read a configuration file and load the mail implementation class – Client will use the MailService interface
  60. 60. Plugin (499) Links classes during configuration rather than compilation  Use plugin to provide specific implantation – Plugins implement specific interface use by the client application code – Decision at configuration time or run time – Use factory to load in the plugin • For example: one plugin for test, another for production
  61. 61. Factory with a Plugin  Create a MailFactory class – Loads mail.properties file – Creates the class specified in the properties file and returns interface MailService – Clients use MailService and are not exposed to particular implementation – It’s easy to change the properties file
  62. 62. Improvements  Problem – Can we make the loading of properties and class more generic? – Other factories might need this functionality also  Solution: – Create a Layered Supertype – MailFactory extends Factory
  63. 63. Layer Supertype (475) A type that acts as the supertype for all types in its layer  Super class that contains common functionality in a layer  How it works – Use this pattern when you have common features from all objects in a layer
  64. 64. Layer Supertype (475) A type that acts as the supertype for all types in its layer  Super class that contains common functionality in a layer  How it works – Use this pattern when you have common features from all objects in a layer
  65. 65. Plugin Pattern
  66. 66. Factory  Has two methods – loadProperties – loadClass  Exception handling – Create a new exception class that we will use – FactoyException – Log the error
  67. 67. FactoryException  Extends Exception – Checked exception – Callers must catch this exception or explicitly throw it public class FactoryException extends Exception { public FactoryException(String message) { super(message); } public FactoryException(String message, Throwable cause) { super(message, cause); } }
  68. 68. Factory public class Factory { Logger logger = Logger.getLogger(LogInfo.LOG_NAME); protected Properties loadProperties(String filename) throws FactoryException { Properties props = new Properties(); try { props.load(new FileInputStream(new File(filename))); } catch (FileNotFoundException fnfex) { String msg = "Factoy: File '" + filename + "' not found."; logger.severe(msg); throw new FactoryException(msg, fnfex); } ... return props; }
  69. 69. Testing Fails  Exception is thrown and message is logged 2.9.2007 16:49:34 is.ru.honn.rubook.factory.Factory loadClass SEVERE: Factoy: Class 'is.ru.honn.rubook.mail.MailServiceStubx' not found.
  70. 70. Testing Fails  Problem – MailService implementation classes have to handle FactoryException or pass it on – Do we want clients to worry about some factory?  Solution – One solution is to catch FactoryException and throw unchecked MailService exception
  71. 71. MailFactory public class MailFactory extends Factory { public MailService getMailService() { MailService service; try { service = (MailService)loadClass( loadProperties("mail.properties"). getProperty("mail.service.class")); } catch(FactoryException fex) { throw new MailServiceException ("Unable to send e-mail", fex); } return service; } }
  72. 72. MailServiceException  Extends RuntimeException – Unchecked exception – Callers decide if they want to catch it public class MailServiceException extends RuntimeException { public MailServiceException(String message) { super(message); } public MailServiceException(String message, Throwable cause) { super(message, cause); } }
  73. 73. Testing  Using the MailFactory class – We can catch the MailServiceException or ignore it – Notice we have not only abstracted the Mail API but also the exception handling public class TestMail { public static void main(String[] args) { MailFactory mf = new MailFactory(); MailService mail = mf.getMailService(); mail.send("andri@ru.is", "andri@ru.is", "Hello", "Hello"); } }
  74. 74. Improvements  Problem – Exception handling in our original MailSender is bad  Solution – Use the MailServiceException public void send(MailMessage message) { try { ... } catch (Exception ex) { String msg = "Sending mail failed: " + ex.getMessage(); logger.severe(msg); throw new MailServiceException(msg, ex); } SEVERE: Sending mail failed: Unknown SMTP host: mail.ru.is
  75. 75. Improvements  Problem – What if we don’t have access to the SMTP server at this time?  Solution – Use a Service Stub – Create the class MailServiceStub that will simply log out the mail sent – Could also write in file
  76. 76. Service Stub (504) Removes dependence upon problematic services during testing  Enterprise systems often need to access external system – Can be out of developers control
  77. 77. MailServiceStub public class MailServiceStub implements MailService { Logger logger = Logger.getLogger(LogInfo.LOG_NAME); public void send(String from, String to, String subject, String body) { logger.info("Sending mail from '" + from + "' to '" + to + "' Subject: '" + subject); } } 2.9.2007 16:36:08 is.ru.honn.rubook.mail.MailServiceStub send INFO: Sending mail from 'andri@ru.is' to 'andri@ru.is' Subject: 'Hello mail.service.class=is.ru.honn.rubook.mail.MailServiceStub mail.properties
  78. 78. Improvements  Problem – What if we need to add new parameter?  Solution – Use an object to group parameters – Easy to change without changing the interface public interface MailService { public void send(String from, String to, String subject, String body); } public interface MailService { public void send(MailMessage message); }
  79. 79. MailMessage  Typical Data Transfer Object public class MailMessage { private String from; private String to; private String subject; private String body; public MailMessage(String from, String to, String subject, String body) { this.from = from; this.to = to; this.subject = subject; this.body = body; } public String getFrom() { return from; } public void setFrom(String from) { this.from = from; } ...
  80. 80. Improvements  Problem – The mail server in MailSender is still hardcoded  Solution – Place in the configuration file – Let the factory inject the name into the Mail Service public interface MailService { public void setMailServer(String mailServer); public void send(MailMessage message); }
  81. 81. Injecting the Mail Server Name
  82. 82. New MailFactoy  getMailService injects the name into the service public class MailFactory extends Factory { public MailService getMailService() { ... loadProperties("mail.properties"); service = (MailService)loadClass(getProperties(). getProperty("mail.service.class")); service.setMailServer(getProperties(). getProperty("mail.server")); // injection return service; } } mail.service.class=is.ru.honn.rubook.mail.MailSender mail.server=mail.ru.is
  83. 83. Improvements  Problem – loadProperties loads the file each time used  Solution – Load once then use public class Factory { private Properties properties = new Properties(); protected Properties loadProperties(String filename) throws FactoryException { ... return properties; } public Properties getProperties() { return properties; } ...
  84. 84. Improvements  Problem – All mail server implementations must store server name and set function – Common functionality in multiple classes  Solution – Create a Layered Supertype – Take care of the common functionality – Make the send method abstract
  85. 85. AbstractMailService  Implements MailService – Provides handling of the mail server property public abstract class AbstractMailService implements MailService { protected String mailServer; // this is used by the factory to inject public void setMailServer(String mailServer) { this.mailServer = mailServer; } public String getMailServer() { return mailServer; } }
  86. 86. MailSender  Extends AbstractMailService – Does not have to implement the MailServer interface – Can use the getMailServer method public class MailSender extends AbstractMailService { public void send(MailMessage message) { try { Properties props = System.getProperties(); props.put("mail.smtp.host", getMailServer()); ...
  87. 87. Summary  Base Patterns • Gateway, Mapper, Layerd Supertype, Separated Interface, Registry, Value Object, Plugin, Service Stub, Record Set  We start with problems to solve – Then we find the patterns to use – Must have clear objectives for the design  Beware of code smell  Refactoring is the process of improving design in little steps at a time  Example case study – Mail service with a configurable factory
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×