Refer only what you need

v1.1.2 Changes
Achievements

• Created a new interface to represent the dependencies needed only by BusinessService. Anything added to SuperFactory will now be hidden from BusinessService.
• Only the reference to SuperFactory inside BusinessService changed. No impact on any other code.

Issues

• There's a 'human' limit to how many dependency interfaces you can create.

Plans

• Let's discuss the state of Dutdip, the opportunities and the challenges.

Adding Service to SuperFactory

v1.1.1 Changes
Achievements

• Reorganized code to separate business code from DI code
• BusinessService itself is initialized from the factory.
• SuperFactory becomes your DI container, the single point of initializing everything in your ecosystem.

Issues

• SuperFactory itself was passed as a parameter to the NewBusinessService method. (This is something we will discuss later.)

Plans

• Change BusinessServiceFactory to use only what it needs.

Adding New Dependency

Compare Changes
Achievements:

• Code changes:
  • Resurrected AnotherDal and created AnotherDalFactory
  • Added AnotherDalFactory to SuperFactory and AnotherDalFactoryImpl to superFactoryImpl
  • Updated BusinessService to call AnotherDal
• Changes to SuperFactory and superFactoryImpl were minimal; one line each.
• No impact on main, and no impact on service initialization.

Issues:

• Does BusinessService need to see SuperFactory? Or should it see only the dependencies it needs?

Plans

• Add BusinessService itself to the SuperFactory & change its initialization
• Change BusinessService intialization to work without SuperFactory

Introducing DUTDIP

v1.0 Compare Changes
Achievements:

• In earlier commits, removed some unwanted code and for now, commented the second dependency.
• Since we are re-wiring the DI, this commit has several changes.
• List of Design changes
  • Created Interface for Factory in model package. Embedded this in the SuperFactory interface.
  • Factory implementation is in the dependency package. This implementation is public.
  • Main package creates a super-factory implementation embedding this factory. The main method does a simple initialization of this structure.
  • BusinessService is redesigned to accept the super-factory by its interface, and uses it to create the dependency.

Plans:

• Add a new dependency: resurrecting AnotherDal

Function Challenges

v0.9.1 Compare Changes
Achievements

• Attempted inheritance of individual factory functions

Issues

• Factories become reusable (a little bit) if they return structures itself, instead of pointers. However, explicit initialization was required in the composite All-Factory structure.
• AllFactory can not substitute FunctionFactory even though both support identical method signatures. Such substitution is possible only through interface implementations. However, function types can't be members of an interface. Nor can function types help implement an interface in a structure without a wrapper method.
• Factories are static methods (a package method is a static method). And static is not 'design-friendly'. Static elements do not adapt to other structures easily. Often, static elements have been wrapped in a separate layer to become compatibility with other components, like the Adapter Pattern. Static elements solve the problem today, but create problems tomorrow.
  • In the event that a static factory method needs to store some state, it will have to rely on static/ package variables. Static variables never get garbage collected, and it is very difficult to subject them to life cycle management. There are thread-safety constraints that must be addressed.
• While the factory method is defined in the respective package, orchestration in the main package is a bit more than what I'd want to do, specially the part of explicit assignment to structure member.

Plans

• In the next attempt, I will try to create factories in the form of reusable structures, and we will then discuss some interesting, long-term, design benefits of these changes.

Function Factory Again

v0.9 Compare
Achievements

• There was no change in the signature of the NewBusinessService Function. As a result, there was no breaking change in its invocation. If you have ever created a Request class to handle the infinite parameters that you were passing to a method, you know why this happened.
• The change was much simpler to implement compared to v0.6 because there were no breaking changes.
• The dependencies are initialized only when required in the workflow.

Issues

• Functions are not as flexible or re-usable as Structures.

Plans

• We will try to discover different ways to check re-usability of the Factory Function.

Function Factory

Compare
Achievements

• Created a structure which encapsulates the Factories that BusinessService is interested in.
• Main method creates the Function Factory. Main method, or rather, the Layer housing the Main Method, is the appropriate place for orchestration. It is responsible for creating the right environment in which the service must be executed.

Issues

• Currently, NewBusinessService has access to the entire factory, not just the function that it needs. I don't think its a great idea that NewBusinessService sees more than it needs to.

Plans

• Let us first check the impact of a new dependency on this piece of code.

Factory Not Instance

v0.7 Factory Not Instance
Achievements

• Passed the "New" function as a parameter.
• Service invokes the function to create an instance of the dependency only when it wants to consume the dependency.
• Dependency is now initialized after the Service, and only if required.

Issues

• We still face the challenge of changes in dependencies. If another dependency is added, it leads to breaking changes in code. (I will not create an example for this issue, as it is the same as described in v0.6).
• There is nothing wrong in passing functions. Functions are first class members of the codebase. However, functions don't lend themselves to easy reuse. Code constructs such as Inheritance and Composition do.

Plans

• To prevent breaking changes in the method signature, we must gather the parameters into a single element. Let us check if we can put factory functions in a structure.

Changes in Dependency Leads to Breaking Changes

Compare
Achievements

• A new dependency is introduced in the same manner as the existing one.
• It is passed as a parameter to the NewBusinessService method.

Issues

• With the signature of the NewBusinessService changing, it leads to breaking changes at every location that it is consumed.
• 'main' function in the sample code had to be fixed to align with the new signature.
• As above, dependencies are initialized before the service, even if they are not utilized.

Plans

• One mechanism to overcome the 2 challenges explained in v0.5 and v0.6 is pass the "New" function itself as a parameter.
• In this sense, the Service has access to the Dependency factory (instead of an instance of a Dependency).
• We will revert back to a single dependency to showcase this solution.

Unexpected Dependency Initialization

Unexpected Dependency Initialization
Achievements

• BusinessService interface was updated to take a bool parameter, which dictates invocation of DAL.
• Some print statements were added to reflect behavior of the code.

Issues

• According to the order of output statements, the dependency is getting initialized before the Service itself. That just doesn't sound right at all.
• Also, the second invocation of the BusinessMethod1 shows that even though the dependency was not invoked, it was certainly initialized.

Plans

• Let us now understand the challenge of a new dependency.