Clean Code Case Study - Confusion

[Christian B]

In a series of videos uncle bob pairs with his son Micah Martin and doing some clean architecture stuff. 

The project is hosted here: https://github.com/cleancoders/CleanCodeCaseStudy

Now, i have a few questions here, and maybe the answer to some of those question is "Because its not done yet":

A: Interactor "PresentCodecastUseCase"

Source: https://github.com/cleancoders/CleanCodeCaseStudy/blob/master/src/cleancoderscom/PresentCodecastUseCase.java

Questions:

1. Why does the Interactor return a value?
2. Why does the Interactor have no presenter to set the response in?

B: Gatekeeper

Source: https://github.com/cleancoders/CleanCodeCaseStudy/blob/master/src/cleancoderscom/GateKeeper.java

Questions:

1. So this is a concrete implementation. When making a web application, should that not be put behind an interface? (Changes -> Rebuild)

C: MockGateway

Source: https://github.com/cleancoders/CleanCodeCaseStudy/blob/master/src/cleancoderscom/MockGateway.java

Questions:

1. So a Mock does by definition know, what should happen in a test case and has some kind of verify method. But this "mock" has serious in memory implementation. Isn't that a Fake? Or just a simple InMemoryGateway?
   

D: Context

Source: https://github.com/cleancoders/CleanCodeCaseStudy/blob/master/src/cleancoderscom/Context.java

Questions:

1. What role does this class actually play? Why is this class there?

[Sebastian Gozin]

• A: I believe a return value is considered a form of sending a response to the presenter. For this kind of public query it is probably the most straight forward way as there are no exceptions.
  
• B: Maybe, but I'm not sure if this thing has crossed any boundaries yet.
• C: This feels like a fake yes. I suspect if it keeps being used it may be promoted to a full featured in memory strategy. Otherwise it's called a mock because everybody calls test doubles mocks.
• D: It's the place where the application components are as they have been created and wired up by main.
• main sets concrete instances on context and thus knows about the implementations used
  
• app reads and uses stuff from context via their public interfaces without knowing about the implementation

Hope this helps,

[Christian B]

It's the place where the application components are as they have been created and wired up by main.

So its like the Registry Pattern? Had bad experiences with that one.

[Sebastian Gozin]

You have another approach in mind?
When I compare this to the ApplicationContext from Spring I can't say it's all that different.

[Christian B]

Yes, inject the Gateway into the Use Case. When using a Context you have to cleanup that context on test tearDowns. Context is a global state and its poison for testing. It can have bad influence on other tests.

I don't know the Java world really good, so if Spring does this, ok, but i think its bad design.

[daniphp]

A. You are correct, a presenter should be passed but the complexity will be higher. I did not see yet a clear example with a presenter.

B. You don't always need an interface.

C. It's a test double ( probably a fake )

D. You should use injection, yes.

[daniphp]

I would also add that even if Uncle Bob is using the term Gateway, according to Martin Fowler and Eric Evans it's a Repository. In my interpretation the Gateway doesn't know the entities and it only works with primitives in it's methods.

[Sebastian Gozin]

I think injection is preferable but in the case of Fitness fixtures not very practical. I presume that he'll only use it this way here to bridge the 2 and then rely on simple injection.
As fr gateways being repositories. I never really liked or saw any purpose in the distinction between repositories and gateways. I feel it is like adding an I to interface names which ultimately doesn't mean anything useful.

[Gareth Wedley]

A: Interactor

Yeah it confused me that there wasn't a presenter. After all, we were told in other videos that the use case interactors drive the views through the presenter interface.

I think in these early stages of the case study, we haven't acknowledged the presenter as its not required for the tests we are doing. We are just trying to get the basics of the use case implemented and defining the gateway interface and how its used.

Im expecting that at some point, a Use Case / Interactor interface will be created with a command method like execute(), and a presenter interface which the use case uses. If the delivery mechanism then uses the Use Case interface, the public methods we see now will be unknown to it. Im not 100% sure, but I think we have these other public methods returning values as it helps us with acceptance tests, and it may also be useful for other use cases to call these methods later on?

Later in the series I think we will start seeing tests and functionality that are more closely linked to what we've seen in previous videos and we will start calling presenters based on the logic we have currently implemented.

D: Context

We are using this to inject some of the dependencies into the application. It saves having to add a gateway constructor argument etc to every use case. Again, could be wrong, but I see myself using my IoC container to provide this context in a real implementation. Both are singletons.