SitePoint Sponsor

User Tag List

Results 1 to 11 of 11
  1. #1
    SitePoint Evangelist captainccs's Avatar
    Join Date
    Mar 2004
    Location
    Caracas, Venezuela
    Posts
    516
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)

    Talking Calling all OOP architects...

    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:

    PHP Code:
    $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?
    Denny Schlesinger
    web services

  2. #2
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,246
    Mentioned
    16 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by captainccs View Post
    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.

    Quote Originally Posted by captainccs View Post
    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.
    "First make it work. Then make it better."

  3. #3
    SitePoint Evangelist captainccs's Avatar
    Join Date
    Mar 2004
    Location
    Caracas, Venezuela
    Posts
    516
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Jeff Mott View Post
    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.
    Denny Schlesinger
    web services

  4. #4
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,246
    Mentioned
    16 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by captainccs View Post
    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.

    Quote Originally Posted by captainccs View Post
    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 email validator from Zend Framework.
    "First make it work. Then make it better."

  5. #5
    . shoooo... silver trophy logic_earth's Avatar
    Join Date
    Oct 2005
    Location
    CA
    Posts
    9,013
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)
    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.
    Logic without the fatal effects.
    All code snippets are licensed under WTFPL.


  6. #6
    SitePoint Evangelist captainccs's Avatar
    Join Date
    Mar 2004
    Location
    Caracas, Venezuela
    Posts
    516
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Jeff Mott View Post
    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:
    PHP Code:
    $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!
    Denny Schlesinger
    web services

  7. #7
    SitePoint Evangelist captainccs's Avatar
    Join Date
    Mar 2004
    Location
    Caracas, Venezuela
    Posts
    516
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by logic_earth View Post
    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.
    Denny Schlesinger
    web services

  8. #8
    SitePoint Wizard DoubleDee's Avatar
    Join Date
    Aug 2010
    Location
    Arizona
    Posts
    3,756
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    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

  9. #9
    SitePoint Guru bronze trophy
    Join Date
    Dec 2003
    Location
    Poland
    Posts
    930
    Mentioned
    7 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by captainccs View Post
    BTW, I made a curious discovery, you can use variable variables to handle multiple email addresses:
    PHP Code:
    $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!

  10. #10
    SitePoint Evangelist captainccs's Avatar
    Join Date
    Mar 2004
    Location
    Caracas, Venezuela
    Posts
    516
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Lemon Juice View Post
    These variable variables are VERY weird!
    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.

    The question is, when, where and why would you want to use it.
    Denny Schlesinger
    web services

  11. #11
    SitePoint Guru bronze trophy
    Join Date
    Dec 2003
    Location
    Poland
    Posts
    930
    Mentioned
    7 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by captainccs View Post
    The question is, when, where and why would you want to use it.
    Perhaps when you want to make your fellow developers scratch their head?


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •