Frequently Asked Questions - adarrivi/pascal-triangle GitHub Wiki

Why are you using @Configuration annotation for the application context instead of XML?

I always wanted to create a project without the XML configuration files. So this was a fantastic opportunity to do it.

Two different ways of calculating the pyramid weight?

Yes. I started first with the formula (FormulaWeightPascalTriangleCalculator.java), but I felt like cheating, as there were no algorithms in it. So I decided to implement also an algorithm approach (AlgorithmWeightPascalTriangleCalculator.java). That way I could also compare the results between them (WeightPascalTriangleComparsionIntegrationTest.java). Later on, I realized that the factorial operation in the formula approach was limiting the pyramid size to 30 levels, so it was good I developed both :)

Why HumanPyramid object? Was it really necessary? Why don't call directly any of the WeightPascalTriangleCalculator implementations?

Yes, I could remove HumanPyramid. But without it I felt the whole application not very Object-Oriented and too much Functional-Programming oriented (with its stateless controllers, components and services...). So I thought it was a good idea to have actually a HumanPyramid object where you can change its weight at runtime if necessary. When the model and the logic will get more complex, it will pay off.

Why did you add caching?

Because it is the optimal situation for it: a method invocation that will return the same value for a given entry :). The weight calculation doesn't take a long for small pyramids, but for big ones (6000+) it could take several seconds. Caching the service calls will improve dramatically the response time.

In the view you have controllerFactories, controllers, handlers, bootstrap providers, etc... Aren't you over complicating the application?

Well, in a way is true. The architecture could be simpler. But I tried to build a framework easily scalable. For example you might want to process another request. It will be as easy as add a new controller like:

@Controller("/numberOfHumans")
public class NumberOfHumansController implements HttpRequestController {

	@Override
	public HttpResponse processRequest(HttpRequest request,
			Map<String, List<String>> parameters) {
        (...)

And that's all; no other class (or XML file) will need to be modified.

Have you added unit testing?

Yes I have. In fact there is a 100% unit coverage :)

But this could be both a blessing and a curse. See next question.

Why are your unit tests like: given...when...then...()? It is not too verbose?

Yes, unfortunately it is a bit.

From my experience, the real problem with unit testing are how easy they are to understand and how easy they are to refactor. Having to refactor very big projects with lots of unit tests where there is no way to understand what are they testing is one of the hardest/dangerous/annoying/stupid things any developer can do.

So the given/when/then methodology is just a way to try to minimize these problems.

Are the unit tests impacting your application architecture?

Yes they do. To archive 100% of unit test coverage with small and simple unit tests you need to design three times:

• Design your application.
• Design your tests (not much to design in this project as it is very small, but something could be done :) )
• Design you application to be easily unit tested.

It requires time and effort. And it might not be for all the projects/companies/teams/etc... But I believe it pays off in the medium/long term in terms of project profitability (less bugs and resources required). And also is a fantastic way to learn and practice!

Any special techniques for unit testing?

Not really. I just used mocked objects and stub classes (only once). But for example I needed to define providers like ServerBootstrapProvider.java to be able to easily mock and check the functionality. This is a nice example about how test can affect your application.