3 ms·

For example?

by atemerev 11y ago

For example?

to3m 11y ago
"GetMailPolicySingleton()->SetSendingMechanism(Email::SMTP)" ;)
- rescripting 11y ago
  Sometimes you're sending via SMTP, sometimes via MailGun. If you don't remember to call GetMailPolicySingleton()->SetSendingMechanism() before every email.send() you end up using whatever policy was set last.
- taspeotis 11y ago
  > Singleton What if two threads need to send mail via SMTP and Mailgun...
  - anton_gogolev 11y ago
    Singletons have nothing to do with reentrancy or lack thereof.
anon1385 11y ago
A 'sending mechanism' property on the email object that defaults to SMTP?
- smanzer 11y ago
  This. There may be other reasons to dislike the email.send() formulation, but it seems like the need to support other mail APIs could be handled relatively easily within this type of OO approach through the use of default values.
throwawaykf05 11y ago
I suppose you could add more methods, e.g sendEmailViaMailGun. But that results in the invoker having to have if-else logic (itself a code smell) for selecting which method to call, which is bad for SRP. You could try to fix that by encapsulating that logic into an EmailRouterStrategy class, but that's just another dependency you have to inject, which is not ideal according to TFA.
mistermann 11y ago
Couldn't you just add a new SendMethod optional parameter defaulted to the method that was used prior to the refactoring? No breaking API changes, no extensive manual refactoring of the entire codebase, as far as I can tell. This is how I always did refactoring for years, it's immediately obvious to support developers wtf is going on, and there's no requirement to have any "complicated" architecture on every single object in your entire application. Instead, the code largely resembles the simplicity of the real world being modeled. Is this approach is so dangerous (as we're constantly told) why has it never caused me any problems? Maybe I'm missing something but I've never read an article that explains what it is I'm missing in a way that clicks.
- anton_gogolev 11y ago
  > Couldn't you just add a new SendMethod optional parameter Adding an optional parameter to an already existing method is not always a backwards-compatible change. For example, in C# this will effectively change method signature and break API.
  - mistermann 11y ago
    Holy cow it seems it seems you're right: http://haacked.com/archive/2010/08/10/versioning-issues-with-optional-arguments.aspx/ http://haacked.com/archive/2010/08/10/versioning-issues-with... http://haacked.com/archive/2010/08/12/more-optional-versioning-fun.aspx/ http://haacked.com/archive/2010/08/12/more-optional-versioni... ...yet I've used this technique for years in VB.Net without issue....weird.

For example?

to3m 11y ago

"GetMailPolicySingleton()->SetSendingMechanism(Email::SMTP)" ;)

rescripting 11y ago
Sometimes you're sending via SMTP, sometimes via MailGun. If you don't remember to call GetMailPolicySingleton()->SetSendingMechanism() before every email.send() you end up using whatever policy was set last.
taspeotis 11y ago
> Singleton What if two threads need to send mail via SMTP and Mailgun...
- anton_gogolev 11y ago
  Singletons have nothing to do with reentrancy or lack thereof.

anon1385 11y ago

A 'sending mechanism' property on the email object that defaults to SMTP?

smanzer 11y ago
This. There may be other reasons to dislike the email.send() formulation, but it seems like the need to support other mail APIs could be handled relatively easily within this type of OO approach through the use of default values.

throwawaykf05 11y ago

I suppose you could add more methods, e.g sendEmailViaMailGun. But that results in the invoker having to have if-else logic (itself a code smell) for selecting which method to call, which is bad for SRP. You could try to fix that by encapsulating that logic into an EmailRouterStrategy class, but that's just another dependency you have to inject, which is not ideal according to TFA.

mistermann 11y ago

Couldn't you just add a new SendMethod optional parameter defaulted to the method that was used prior to the refactoring? No breaking API changes, no extensive manual refactoring of the entire codebase, as far as I can tell. This is how I always did refactoring for years, it's immediately obvious to support developers wtf is going on, and there's no requirement to have any "complicated" architecture on every single object in your entire application. Instead, the code largely resembles the simplicity of the real world being modeled. Is this approach is so dangerous (as we're constantly told) why has it never caused me any problems? Maybe I'm missing something but I've never read an article that explains what it is I'm missing in a way that clicks.

anton_gogolev 11y ago
> Couldn't you just add a new SendMethod optional parameter Adding an optional parameter to an already existing method is not always a backwards-compatible change. For example, in C# this will effectively change method signature and break API.
- mistermann 11y ago
  Holy cow it seems it seems you're right: http://haacked.com/archive/2010/08/10/versioning-issues-with-optional-arguments.aspx/ http://haacked.com/archive/2010/08/10/versioning-issues-with... http://haacked.com/archive/2010/08/12/more-optional-versioning-fun.aspx/ http://haacked.com/archive/2010/08/12/more-optional-versioni... ...yet I've used this technique for years in VB.Net without issue....weird.