Tim Holloway wrote:Well, technically, all Inversion of Control (IoC) requires is that instead of going out and finding things (Locator Pattern), someone/thing injects those things in.
But it's a lot more flexible if the injectable things are abstract, as that makes them plug-replaceable.
One of my favorite examples along those lines is using an email interface. If you have a class that generates emails, injecting an email sender Interface means that you can test the generating class with a dummy email sender injected in, then inject the actual email sender when you are ready to go live. Thus sparing the world a lot of junk email.
Q# | Question |
---|---|
1 | Can interface be used as variable/ field? If yes, please quote reference under which scenario? please give an example to illustrate |
2 | Can interface be used as argument/ parameter? If yes, please quote reference under which scenario? please give an example to illustrate |
Junilu Lacar wrote:
Sukumar Sat wrote:
I can rewrite code as following: -
You're "rewrite" doesn't work so there's really nothing to compare other than the original works and yours doesn't.
Junilu Lacar wrote:
Sukumar Sat wrote:
I can rewrite code as following: -
You're "rewrite" doesn't work so there's really nothing to compare other than the original works and yours doesn't.
Junilu Lacar wrote:The code was given as an example of the Dependency Inversion Principle, i.e. depend on abstractions instead of concrete implementations. An interface is an abstraction, so. that's why the field and the method parameter are using the interface type instead of any specific implementation type. This way, the program can use any implementation. If someone comes up with a different implementation of the EngineInterface in the future, you can easily use it without changing any of the code in the Car class.
On the other hand, if the Car class depended on a specific implementation instead, the program code will need to be modified if you want to use a different engine implementation in the future.
Tim Moores wrote:The Domain class has no particular purpose except to illustrate the concept of BiPredicate - it models an internet domain (like "google.com") along with a "goodness" score of that domain.
The filterBadDomain method simply applies a Bipredicate to a List of domains. it's shown in action several times in the code; did you get that to run now? That should be the first step in learning from this example, as it makes it much easier to understand what's going on. (Although the source code does actually show the output of each of the System.out.println statements.)
Tim Moores wrote:Welcome to the Ranch.
Note this comment in the Domain class:
// getters , setters , toString
That means you need to add the usual getter and setter methods: setName, getName, setScore and getScore. (toString is not needed for this example.)