Say I have something like this:
#Module
internal class SeenModule {
#Provides
fun parameter() = Parameter()
#Provides
fun actualThingINeedToInject(parameter: Parameter) = ActualThing(parameter)
}
However, this module only really needs to provide an ActualThing object - in other words, the Parameter is only there because the very own module needs it. I don't want it to be part of the set of dependencies that can be retrieved outside of this module.
The way I'm currently doing this is by defining a custom scope as private and then marking the methods that provide dependencies which shouldn't leave the module with this scope, as well as those in the module where the provided dependencies should be injected, of course. This is a bit annoying because it prevents me from using other scopes in these methods and requires a lot of additional annotating all over the place. What is the proper way to achieve this?
Dagger doesn't really offer "private bindings" in the sense you're asking for, where Parameter would not be injectable from anywhere else. I also advise against using scope annotations for visibility, in part because the Component itself would need to be annotated with that scope annotation, so the scope annotation would simply slightly increase the hassle needed to improperly consume Parameter (and the hassle needed to create a Component that properly consumes Parameter).
I'd offer one of these three alternatives:
Reduce the visibility of Parameter as a class. If Parameter is package-private, you won't be able to refer to it from outside of that Java package, giving you the encapsulation you want.
Use "Subcomponents for Encapsulation", in which you create a subcomponent, install your Parameter (and any related bindings) in a Module bound on the subcomponent, and expose only your ActualThing on the subcomponent's interface. Your subcomponent will be injectable, but your Parameter is not; you can also write a #Provides method that returns your ActualThing from your subcomponent instance.
Grin and bear it, and just document that Parameter is an implementation detail that should not be accessed outside of certain packages. If you are providing objects to external teams who access ActualThing through your Component interface, you can simply decline to put Parameter on your public interface; if you are providing objects to internal teams they will likely have access to change your Dagger structure or access modifiers anyway. You might also ask yourself why Parameter would be useful for another team to consume, and document it as an API if there is a business reason for injecting it.
Related
I would like to write test for a controller class. The controller class takes a service object as constructor parameter. Added the #Inject annotation to the constructor of the service class.
class AssociateService #Inject()(configuration: Configuation){...}
The constructor parameter of the service class is a custom configuration object also created for the application. I added the #Inject to the constructor of the config class as well. Now I'm getting these types of error messages:
No implementation for "className" was bound.
Could not find a suitable constructor in java.lang.Integer. Classes must have either one (and only one) constructor annotated with #Inject or a zero-argument constructor that is not private.
The configuration class has several constructor parameters, those are "basic" types (Int, Boolean) and one parameter is a custom class type (className).
How should I do this binding or is it just enough to annotate something else?
And why it says that constructor error message?
As far as I know, there are two ways with tests and guice, with trade offs:
Don't using field injections, using only constructor injections and fields assignment in constructor for injected parameters. This approach enables very simple solution for testing, just don't use dependency injection in tests. But all your classes must have ability to be created with new operator in test cases...
Ps. You can define optional constructor and use field injections, of course, but it is not very clear solution.
Creating correct module with injectable interfaces binding to its implementations for every test or group of similar tests. Sometimes this approach takes a lot of unnecessary working hours.
You must design your software to maintain testability. Sometimes not every line of code in project need to be tested, sometimes not every code is testable, you must separate it from important parts of your software, that requires testing. If you design your software with single responsibility principe so writing tests is much easer...
When using Dagger 2, very often I'm applying the following pattern:
Create interface, let's call it LoginService
Create the only one implementation - LoginServiceImpl with the constructor injection:
class LoginServiceImpl implements LoginService {
#Inject LoginServiceImpl() {}
}
Bind the implementation to the interface:
#Binds
abstract LoginService bindStatisticsService(LoginServiceImpl impl);
Always depend on the interface - LoginService in this case.
Is there a possibility to avoid the #Binds annotated method? Is there a simpler (with the less amount of boilerplate code) way to tell Dagger - this class is the only one implementation of the interface, always bind it for example in some annotation on the interface itself?
I've read the documentation and unfortunately haven't found anything like that, but maybe someone knows some trick which can solve my problem.
I don't think that's possible, even hypothetically.
Dagger can't really tell that there's only one implementation, and the only way it could would be to search for every class on the (compilation) classpath to try to find all sorts of possible implementation. That would be slow at best, but Java allows classloading from custom classloaders, so you aren't ever really guaranteed to get a full list of available classes. Even if you were to claim that Dagger should just match against the first appropriate assignable type it sees (because you know that there's only one), Dagger may not have a way to identify where to find that implementation type.
Ultimately it's going to be difficult to improve on a single-line #Binds statement that identifies the fully-qualified class of the binding key (your.package.name.LoginService) and target (your.package.name.LoginServiceImpl).
I already read the documentation about the new modifiers "open" and "fileprivate". But there are two things that I don't understand:
Why is it not possible to declare protocols or extensions also as "open"? And does it mean that it's not possible to use these things outside a module?
If I don't want to build my classes for a module but an common app, should I declare my classes and methods as "open" anyway or is it good practice to keep them only "public"?
As this answer says:
An open class is accessible and subclassable outside of the defining module. An open class member is accessible and overridable outside of the defining module.
A public class is accessible but not subclassable outside of the defining module. A public class member is accessible but not overridable outside of the defining module.
I think the answer to your first question, is that you can't override or subclass a protocol or extension. Thus, there is no use for such things to be open because public already makes them accessible outside of a module.
For your second question, I would say that you should only declare your own classes as open if you plan on overriding or subclassing. Otherwise you are allowing unnecessary access to these items. Most of the time public should suit your needs.
Edit:
As #Alex points out, I don't think there are many downsides to allowing this "extra access". The only thing I can think of is if you just wanted to protect your classes from your future self, but that may or may not be applicable. Thus, if this is not the case, there shouldn't be much harm in setting them as open by default.
open is for another module, for example in we use it in unit test or in cocoa pods, you can inherit from a pod (if it's: open class somePod {...}) or override some function (if it's: open func someFunctionInPod{...}) in your project.
In c# we have the protected accessor which allows class members to be visible on inherited clases but not for the rest.
In Swift this doesn't exist so I wonder what's a correct approach for something like this:
I want to have a variable (internal behavior) and and a public method using this variable on a base class. This variable will be used also on inherited clases.
Options I see
Forget about base class and implement variable and methods everywhere I need it. WRONG, duplicated code
Implement inheritance by composition. I'd create a class containing common methods and this will be used by composition instead of inheritance. LESS WRONG but still repeating code that could be avoided with inheritance
Implement inheritance and make variable internal on base class. WRONG since exposes things without any justification except allowing visibility on inherited clases.
Implementation Details for Base Class
I want to have a NSOperationQueue instance and and a public method to cancel queued operations. I add new operations to this queue from inherited classes.
In Swift the correct answer is almost always protocols and extensions. It is almost never inheritance. Sometimes Cocoa stands in our way, because there are classes in Cocoa more often than protocols, but the goal is almost always protocols and extensions. Subclassing is our last choice.
Your particular case is confusing because NSOperationQueue already has a public method to cancel queued operations (cancelAllOperations). If you want to protect the queue from outside access (prevent callers from using addOperation directly for instance), then you should put the queue inside another type (i.e. composition), and forward what you want to the queue. More details on the specific problem you're solving would allow us to help suggest other Swift-like solutions.
If in the end you need something that looks like protected or friend, the correct solution is private. Put your subclass or your friend in the same file with the target, and mark the private thing private. Alternately, put the things that need to work together in a framework, and mark the attribute internal. The Swift Blog provides a good explanation of why this is an intentional choice.
I used InheritedExport attribute, and have a tree of objects. Think IMessageSender where I have SmtpSender, TextSender, HttpPostSender. But through decorator pattern I have additional classes that also inherit this MEF InheritedExport attribute.
However when composing the senders, I do not want to decorators to be composed.
Now Lazy could help, whereas I only retrieve the objects that are not of the Decorator type. But I can't ask Lazy what T actually is. Perhaps metadata could help, but the metadata only applies to the object that has this metadata. I don't want to force implementers (read: developers) to add the correct metadata to their decorator or sender.
Any ideas? Thanks!
I needed to do something similar. In the end I opted to add metadata that gave me the required information, but I can see why that's not ideal for your.
One other possibility would be to switch from using an automatic import via attributes, and explicitly call CompositionService.GetExports instead. Then you'd end up with an IEnumerable of Export objects. This would let you get at the contract name (usually, but not always, the type name) and the contract metadata. I think that the contract metadata always includes the type name, so you'd have the information you're looking for.
You can use the following code, to get the type of a Lazy member:
.GetType().GetProperty("Value").PropertyType