This question already has an answer here:
Let's say that I have a class representing the Neural Network. The neural network is composed of three bigger units: a subpart_1, subpart_2 and subpart_3, being called in such a way, that the output of one part is an input to the next one. The parts are itself Neural Networks with the same basic interface. In my current approach, each of this part is created inside the constructor, the __init__method of my class, and I am passing in the configuration parameters. It inherits from some framework NeuralNetwork class which gives me access to some common interface like forward/backward methods. It looks like this:
class NeuralNetwork(framework.NeuralNetworkBase): def __init__(self, subp_1_params, subp_2_params, subp_3_params) super(...) self.subpart_1 = Subpart1Class(subp_1_params) self.subpart_2 = Subpart2Class(subp_2_params) self.subpart_3 = Subpart3Class(subp_3_params) . . . def forward(self, input): <use the subparts on the data in some way>
You can imagine the SubpartXClasses being implemented in a similar manner. Now, I have been recently reading more on Unit Testing and Unit Testing-friendly design and in particular I have stumbled upon the blog post:
in which the author claims, that unless the fields of the class are not plain data structures, they should not be created inside the constructor and instead passed as the constructor arguments to allow for the maximally decoupled and unit testing-friendly design. The tone of that posts is really strict but it is also quite old. So now my question: In a scenario like this, would it be a straight up better idea to create the objects externally, through some factory, and pass a ready and configured objects into the constructor to register them to my NeuralNetwork class? From my point of view, the current approach seems more natural (actually the framework I am using also promotes this approach), but after reading that blog posts I started having some doubts.