Calling all OOP architects

[captainccs]

The thread ‘Group commonly used application-wide methods in unit-test friendly way’ has given me a lot to think about, maybe I’m stuck in procedural mode. But how to get out of the rut? How to think about objects? A “button” is an object, you can do things to it and it will respond in certain ways. An email address is not an object, it’s value, a property of the account owner just like a telephone number or a name.

An email address can be valid or invalid. There are many methods of validating an email address, from less precise to more precise: you can check the formatting, you can look up the MX record, you can send an email to see if it bounces, you can confirm the email address if you get a reply from that address.

If you are dealing with a member, a subscriber, or an account, the email address is their property and you can use all the methods outlined above to verify the email address. If you have a mailing list the email address is still a “property” of the list but not as “proprietary” as in the first case and you can’t use all the validation methods. If you are dealing with a contact form, the visitor’s email address is still a “property” but even less “proprietary” that in the case of a mailing list but at least you have received direct authorization to send mail to that address.

For discussion purposes let’s call the validation anyone can do “secondary” because it’s not entirely conclusive and let’s call the validation that the membership scripts can do “primary” because they get owner feedback. If there are better terms for these things, please let me know.

According to the thread mentioned above, the email validation methods should be part of the membership class that really owns the email address property. But there can be many versions or variations of the membership class and the validation methods should be in some ancestral membership class which can be used by contact class and mailing list class as static methods, for example:

$myList->valid('Id15') = Membership::validateEmail($myList->getEmail('Id15'));

There would be a base “Membership class” which can be extended for specific membership needs like 'ForumMembership extends Membership"

This would eliminate the need for an email utility class. Each calling class would deal with errors in their particular way. This requires that the validation and feedback methods be separate.

Am I making sense?

[Jeff_Mott]

@captainccs

An email address is not an object, it’s value, a property of the account owner just like a telephone number or a name.

Though, to be clear, an email address could be an object. More generally, any noun could be an object. Whether we choose to make it a plain value or an object depends on the complexity of the value and on whether any logic needs to follow that value.

@captainccs

According to the thread mentioned above, the email validation methods should be part of the membership class that really owns the email address property. But there can be many versions or variations of the membership class and the validation methods should be in some ancestral membership class which can be used by contact class and mailing list class as static methods

You could create a separate class called, for example, EmailValidator. That way the logic is contained in one placed and can be reused by both your membership and contact classes.

[captainccs]

@Jeff_Mott

Though, to be clear, an email address could be an object. More generally, any noun could be an object. Whether we choose to make it a plain value or an object depends on the complexity of the value and on whether any logic needs to follow that value.

Yes, it could be but to what purpose if it has no methods? An email address is just data.

You could create a separate class called, for example, EmailValidator. That way the logic is contained in one placed and can be reused by both your membership and contact classes.

That’s how the other thread started and we were told that it was just procedural code dressed up as OOP.

[Jeff_Mott]

@captainccs

Yes, it could be but to what purpose if it has no methods? An email address is just data.

Absolutely. I didn’t mean to imply that it should. I just wanted to make sure you knew that it could. That any noun could be an object if it were necessary or useful.

@captainccs

That’s how the other thread started and we were told that it was just procedural code dressed up as OOP.

I’ll check what they said, but rest assured that an EmailValidator class is perfectly good OOP. In fact, today’s frameworks that showcase some of the highest quality OOP do exactly that. See the email validator from the Symfony validator component, and the [URL=“https://github.com/zendframework/zf2/blob/master/library/Zend/Validator/EmailAddress.php#L486”]email validator from Zend Framework.

[logic_earth]

Having Validation under its own object allows you to change the validation preformed without changing the objects that use it. Thus if there is a bug in the email validation you only have to change it in one place instead of a dozen. Validating an email is a single responsibility which does make an object. Having a single method makes it no less an object.

[captainccs]

@Jeff_Mott

Absolutely. I didn’t mean to imply that it should. I just wanted to make sure you knew that it could. That any noun could be an object if it were necessary or useful.

Shortly after reading your reply I realized that it makes perfect sense to have an ‘EmailAddress’ class capable of validating the address and providing other Email Address related services. Now other objects have the choice of properties, either the EmailAddress object or the EmailAddress string.

Having the choice is important because, for example, a mailing list with a 1000 addresses would take for ever to check each MX record.

This also solves the dependency issue since only the EmailAddress class needs do validation. Other classes only need to ask the EmailAddress object if it is valid or not.

It is also easy to localize or customize the verbose feedback by extending the EmailAddress class. For example EmailAddress_es would have the verbose feedback in Spanish.

BTW, I made a curious discovery, you can use variable variables to handle multiple email addresses:

$myEmail = 'mySelf<someone@domain.com>';
$$myEmail = new EmailAddress($myEmail);
 
$myEmail = 'my very own Self <someonelse@otherdomain.com>';
$$myEmail = new EmailAddress($myEmail);

The above creates two objects that can be accessed by setting $myEmail to the email address itself. I fear this is likely confusing in practice.

Thanks for the feedback, it’s been very useful!

[captainccs]

@logic_earth

Having Validation under its own object allows you to change the validation preformed without changing the objects that use it. Thus if there is a bug in the email validation you only have to change it in one place instead of a dozen. Validating an email is a single responsibility which does make an object. Having a single method makes it no less an object.

Thanks for the feedback. I see that there are many ways to skin the OOP cat! I decided on the EmailAddress class which gives me the most choices as I set out in my reply to Jeff.

[DoubleDee]

To stir things up a bit, an “Email” could contain many Attributes and Methods.

How about these…

Properties:

• ValidFormat (True|False)
• UserValidated (True|False)
• OwnerType (Customer|Employee|Personal)
• UsageContext (Work|Personal)
• Priority (Primary|Secondary)
• WebMail (e.g. Yahoo, Gmail, Hotmail = True)
• WantsSolicitations (True|False)
• LastUsed

Methods:

• validateFormat()
• validateOwner()
• linkToSecondaryEmail()

Just some ideas to show that an E-mail is far from just a “value”…

Sincerely,

Debbie

[Lemon_Juice]

@captainccs

BTW, I made a curious discovery, you can use variable variables to handle multiple email addresses:

$myEmail = 'mySelf<someone@domain.com>';
$$myEmail = new EmailAddress($myEmail);
 
$myEmail = 'my very own Self <someonelse@otherdomain.com>';
$$myEmail = new EmailAddress($myEmail);

These variable variables are VERY weird! :eek2:

[captainccs]

@Lemon_Juice

These variable variables are VERY weird! :eek2:

Yes, they are weird! First I tried to see if I could use the email address as the variable name and that is not allowed because it is a badly structured variable name. Then I tried the variable variable and, to my amazement, it worked. :magic:

The question is, when, where and why would you want to use it. :scratch:

[Lemon_Juice]

@captainccs

The question is, when, where and why would you want to use it. :scratch:

Perhaps when you want to make your fellow developers scratch their head?