The Stack Overflow podcast is back! Listen to an interview with our new CEO.
9 added 4 characters in body
source | link

But the input port <I> interface simply can't slave itself to the Controller client and have this be a true plugin. This is a 'library' boundary. A completely different programming shop could be writing the green layer years after the red layer has been published.

But the input port interface simply can't slave itself to the Controller client and have this be a true plugin. This is a 'library' boundary. A completely different programming shop could be writing the green layer years after the red layer has been published.

But the input port <I> interface simply can't slave itself to the Controller client and have this be a true plugin. This is a 'library' boundary. A completely different programming shop could be writing the green layer years after the red layer has been published.

8 added 35 characters in body
source | link

One way to pull that off is an adapter. Put it between clients like Controler and the Input Port <I> interface. The adapter accepts Interactor as an Input Port <I> and delegates it's work to it. However, it exposes only what clients like Controller needsneed through a role interface or interfaces owned by the green layer. The adapter doesn't follow ISP it self but allows more complex class like Controller to enjoy ISP. This is useful if there are fewer adapters than clients like Controller clients that use them and when you're in the unusual situation where you're crossing a library boundary and, despite being published, the library won't stop changing. LookingLooking at you Firefox. Now those changes only break your adapters. 

One way to pull that off is an adapter. Put it between Controler and the Input Port <I> interface. The adapter accepts Interactor as an Input Port <I> and delegates it's work to it. However, it exposes only what Controller needs through a role interface or interfaces owned by the green layer. The adapter doesn't follow ISP it self but allows more complex class like Controller to enjoy ISP. This is useful if there are fewer adapters than Controller clients that use them and when you're in the unusual situation where you're crossing a library boundary and, despite being published, the library won't stop changing. Looking at you Firefox.

One way to pull that off is an adapter. Put it between clients like Controler and the Input Port <I> interface. The adapter accepts Interactor as an Input Port <I> and delegates it's work to it. However, it exposes only what clients like Controller need through a role interface or interfaces owned by the green layer. The adapter doesn't follow ISP it self but allows more complex class like Controller to enjoy ISP. This is useful if there are fewer adapters than clients like Controller that use them and when you're in the unusual situation where you're crossing a library boundary and, despite being published, the library won't stop changing. Looking at you Firefox. Now those changes only break your adapters. 

7 added 298 characters in body
source | link
  • Presenter (a service) shouldn't dictate to the Output Port <I> interface. The interface should be narrowed to what Interactor (here acting as a client) needs. That means the interface KNOWS about the Interactor and, to follow ISP, must change with it. And this is fine.

  • Interactor (here acting as a service) shouldn't dictate to the Input Port <I> interface. The interface should be narrowed to what Controller (a client) needs. That means the interface KNOWS about the Controller and, to follow ISP, must change with it. And this is not fine.

If you're crossing a 'library' boundary and you feel the need to apply ISP even though you don't own the interface on the other side you're going to have to find a way to narrow the interface without changing it.

One way to pull that off is an adapter. Put it between Controler and the Input Port <I> interface. The adapter accepts Interactor as an Input Port <I> and delegates it's work to it. However, it exposes only what Controller needs through a role interface or interfaces owned by the green layer. The adapter doesn't follow ISP it self but allows more complex class like Controller to enjoy ISP. This is useful if there are fewer adapters than Controller clients that use them and when you're in the unusual situation where you're crossing a library boundary and, despite being published, the library won't stop changing. Looking at you Firefox.

  • Presenter (a service) shouldn't dictate to the Output Port <I> interface. The interface should be narrowed to what Interactor (here acting as a client) needs. That means the interface KNOWS about the Interactor and must change with it. And this is fine.

  • Interactor (here acting as a service) shouldn't dictate to the Input Port <I> interface. The interface should be narrowed to what Controller (a client) needs. That means the interface KNOWS about the Controller and must change with it. And this is not fine.

  • Presenter (a service) shouldn't dictate to the Output Port <I> interface. The interface should be narrowed to what Interactor (here acting as a client) needs. That means the interface KNOWS about the Interactor and, to follow ISP, must change with it. And this is fine.

  • Interactor (here acting as a service) shouldn't dictate to the Input Port <I> interface. The interface should be narrowed to what Controller (a client) needs. That means the interface KNOWS about the Controller and, to follow ISP, must change with it. And this is not fine.

If you're crossing a 'library' boundary and you feel the need to apply ISP even though you don't own the interface on the other side you're going to have to find a way to narrow the interface without changing it.

One way to pull that off is an adapter. Put it between Controler and the Input Port <I> interface. The adapter accepts Interactor as an Input Port <I> and delegates it's work to it. However, it exposes only what Controller needs through a role interface or interfaces owned by the green layer. The adapter doesn't follow ISP it self but allows more complex class like Controller to enjoy ISP. This is useful if there are fewer adapters than Controller clients that use them and when you're in the unusual situation where you're crossing a library boundary and, despite being published, the library won't stop changing. Looking at you Firefox.

6 added 298 characters in body
source | link
5 added 298 characters in body
source | link
4 added 1 character in body
source | link
3 added 29 characters in body
source | link
2 added 36 characters in body
source | link
1
source | link