Coupling concerns

[Trismegiste]

Hello, this lib is great !

But since relying on concrete class when type-hinting parameters is a bad practice (LSP), I've added an interface to this service for loose-coupling.

In the process I've added some missing visibility keywords to follow PSR-2

Hope this helps 🍻

[jd327]

Hi @Trismegiste, haven't forgotten about your PR, just been traveling. Need some time to review.

[Trismegiste]

no problem, thanx.
Perhaps you might want to change some very generic phpdoc I've added.

[jd327]

Is there a certain reason the interface is called "HashGenerator"? If not, I think "iHashids" or "HashidsInterface" might be more appropriate / simpler? (looking at http://php.net/manual/en/language.oop5.interfaces.php)

[Trismegiste]

iHashids, definitely not, according PSR-0/2, classname must be in CamelCase.

HashidsInterface is a good option but I'm not fond of redundancy. The responsibility of the contract is for generating hashes so HashGenerator, I'm not good at finding names 😺

Say, for example, someone else wants to substitute your service by his, he can implement HashGenerator, the interface name speaks for itself.

[jd327]

Great, thanks for the pull request + explanation. Version bumped up + pushed out.

[jd327]

@Trismegiste, I still have to adjust the examples in the repo, because in their current state there's a require missing for the generator. Is there a good way to require the generator file to make the test files work (without doing the actual "require_once")?

[Trismegiste]

Hello,

The best (and only) way to load required files is the autoloader generated from Composer.

I make a PR for this, my bad