3 added 21 characters in body
source | link

The argument of less test initialization boiletplate is valid, but there are other concerns that must be taken into account when answering. First of all, you have to answer a question:

Do I want my class to be instantiable only with reflection?

Using field injections means narrowing down compatibility of a class to dependency injection environments that instantiate objects using reflection and support these particular injection annotations. Some platforms based on Java language do not even support reflection (GWT), so field‑injected class will not be compatible with them.

Second issue is performance. A constructor call (direct or by reflection) is always faster than a bunch of reflection field assignments. Dependency injection frameworks must use reflection analysis to build dependency tree and create reflection constructors. This process causes additional performance hit.

Performance affects maintainability. If each test suite must be run in some sort of dependency injection container, a test run of few thousands unit tests may last tens of minutes. Depending of size of a code base, this may be an issue.

This all rises many new questions:

  1. What is the probability of using parts of the code on another platform?
  2. How many unit tests will be written?
  3. How fast do I need to prepare each new release?
  4. ...

Generally, the bigger and more important a project is, the more significant these factors are. Also, Quality-wise, we would generally like to the keep the code high on compatiblity, testability and maintainability. From the philosophical point of view, field injection breaks encapsulation, which is one of four fundamentals of object-oriented programming, which is the main paradigm of Java.

Many, many arguments against field injection.

The argument of less test initialization boiletplate is valid, but there are other concerns that must be taken into account when answering question:

Do I want my class to be instantiable only with reflection?

Using field injections means narrowing down compatibility of a class to dependency injection environments that instantiate objects using reflection and support these particular injection annotations. Some platforms based on Java language do not even support reflection (GWT), so field‑injected class will not be compatible with them.

Second issue is performance. A constructor call (direct or by reflection) is always faster than a bunch of reflection field assignments. Dependency injection frameworks must use reflection analysis to build dependency tree and create reflection constructors. This process causes additional performance hit.

Performance affects maintainability. If each test suite must be run in some sort of dependency injection container, a test run of few thousands unit tests may last tens of minutes. Depending of size of a code base, this may be an issue.

This all rises many new questions:

  1. What is the probability of using parts of the code on another platform?
  2. How many unit tests will be written?
  3. How fast do I need to prepare each new release?
  4. ...

Generally, the bigger and more important a project is, the more significant these factors are. Also, Quality-wise, we would generally like to the keep the code high on compatiblity, testability and maintainability. From the philosophical point of view, field injection breaks encapsulation, which is one of four fundamentals of object-oriented programming, which is the main paradigm of Java.

Many, many arguments against field injection.

The argument of less test initialization boiletplate is valid, but there are other concerns that must be taken into account. First of all, you have to answer a question:

Do I want my class to be instantiable only with reflection?

Using field injections means narrowing down compatibility of a class to dependency injection environments that instantiate objects using reflection and support these particular injection annotations. Some platforms based on Java language do not even support reflection (GWT), so field‑injected class will not be compatible with them.

Second issue is performance. A constructor call (direct or by reflection) is always faster than a bunch of reflection field assignments. Dependency injection frameworks must use reflection analysis to build dependency tree and create reflection constructors. This process causes additional performance hit.

Performance affects maintainability. If each test suite must be run in some sort of dependency injection container, a test run of few thousands unit tests may last tens of minutes. Depending of size of a code base, this may be an issue.

This all rises many new questions:

  1. What is the probability of using parts of the code on another platform?
  2. How many unit tests will be written?
  3. How fast do I need to prepare each new release?
  4. ...

Generally, the bigger and more important a project is, the more significant these factors are. Also, Quality-wise, we would generally like to the keep the code high on compatiblity, testability and maintainability. From the philosophical point of view, field injection breaks encapsulation, which is one of four fundamentals of object-oriented programming, which is the main paradigm of Java.

Many, many arguments against field injection.

2 added 2 characters in body
source | link

The argument of less test initialization boiletplate is valid, but there are other concerns that must be taken into account when answering question:

Do I want my class to be instantiable only with reflection?

Using field injections means narrowing down compatibility of a class to dependency injection environments that instantiate objects using reflection and support these particular injection annotations. Some platforms based on Java language do not even support reflection (GWT), so field‑injected class will not be compatible with itthem.

Second issue is performance. A constructor call (direct or by reflection) is always faster than a bunch of reflection field assignments. Dependency injection frameworks must use reflection analysis to build dependency tree and create reflection constructors. This process causes additional performance hit.

Performance affects maintainability. If each test suite must be run in some sort of dependency injection container, a test run of few thousands unit tests may last tens of minutes. Depending of size of a code base, this may be an issue.

This all rises many new questions:

  1. What is the probability of using parts of the code on another platform?
  2. How many unit tests will be written?
  3. How fast do I need to prepare each new release?
  4. ...

Generally, the bigger and more important a project is, the more significant these factors are. Also, Quality-wise, we would generally like to the keep the code high on compatiblity, testability and maintainability. From the philosophical point of view, field injection breaks encapsulation, which is one of four fundamentals of object-oriented programming, which is the main paradigm of Java.

Many, many arguments against field injection.

The argument of less test initialization boiletplate is valid, but there are other concerns that must be taken into account when answering question:

Do I want my class to be instantiable only with reflection?

Using field injections means narrowing down compatibility of a class to dependency injection environments that instantiate objects using reflection and support these particular injection annotations. Some platforms based on Java language do not even support reflection (GWT), so field‑injected class will not be compatible with it.

Second issue is performance. A constructor call (direct or by reflection) is always faster than a bunch of reflection field assignments. Dependency injection frameworks must use reflection analysis to build dependency tree and create reflection constructors. This process causes additional performance hit.

Performance affects maintainability. If each test suite must be run in some sort of dependency injection container, a test run of few thousands unit tests may last tens of minutes. Depending of size of a code base, this may be an issue.

This all rises many new questions:

  1. What is the probability of using parts of the code on another platform?
  2. How many unit tests will be written?
  3. How fast do I need to prepare each new release?
  4. ...

Generally, the bigger and more important a project is, the more significant these factors are. Also, Quality-wise, we would generally like to the keep the code high on compatiblity, testability and maintainability. From the philosophical point of view, field injection breaks encapsulation, which is one of four fundamentals of object-oriented programming, which is the main paradigm of Java.

Many, many arguments against field injection.

The argument of less test initialization boiletplate is valid, but there are other concerns that must be taken into account when answering question:

Do I want my class to be instantiable only with reflection?

Using field injections means narrowing down compatibility of a class to dependency injection environments that instantiate objects using reflection and support these particular injection annotations. Some platforms based on Java language do not even support reflection (GWT), so field‑injected class will not be compatible with them.

Second issue is performance. A constructor call (direct or by reflection) is always faster than a bunch of reflection field assignments. Dependency injection frameworks must use reflection analysis to build dependency tree and create reflection constructors. This process causes additional performance hit.

Performance affects maintainability. If each test suite must be run in some sort of dependency injection container, a test run of few thousands unit tests may last tens of minutes. Depending of size of a code base, this may be an issue.

This all rises many new questions:

  1. What is the probability of using parts of the code on another platform?
  2. How many unit tests will be written?
  3. How fast do I need to prepare each new release?
  4. ...

Generally, the bigger and more important a project is, the more significant these factors are. Also, Quality-wise, we would generally like to the keep the code high on compatiblity, testability and maintainability. From the philosophical point of view, field injection breaks encapsulation, which is one of four fundamentals of object-oriented programming, which is the main paradigm of Java.

Many, many arguments against field injection.

1
source | link

The argument of less test initialization boiletplate is valid, but there are other concerns that must be taken into account when answering question:

Do I want my class to be instantiable only with reflection?

Using field injections means narrowing down compatibility of a class to dependency injection environments that instantiate objects using reflection and support these particular injection annotations. Some platforms based on Java language do not even support reflection (GWT), so field‑injected class will not be compatible with it.

Second issue is performance. A constructor call (direct or by reflection) is always faster than a bunch of reflection field assignments. Dependency injection frameworks must use reflection analysis to build dependency tree and create reflection constructors. This process causes additional performance hit.

Performance affects maintainability. If each test suite must be run in some sort of dependency injection container, a test run of few thousands unit tests may last tens of minutes. Depending of size of a code base, this may be an issue.

This all rises many new questions:

  1. What is the probability of using parts of the code on another platform?
  2. How many unit tests will be written?
  3. How fast do I need to prepare each new release?
  4. ...

Generally, the bigger and more important a project is, the more significant these factors are. Also, Quality-wise, we would generally like to the keep the code high on compatiblity, testability and maintainability. From the philosophical point of view, field injection breaks encapsulation, which is one of four fundamentals of object-oriented programming, which is the main paradigm of Java.

Many, many arguments against field injection.