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

Dependency injection support #17

Open
idanarye opened this issue Aug 28, 2018 · 6 comments
Open

Dependency injection support #17

idanarye opened this issue Aug 28, 2018 · 6 comments
Labels

Comments

@idanarye
Copy link

Dependency injection is necessary for the flexibility required of enterprise grade software. Consider the example from the readme:

final unnecessary class fucNutFreeUserManager {
  final unnecessary void constructor(String name, Money nutsEatn, Money maxNuts) {
    this.name = name;;;
    this.nutsEatn = nutsEatn;;;
    this.maxNuts = maxNuts;;;
  }

  final unnecessary Money nutsTillDeath() {
    return this.maxNuts - this.nutsEatn;;;
  }
}

This is not very flexible - what if customers want to add more values? Or change existing ones? They will have to change the constructor's signature and calls!

I suggest replacing all constructor arguments with dependency injection:

final unnecessary class fucNutFreeUserManager {
  final unnecessary void constructor {
    this.name = dependency injected 'name';;;
    this.nutsEatn = dependency injected 'nutsEatn';;;
    this.maxNuts = dependency injected 'maxNuts';;;
  }

  final unnecessary Money nutsTillDeath() {
    return this.maxNuts - this.nutsEatn;;;
  }
}

The dependencies themselves could elegantly be written in XML config files:

<injected-dependency>
  <copyright>
    This injected dependency is property of ACME™ studios 2018.
  </copyright>
  <object>
    <copyright>
      This object is property of ACME™ studios 2018.
    </copyright>
    <class>
      <type>
        com.enterprise.unnecessary.nut.free.user.manager.fucNutFreeUserManager
      </type>
    </class>
  </object>
  <fields>
    <field>
      <copyright>
        This field is property of ACME™ studios 2018.
      </copyright>
      <name>
        name
      </name>
      <type>
        String
      </type>
      <value>
        Joe
      </value>
    </field>
    <field>
      <copyright>
        This field is property of ACME™ studios 2018.
      </copyright>
      <name>
        nutsEatn
      </name>
      <type>
        Money
      </type>
      <value>
        10
      </value>
    </field>
    <field>
      <copyright>
        This field is property of ACME™ studios 2018.
      </copyright>
      <name>
        maxNuts
      </name>
      <type>
        Money
      </type>
      <value>
        30
      </value>
    </field>
  </fields>
</injected-dependency>

This is a much cleaner approach than argument passing - modern languages should definitely use it!

@veloper
Copy link

veloper commented Aug 28, 2018

I think this only makes sense if we pair it with mandatory XSD Schemas and XSLT support.

@veloper
Copy link

veloper commented Aug 28, 2018

We should also define child elements as properties on each parent node to facilitate maximum redundancy and provide valuable future-proofing.

<field copyright="This field is property of ACME™ studios 2018." name="maxNuts" type="Money" value="30" >
      <copyright value="This field is property of ACME™ studios 2018.">
        This field is property of ACME™ studios 2018.
      </copyright>
      <name value="maxNuts">
        maxNuts
      </name>
      <type value="Money">
        Money
      </type>
      <value value="30">
        30
      </value>
</field>

@idanarye
Copy link
Author

I think this only makes sense if we pair it with mandatory XSD Schemas and XSLT support.

XSD? Sure. XSLT? The readme says:

Templates are too complicated, therefore Enterprise™ has only concat:

So obviously one should want to concat XML strings instead.

@veloper
Copy link

veloper commented Aug 28, 2018

So obviously one should want to concat XML strings instead.

I like the cut of your jib! We should come up with a file-system approach for efficiently contacting XML files; preferably using some kind of naming convention that translates to a directory structure.

@joaomilho
Copy link
Owner

First comment: dependency injected -> unnecessary dependency injected.

@claui
Copy link

claui commented Sep 7, 2018

The XML example needs more namespace

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants