Looks like you’re introducing an Adapter for a subsystem. An interface is introduced so that the dependency is abstracted. The indirection then is added and can be manipulated in the last step using test doubles that implement that interface. Looks like a combined refactoring to me. Don’t have Fowler or Kerievsky here to look up the name, but the name seems to be something like “Extract Interface and introduce Adapter”.
I actually see it as “Decouple Subsystem”, which first adds a class that defines an exact API, and then that class is transformed to an Interface for even greater decoupling and easier testing.
For me, this refactoring is about to isolate the left sub system from the whole system, by extracting a facade.
The gray component is actually the only one which doesn’t belong to this subsystem.
r.
about 4 hours later:
I like and second the Breaking Dependencies comments from Markus and Romain with the use of extract Interface / Facade and introduce Adapter.
When presenting this one, I also discuss it as “A single place should change when changing the (right hand side) subsystem”. Easier to test and easier to change the dependencies.
I would simply name this sequence of 4 steps “Introduce Test Double”. It does contain the refactoring “Decouple Service” (steps 1 to 3).
1/ Various components depend on a service typically outside of our control. Select this service, then:
2/ “Introduce Adapter” (almost a Proxy indeed), which becomes the service actually depended upon by the legacy components.
This is the step with most impact on the code base. What is not explained here is how to retrieve the Adapter, as it will become key for step 4 (Dependency Injection? FactoryMethod? Singleton?)
3/ “Extract Interface” on the proxy: we now have a degree of freedom (variability) to implement alternate implementations of the service
This one looses me. I liked the concise one-picture drawing better. So this looks like 0) identify commonalities amongst the consumers of a bunch of logic (represented by the cloud), 1) create a Facade, then 2) extract interface, then 3) implement bunch of test doubles. Too much for a single slide and the message is somewhat blurred. Also, w/o arrows the direction is difficult to figure out (who’s the consumer, who’s the provider)
Step 1: external service is hidden behind a Facade class.
Step 2: an interface is extracted.
Step 3: multiple implementations can be used for test purposes.
Tim Ottinger
about 17 hours later:
without reading anyone else’s comments, my immediate interpretation was “encapsulate API”, “Extract interface”, “introduce test doubles”.
ceferhat
1 day later:
a consumer proxy has been created and strategy (may be adapter) applied, for connecting to other clouds.
unclebob
1 day later:
Arrowheads would help. If we could see that the little guys all use the cloud, then the extraction and subsequent decoupling of behavior from the cloud becomes clearer. The initial arrowheads ought to point at the cloud since they are using relationships.
Chris Tinning
22 days later:
Manuel for me offers the best explanation but the additions of arrows would make things clearer.
I interpret this as “How to insert an interface to an outside resource to make testing easier with code that depends on that resource.”
Exposing services/programs to the internet.
0 to 1: Making the objects talk to a single class instead of talking to web services (? the cloud?) directly.
1 to 2: Extracting an interface so the objects talk to an interface instead of the object directly.
2 to 3: Now you can plug-in various test doubles for testing purposes.
Looks like you’re introducing an Adapter for a subsystem. An interface is introduced so that the dependency is abstracted. The indirection then is added and can be manipulated in the last step using test doubles that implement that interface. Looks like a combined refactoring to me. Don’t have Fowler or Kerievsky here to look up the name, but the name seems to be something like “Extract Interface and introduce Adapter”.
I actually see it as “Decouple Subsystem”, which first adds a class that defines an exact API, and then that class is transformed to an Interface for even greater decoupling and easier testing.
For me, this refactoring is about to isolate the left sub system from the whole system, by extracting a facade.
The gray component is actually the only one which doesn’t belong to this subsystem.
I like and second the Breaking Dependencies comments from Markus and Romain with the use of extract Interface / Facade and introduce Adapter. When presenting this one, I also discuss it as “A single place should change when changing the (right hand side) subsystem”. Easier to test and easier to change the dependencies.
Step 0: Many classes (left) access different classes of an external library (right)
Step 1: Create a facade for the external library
Step 2: Create an interface for the facade
Step 3: Create test doubles to mock the external library to be able to test the classes on the left without the dependency on the external library
step 1: Extract class Step 2: Extract interface
I love the playful idea of the quizz.
I would simply name this sequence of 4 steps “Introduce Test Double”. It does contain the refactoring “Decouple Service” (steps 1 to 3).
1/ Various components depend on a service typically outside of our control. Select this service, then:
2/ “Introduce Adapter” (almost a Proxy indeed), which becomes the service actually depended upon by the legacy components.
This is the step with most impact on the code base. What is not explained here is how to retrieve the Adapter, as it will become key for step 4 (Dependency Injection? FactoryMethod? Singleton?)
3/ “Extract Interface” on the proxy: we now have a degree of freedom (variability) to implement alternate implementations of the service
4/ “Inject Test Double”. Create Mock implementation(s) + configure dependency injection
Extract a class from the cloud to create a Facade. Creates an interface. Create some mock classes.
Step Zero: Your classes have Un-DRY code that uses some other classes (represented as a cloud there)
Step One: You realize that and abstract common behavior in a concrete class
Step Two: You create an interface for the newly created class, so clients don’t depend on implementations but on interfaces instead.
Step Three: Here you realize that you can stub/mock the implementation and test the client classes in isolation.
This one looses me. I liked the concise one-picture drawing better. So this looks like 0) identify commonalities amongst the consumers of a bunch of logic (represented by the cloud), 1) create a Facade, then 2) extract interface, then 3) implement bunch of test doubles. Too much for a single slide and the message is somewhat blurred. Also, w/o arrows the direction is difficult to figure out (who’s the consumer, who’s the provider)
Step 1: external service is hidden behind a Facade class. Step 2: an interface is extracted. Step 3: multiple implementations can be used for test purposes.
without reading anyone else’s comments, my immediate interpretation was “encapsulate API”, “Extract interface”, “introduce test doubles”.
a consumer proxy has been created and strategy (may be adapter) applied, for connecting to other clouds.
Arrowheads would help. If we could see that the little guys all use the cloud, then the extraction and subsequent decoupling of behavior from the cloud becomes clearer. The initial arrowheads ought to point at the cloud since they are using relationships.
Manuel for me offers the best explanation but the additions of arrows would make things clearer.
well… i’d say : Step 1: Extract class Step 2: Extract interface
step one: Extract class step two: Extract interface
Free download Blu-ray to iPad Mac, you can easily convert Blu ray and DVDs to iPad for playing.