-1

I've been thinking about having multiple page elements and making tabbing with a PageFactory. Then I realized it would be better to not to type all the types that I want, since I just wanna get the instance. Then I created something as follows:

    public static T GetInstance<T>() where T:IPage, new()
    {
        return new T();
    }

But the point is, I can just create my pages like new WelcomePage(); instead of PageFactory.GetInstance<WelcomePage>() and it doesn't make sense to me to have a generic method like that. But I see it is something used before.

So, what is the benefit of using that generic way to get an instance. I'd be happy to hear, probable needs.

Mert
  • 113
  • 1
  • 5
  • In that specific scenario, yeah it is pointless. But imagine that every `IPage` needed to have a property set before it was useful. Now you can centralise that logic in this one place - for example. Now, would I **personally** do it that way? No (I'd use an IoC container). – mjwills Jun 06 '19 at 01:01
  • Consider the following: what if your method needs to return a different kind of `IPage` depending on some other information? Does it make sense then? – BJ Myers Jun 06 '19 at 01:02
  • @BJMyers The caller is somewhat explicit about what type they want (or at least the base type of the type they want, if I was being overly charitable) though. – mjwills Jun 06 '19 at 01:03
  • This is too broad, there is no reason to do this, any other example of doing *exactly* this is pointless. The reasons why you would add the `new()` *constraint* or *generics* and *constraints* are in the billions – TheGeneral Jun 06 '19 at 01:03
  • I can see a use in a _larger system_ but that is not demonstated here –  Jun 06 '19 at 01:12
  • @mjwills Yes, DI makes lot more sense but I'm trying to make something self contained, in order to create kind of a library. So I don't wanna force any container. – Mert Jun 06 '19 at 01:16
  • @MickyD an example would be great. – Mert Jun 06 '19 at 01:20
  • 1
    @Mert - There are so many reasons to do things like this. For example, if you change your signature to `IPage GetInstance() where T:IPage, new()` then you can create a `T`, but wrap that `T` in another class that implements `IPage` so that you can add logging or debugging to your code at run-time. – Enigmativity Jun 06 '19 at 01:22
  • 1
    @Mert _"an example would be great"_ - the onus is on you to provide a more detailed example before we can comment sadly –  Jun 06 '19 at 02:18

1 Answers1

1

Given that this is static method, I see no benefits over new, except usage of GetInstance in other generic methods. (Non static factory, as a part of interface or abstracts class, and with more that 1 implementation, would get more sense, as client would not depend on specific factory, or e.g. different factory could be used in tests than in production).

I would prefer new, because:

  • it's immediately understandable, and doesn't require an extra looking into implementation details of GetInstance
  • given that GetInstance<T> is generic, and constructor constraints on generics are limited to parameterless constructor new (), this implies that dependencies will be injected into T object via properties or ambient environment, neither of which is ideal. Dependency injection via constructor is much better.
Renat
  • 7,718
  • 2
  • 20
  • 34