Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stop using poor man's dependency injection #5

Open
SamHurne opened this issue Sep 19, 2015 · 0 comments
Open

Stop using poor man's dependency injection #5

SamHurne opened this issue Sep 19, 2015 · 0 comments
Milestone

Comments

@SamHurne
Copy link
Collaborator

[Moved from Codeplex: https://gw2dotnet.codeplex.com/workitem/1346]

While most of the library accepts dependencies as constructor parameters, there are a lot of constructor overloads that create their own objects.

This "technique" is called poor man's dependency injection. Code written like this is only acceptable in the top-level library (GW2NET.csproj).

When you see code like this, refactor it so that there is only 1 constructor that has parameters for every dependency.

class Foo
{
    private readonly IBar bar;

    public Foo()
        : this(new BarImplementation())
    {
    }

    public Foo(IBar bar)
    {
        this.bar = bar;
    }
}

Refactored without poor man's dependency injection:

class Foo
{
    private readonly IBar bar;

    public Foo(IBar bar)
    {
        this.bar = bar;
    }
}

StevenLiekens wrote May 27 at 4:24 PM

Example changeset: https://gw2dotnet.codeplex.com/SourceControl/changeset/40883

StevenLiekens wrote May 28 at 7:52 AM

Recommended reading: https://stackoverflow.com/questions/7099406/what-is-the-real-difference-between-bastard-injection-and-poor-mans-injectio

sliekens added a commit to sliekens/GW2.NET that referenced this issue Sep 27, 2015
 - Change converter naming convention.
     Previous naming convention: 'ConverterForXyz'
     New naming convention: 'XyzConverter'

 - Change data contract naming convention.
     Previous naming convention: 'XyzDataContract'
     New naming convention: 'XyzDTO'

 - Move types into matching files

 - Move initialization code to te bootstrapper.
     The bootstrapper is now reponsible for initializing converters.

 - Convert internal classes to public sealed.
     This change is necessary to be able to initialize converters
     from outside their containing assembly.

 - Improve argument exception messages
     When 'ArgumentException' (or a derivation) is thrown, the
     message should say what is expected instead of what isn't.

- Replace boilerplate converter code with T4 templates
     Where possible, T4 text templates and reflection are used
     to automatically generate type converters for well-known
     entities.

Resolves: Ruhrpottpatriot#7
See also: Ruhrpottpatriot#5
sliekens added a commit to sliekens/GW2.NET that referenced this issue Sep 29, 2015
 - Change converter naming convention.
     Previous naming convention: 'ConverterForXyz'
     New naming convention: 'XyzConverter'

 - Change data contract naming convention.
     Previous naming convention: 'XyzDataContract'
     New naming convention: 'XyzDTO'

 - Move types into matching files

 - Move initialization code to te bootstrapper.
     The bootstrapper is now reponsible for initializing converters.

 - Convert internal classes to public sealed.
     This change is necessary to be able to initialize converters
     from outside their containing assembly.

 - Improve argument exception messages
     When 'ArgumentException' (or a derivation) is thrown, the
     message should say what is expected instead of what isn't.

 - Replace boilerplate converter code with T4 templates
     Where possible, T4 text templates and reflection are used
     to automatically generate type converters for well-known
     entities.

 - Add integration tests

Resolves: Ruhrpottpatriot#7
See also: Ruhrpottpatriot#5
@Ruhrpottpatriot Ruhrpottpatriot added this to the v2.0.0 milestone Oct 3, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants