Oop concept for 3 different objects

I have a supplier and a client object. So far so good.

I wish to send an email to the client, but to respect some good old fashion OOP concepts, it's not ok to add a send email method in supplier or client because the methods will break the SRP principle (among others). I should probably say: in both client and supplier I have some basic CRUD oper开发者_运维问答ations.

So what is the solution? A SupplierClientEmail class with a static method even if this class will probably never be touch or used again ? How do you deal with such concepts in your code?

---

Do you need to keep a record of the email? If not, then you don't really need an object for it. You could have an EmailService that has a method sendEmail(client, supplier) or whatever makes sense.

If you do need to keep track of emails, for example storing some sort of marker in the database to show an email was sent, you can have an Email class that has a reference to both client and supplier, with info like dateSent and any other info you need. That way you can always go back and see what email was sent to which client/suppliers. In this scheme Email knows about client and supplier, but those classes don't know about email.

---

If it truly is a method you will use once here, never again, and only with the supplier objects, it would only make sense to include it here as a method. In my personal opinion, a smattering of single-method classes is much more confusing and unwieldly than a simple addition of a private method.

Another option would be something like an EmailHelper class, that you would then throw this method into, as well as any other email-related loosely-fitting methods.