I don't think we need a KernelTestCase for the twitter service anymore. Feels like we should do this elsewhere.
This stronly reflects my opinion on writing software, the code that already existed was fine, so feel free to destroy this code.
Why?
Because set/getTwitterClient is removed from the class. A developer using the service will not be tempted to use the underlying client, because he has no access to it. Instead he will create a nice function in the service that reflects the use case (s)he will need.
Why?
Well if the user would use the underlying TwitterClient (in this case a pretty nice one :)) we are binding our bussiness/domain logic to the framework.
Why?
Well by binding your domain to a specific framework/lib you will lose the ability to update to newer/beter/feature-richer lib.
So why remove the $count parameter
We do not have any usecases that would require us to fetch more. However some feature creaping boss (@caroga for example :P) Might force a feature/use-case upon us that requires a different parameter. In that case we made a wrong assumption that this would be future proof and we are required to break backwards compatibility without ever using the functionaltity.
Caroga
commented
8 years ago
I don't think we need a KernelTestCase for the twitter service anymore. Feels like we should do this elsewhere.
This stronly reflects my opinion on writing software, the code that already existed was fine, so feel free to destroy this code.
Why?
Because set/getTwitterClient is removed from the class. A developer using the service will not be tempted to use the underlying client, because he has no access to it. Instead he will create a nice function in the service that reflects the use case (s)he will need.
Why?
Well if the user would use the underlying TwitterClient (in this case a pretty nice one :)) we are binding our bussiness/domain logic to the framework.
Why?
Well by binding your domain to a specific framework/lib you will lose the ability to update to newer/beter/feature-richer lib.
So why remove the
$countparameterWe do not have any usecases that would require us to fetch more. However some feature creaping boss (@caroga for example :P) Might force a feature/use-case upon us that requires a different parameter. In that case we made a wrong assumption that this would be future proof and we are required to break backwards compatibility without ever using the functionaltity.
Implement a freaking cache already
Uuuhm I guess you're right.