Suggestions by Examples
Organisations though recognise adoption of Specification by Examples and Test Driven Development, as one of the proven ways, to develop and enhance features, they are desperate in adopting these models because of several reasons.
One of the prominent constraints is the design of their current systems.
The series of articles are Suggestions by Examples, to teams, those are in their pursuit of devising ways to progressively transform their systems.
The Transformation Plan
In my previous article, I introduced a facade layer to intercept any allocation request from a requestor, to either allocate a preferred task or to throw an exception; if we are unable to fulfil the request .
In this article, I will further improvise the design, by adopting a preferential producer and consumer strategy.
Here is a sequence diagram to aid in visualizing the progressive transformation of the design.
Outside-in on Allocator
I moved the responsibility of filling the allocation buffer from the Allocator to a new class TaskPool.
TaskPool is an instance of Runnable that encapsulates the allocation buffer which is now transformed into a Linked Blocking Queue.
The put method on the allocationBuffer has the built-in ability to wait for space to available if necessary.
Since, the Allocator delegates the responsibility, of producing and managing the Buffer, to the Task Pool, it becomes a highly cohesive class.
Verification of Transformation
Let me quickly verify, if our refactoring and transformations are free from any side-effects, by running our unit-test cases and specification tests
Cheers — Happy Greens!!!. The refactoring is safe.
Code for the Article
https://github.com/krsmanian1972/TaskAllocation
Yours humbly
I attempted to re-emphasis
- Specification by example is a means to capture the definition of done objectively
- Unit tests are instrumental to progressively evolve design
- TDD works well in the context of Legacy; by isolating the premise of change by introducing additional layers.
Thanks for reading.
