NightOwl888 commented on issue #1059: URL: https://github.com/apache/lucenenet/issues/1059#issuecomment-2543986222
> We would then explicitly implement the interface for the GetGroup method. I think that would be cleaner than exposing a non-generic ICollection, although I could be swayed on explicitly implementing that too. Thoughts? Yeah, I definitely would stay away from a non-generic `ICollection`. > > That being said, using an interface does have an advantage we may be able to take advantage of: it can be declared internal and used just for testing purposes. > > I think if you're saying that users have a valid use case of needing to store multiple of these different collectors in a variable or collection with different type parameters, we might as well make the interface public then. But as I noted above, I think interfaces instead of abstract classes have another advantage: being able to explicitly implement them in the generic abstract classes. > > If we take the abstract class approach, you can't explicitly implement an abstract class. It will require shadowing the non-generic properties if they have the same name. I think an interface lets us have the best of both worlds: we can allow for this use case, while simplifying our testing code. I'll give it a try and see how it comes out. Agreed. I often use interfaces to separate members of the same name that only differ by return type. In fact, I made a fluent API generator that creates a builder class that implements interfaces to enforce complex business rules, such as only allowing a specific setting to be applied up to 3 times (after which it will return the builder instance cast to an interface that no longer declares the method for the setting). I would also like to see how that approach turns out. And I agree that there is more utility for this than just testing. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@lucenenet.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
