Move build_from_file to a factory class #6
Conversation
|
I think the refactoring is ok, but I would keep the Contracts.build_from_file method and simply make it use the factory. The methods in the Contracts module are supposed to be the public interface of the gem, and anything else should be considered private (as in not used) from the gem's client perspective. This is a common pattern and allows us to change the gem internals while keeping a consistent public interface. |
|
Sounds fare not removing Contracts.build_from_file to keep it consistent and to have only one public interface, and just delegating the task to ContractFactory. |
|
Changes Unknown when pulling fff05cbaf25a2fd4ee7296b82ee7dee8e41786e0 on jesusmercado:use_contract_factory into * on thoughtworks:master*. |
The method build_from_file constructing a new Contract and is not related with the other methods in Pacto module. The idea is to separate what is construction of a contract from what is using the contract. Keeping consistency with the idea that the module Pacto is the public interface that hides the details of the implementation. In this case ContractFactory is a implementation detail that is not needed to expose to the public interface.
|
Changes Unknown when pulling 249c544 on jesusmercado:use_contract_factory into * on thoughtworks:master*. |
Move build_from_file to a factory class
4 participants
This
build_from_filemethod is constructing a newContractand is notrelated with the other methods in the module
Contracts.The idea is to separate what is construction of a
Contractfrom what isusing the contract.
The way the gem will be used has to be changed from:
Contracts.build_from_file(path, host)to:Contracts::ContractFactory.build_from_file(path, host)