CS410J: Advanced Java Programming

Transcription

1 CS410J: Advanced Java Programming The Dependency Injection design pattern decouples dependent objects so that they may be configured and tested independently. Google Guice manages dependencies among objects and handles the complexity of wiring together complex object relationships. Dependency Injection The Dependency Injection design pattern Testing with mock objects using Mockito Managing dependencies with Google Guice Copyright c by David M. Whitlock. Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and full citation on the first page. To copy otherwise, to republish, to post on servers, or to redistribute to lists, requires prior specific permission and/or fee. Request permission to publish from whitlock@cs.pdx.edu. Last updated May 7,

2 Dependencies Among Objects Consider the below set of dependent objects BookInventory remove(book) add(book) instock(book) : int BookStore purchase(list<book>, CreditCard) : double refund(list<book> CreditCard) : double CreditCardService debit(creditcard, dollars : int, cents : int) credit(creditcard, dolars : int, cents : int) BookDatabase directory : File filename : String FirstBankOfPortlandStateServlet REST FirstBankOfPSU serverhost : String serverport : int A BookStore requires a BookInventory and a CreditCardService to get its work done We ve already extracted interfaces to allow us to abstract out the behavior that we need We want to be able to replace the implementations of BookInventory and CreditCardService without affecting the code in BookStore 2

3 How can we implement BookStore? package edu.pdx.cs410j.di; import java.io.file; import java.util.list; public class BookStore { private final BookInventory inventory; private final CreditCardService cardservice; public BookStore() { String tmpdir = System.getProperty( "java.io.tmpdir" ); File directory = new File( tmpdir ); this.inventory = new BookDatabase( directory, "books.txt" ); this.cardservice = new FirstBankOfPSU( "localhost", 8080 ); When the BookStore is created, it also creates its dependencies Dependencies are stored in final fields because they only need to be created once 3

4 How can we implement BookStore? public double purchase( List<Book> books, CreditCard card) { double total = 0.0d; for (Book book : books) { inventory.remove(book); total += book.getprice(); CreditTransactionCode code = cardservice.debit(card, total); if (code == CreditTransactionCode.SUCCESS ) { return total; else { throw new CreditCardTransactionException(code); The purchase method uses the dependencies 4

5 What is wrong with this solution? Sure, this code works, but.. You can t test this code! Tests would have to execute against the actual database (slow) and credit card service ($$$) Lots of data setup: create database file and credit card account The BookStore has to know how to configure its dependencies Does the BookStore really care what port the credit card service runs on? If another class wants to use the BookDatabase, it would have to create another instance Two BookDatabases can t work with the same file If you want to switch out another implementation of the dependencies, you have to change the BookStore Again, does the BookStore really care what kind of BookInventory is uses? 5

6 Don t call us, we ll call you The Hollywood Principle states that dependent code should require that its dependencies are provided to it Practically speaking, it means pass dependencies into the constructor public BookStore( BookInventory inventory, CreditCardService cardservice ) { this.inventory = inventory; this.cardservice = cardservice; Now the BookStore class doesn t have to know about the concrete types of its dependencies Let the main program create and configure dependencies public class BookStoreApp { public static void main(string... args) { String tmpdir = System.getProperty( "java.io.tmpd File directory = new File( tmpdir ); BookInventory inventory = new BookDatabase( directory, "books.txt" ); CreditCardService cardservice = new FirstBankOfPSU( "localhost", 8080 ); BookStore store = new BookStore(inventory, cardservice); 6

7 Testing with Mock Objects Now that a BookStore gets passed its dependencies, you can test the class without using the production BookInventory and CreditCardService Instead of using real dependencies, test with mock objects that provide an implementation of the interface that is useful for testing package edu.pdx.cs410j.di; public abstract class MockObject { protected void shouldnotinvoke() { throw new UnsupportedOperationException( "Did not expect this method to be invoked"); package edu.pdx.cs410j.di; public class MockBookInventory extends MockObject implements BookInventory { public void remove( Book book ) { shouldnotinvoke(); 7

8 Testing with Mock Objects Test that BookStore invokes the expected methods of its dependencies Override interface methods to keep track of how it was invoked package edu.pdx.cs410j.di; import org.junit.test; import java.util.collections; import static org.junit.assert.assertequals; import static org.junit.assert.assertnotnull; public class BookStoreTest public void testbookispurchased() { final Book[] removedbook = new Book[1]; BookInventory inventory = new MockBookInventory() public void remove( Book book ) { removedbook[0] = book; ; CreditCardService cardservice = new MockCreditCar public CreditTransactionCode debit( CreditCard return CreditTransactionCode.SUCCESS; ; 8

9 Testing with Mock Objects Once the mock dependencies are set up Create the BookStore Invoke the method you want to test Verify that the dependency was invoked as you expected BookStore store = new BookStore(inventory, cardservice); CreditCard card = new CreditCard( "123" ); final Book testbook = new Book("title", "author", 1.00d); double total = store.purchase( Collections.singletonList(testBook), card ); assertequals( testbook.getprice(), total, 0.0d ); final Book removed = removedbook[0]; assertnotnull( removed ); assertequals(testbook.gettitle(), removed.gettitl assertequals(testbook.getauthor(), removed.getaut assertequals(testbook.getprice(), removed.getpric 9

10 Mock Objects are Awkward Mock Objects get the job done, but... Lots of verbose boilerplate code When interface changes (new method, e.g.), mock has to change Subclassing mock objects is hokey Lots of anonymous inner classes Have to keep track of state that was passed to dependency There s got to be a better way, right? 10

11 Mock Objects with Mockito There are several testing libraries for Java that allow you to easily create mock objects We re going to learn about Mockito ( A Java API that creates mock objects for interfaces and classes Contains a domain specific language (DSL) for constructing mock objects You can specify what behavior you expect out of the mock objects Add the dependency in your pom.xml <dependency> <groupid>org.mockito</groupid> <artifactid>mockito-core</artifactid> <version>1.8.5</version> <scope>test</scope> </dependency> 11

12 Mock Objects with public void testcreditcardischarged() { Book book = mock(book.class); double price = 1.00d; when( book.getprice() ).thenreturn( price ); BookInventory inventory = mock(bookinventory.class); CreditCardService cardservice = mock(creditcardservice.class); when(cardservice.debit(any( CreditCard.class ), anydouble() )).thenreturn( CreditTransactionCode.SUCCESS ); BookStore store = new BookStore(inventory, cardservice); CreditCard card = mock(creditcard.class); double total = store.purchase( Collections.singletonList(book), card ); assertequals( book.getprice(), total, 0.0d ); verify( cardservice ).debit( card, price ); Let s take a closer look... 12

13 Creating mock objects The most interesting methods are all in the org.mockito.mockito class The mock method creates a mock object for an interface or class static <T> T mock(class<t> classtomock) Unless instructed otherwise, invoking a method of the mock object will noop or return null Mockito uses crazy class loading tricks to accomplish this We mocked all of our objects in the previous example No need to invoke constructors Only had to specify the state we needed The test doesn t care about the title or author of the Book We can add a method to an interface without having to update a mock implementation 13

14 Specifying behavior of mock objects The when method specifies how a method of the mock object should behave static <T> OngoingStubbing<T> when(t methodcall) Because they cannot be overridden by the magical class loader, final methods cannot be sent to when The OngoingStubbing class specifies what the behavior of the mock method thenreturn(t value) will cause the mock method to return a given value thenthrow(throwable t) will throw an exception when the mock method is invoked thencallrealmethod() will invoked the real implementation of the mock object to be invoked In general, you want to chain the when and then calls together when( book.getprice() ).thenreturn( price ); 14

15 Method Argument Matching The same mock method can be configured with different argument values when( cardservice.debit(card, price).thenreturn(success)) when( cardservice.debit(card, -1.0).thenReturn(INVALID_AMOUNT)) Sometimes the behavior of the mock method doesn t depend on the value of its arguments Always return SUCCESS no matter which card is passed in Matchers, the superclass of Mockito, has methods for filtering which values apply to the when Basically, there are bunch of type safe any methods any() object (or null) or any(class<t>) object of a given type anyint(), anydouble(), anystring(), etc. isnull, isnotnull, and same(t), matches(string regex) 15

16 Method Argument Matching If at least one arguments to a mock method is one of the matchers, then all arguments must be matchers Use the eq() methods for matching on a single value when( cardservice.debit( any(creditcard.class), eq(-1.0) ).thenreturn(invalid_amount); The AdditionalMatchers class has even more matchers Boolean operations on matchers: and, or, not, etc. Comparison operations: gt, lt, geq 16

17 Verifying Mock Objects After configuring your mock objects and sending them to the API you want to test, the mock objects are verified Mock objects keep a history of what methods were invoked with which arguments The verify method tests whether or not a mock method was invoked with the expected arguments To verify that cardservice was invoked with the expected card and price: verify( cardservice ).debit( card, price ); You can also use matchers with verify verify(cardservice).debit( same(card), eq(price) ); 17

18 Managing Dependencies As your application scales, wiring together dependencies can become very cumbersome Large initialization code that references tons of classes Difficult to change out old implementations for new implementations End up relying on design patterns to create instances Factory Pattern Create instances of a class using a static method Singleton Pattern Access the one-and-only instance of a class via a static method Lots of boilerplate code that is tricky to get right Concurrent access to singletons Life cycle of pooled/cached objects 18

19 Google Guice Google Guice (pronounced juice ) is a framework for configuring and injecting dependencies into Java classes Leverages annotations to provide type-safety Well-known objects are registered in one place (a module ) Objects that depend on well-known objects are created by Guice via reflection Dependencies are injected into constructors and fields Maven dependency: <dependency> <groupid>com.google.code.guice</groupid> <artifactid>guice</artifactid> <version>2.0</version> </dependency> 19

20 Managing Dependencies without Guice From BookStoreApp.java public static void main(string... args) throws JAXBException, IOException { String tmpdir = System.getProperty("java.io.tmpdir"); File directory = new File(tmpdir); BookInventory inventory = new BookDatabase(directory); addbooks(inventory); CreditCardService cardservice = new FirstBankOfPSU("localhost", 8080); Logger logger = Logger.getLogger("edu.pdx.cs410J.Logger"); logger.setlevel(level.info); CheckoutPanel panel = new CheckoutPanel(inventory,cardService,logger); BookStoreGUI gui = new BookStoreGUI(panel); gui.pack(); gui.setvisible( true ); If we want to introduce another panel that is for inventory control, we d have to pass the well-known BookInventory instance to that code, too. 20

21 Requesting Objects from Guice Annotating one of a class s constructors instructs Guice to invoke that constructor when an instance is requested Guice will provide the well-known instances of the constructors public CheckoutPanel(BookInventory inventory, CreditCardService cardservice, Logger logger ) { If Guice is asked to create an instance of CheckoutPanel, it will invoke this constructor and provide an instance of BookInventory and CreditCardService Your code doesn t need to create the dependencies any can also be applied to methods and non-final instance fields methods that are invoked by methods are invoked by Guice after the instance is created Guice automatically injects a Logger whose name is the name of the class into which it is injected. And you can t change it. 21

22 Guice Modules A Guice module tells the Guice infrastructure about well-known objects Your modules subclass com.google.inject.abstractmodule Objects are bound into Guice using the bind method Linking a type to its implementation (like a factory method) bind(bookinventory.class).to(bookdatabase.class); Whenever an object depends on a BookInventory, Guice will provide it with an instance of BookDatabase By default, Guice will create a new instance of a bound class when it is requested Singleton objects in Guice can be configured in two ways Annotating the object s class Binding the type in the singleton scope bind(creditcardservice.class).to(firstbankofpsu.class).in(singleton.class); 22

23 Annotations for Binding annotation can be used to name well-known objects From public String int serverport ) In your module, you can bind the values of the named objects: bind(string.class).annotatedwith(names.named("serverhost")).toinstance("localhost"); bind(integer.class).annotatedwith(names.named("serverport")).toinstance( 8080 ); When Guice instantiates FirstBankOfPSU it will provide the values of the server host and port. 23

24 Annotations for Binding You can also create your own annotation types for well-known objects DataDirectory is an annotation for the directory in which application data is stored package edu.pdx.cs410j.di; import com.google.inject.bindingannotation; @Target({ElementType.PARAMETER, DataDirectory means that the annotation being defined can be used with Guice 24

25 Annotations for Binding You can annotate constructor public File directory) And bind the value in your module: String tmpdir = System.getProperty("java.io.tmpdir"); File directory = new File(tmpdir); bind(file.class).annotatedwith(datadirectory.class).toinstance(directory); 25

26 Creating an Injector A Guice module is used to create an Injector which provides access to well-known objects public class GuicyBookStoreApp extends BookStoreApp { public static void main(string... args) { Injector injector = Guice.createInjector(new BookStoreModule()); BookInventory inventory = injector.getinstance(bookinventory.class); addbooks(inventory); BookStoreGUI gui = injector.getinstance(bookstoregui.class); gui.pack(); gui.setvisible(true); Guice takes care of creating and configuring all of the dependencies of BookStoreGUI and wiring them together Ultimately, your code is more decoupled and can be reconfigured more easily 26

27 Provider Methods Sometimes, objects need more than a constructor call in order to be initialized Or the constructor needs dependencies that are not provided by Guice A module method that is annotated constructs a Guice-managed instance of its return type This is probably a better way to configure the protected File providedatadirectory() { String tmpdir = System.getProperty("java.io.tmpdir"); return new File(tmpdir); It would probably be better to construct the FirstBankOfPSU using a provider method, also. You wouldn t need constructor parameters that reused anywhere 27

28 Provider classes A Provider class is used to create very expensive objects or objects that you want lazily initialize public class EncyrptionKeyProvider implements Provider<EncryptionKey> { private final EncryptionAlgorithm public EncyrptionKeyProvider(EncryptionAlgorithm al this.algorithm = public EncyrptionKey get() { // Perform expensive operation on demand return new EncryptionKey(algorithm); Bind with: bind(encyrptionkey.class).toprovider(encyrptionkeyprovider.class); 28

29 Provider classes Guice can inject a provider into an public class ConnectionManager private Provider<EncryptionKey> keyprovider; public ConnectionManager() { // Should inject Provider as parameter instead public Connection createconnection() { return new Connection(keyProvider.get()); Even though the ConnectionManager is a singleton, it can get multiple EncyrptionKeys by injecting the Provider Okay, ConnectionManager is a factory and we could probably doing this Guicier, but you get the point 29

30 Summary Dependency Injection is the ultimate expression of programming to the interface The Hollywood Principle states that objects should receive their dependencies upon construction When dependencies are decoupled, finer-grained testing is possible Mockito provides facilities for mocking objects and specifying mocked behavior Google Guice manages dependencies by separating configuration code from application code 30