I'm attempting to design a class that is to be instantiated through the use of a static method, something like newInstance(param1, param2)
. The reason behind this is that 2 of the 4 parameters it takes are from the same package, but I want to hide them from the public.
In order to achieve this, I made the constructor private. However, I just realize that I am now unable to pass the 2 parameters on my tests.
It goes like this
class Foo {
private constructor(p1, p2, p3, p4) {}
public static newInstance(p1, p2) {
p3 = new p3;
p4 = new p4;
return new static(p1, p2, p3, p4);
}
}
Obviously my design is wrong, but I can't think of a way to abstract the existence of p3 and p4 to other developers, while still being able to pass them as dependency in order to apply dependency inversion.
What design can I use to achieve this? Maybe I should just create a FooFactory
and document that they're supposed to use that...
I'm basically writing an SDK for an REST API. These REST API is not designed by me nor my company (so I can't make the REST API follow industry standards), and it has a very complicated authentication mechanism. It is complicated enough that I want to achieve the following:
- Break it down into little testable components, so that it's easier to maintain, and the other developers are able to work with just the endpoints the SDK expose, which encapsulate the domain model.
- Abstract the construction of the dependency graph for the SDK, so that they can just use the
CompanyClient
class and call business domain methods likegetCustomerList
. - Completely abstract the construction of the customized headers, parameters, etc... of the HTTP request.
I agree this work as a unit so it make sense just to test the CompanyAPI
class by itself; However, that would make it difficult to maintain the sub-mechanisms that are needed to make it work.
In summary, by breaking it down into smaller pieces, it's easy to test that every mechanism works according to the specification.
For this reason I want just to expose 2 parameters for the library users. They don't need to know the underlying implementation. However, I DO need to test and since the dependencies include a HTTP client, I need to inject mock objects.