2 Replies Latest reply: Oct 15, 2013 11:54 AM by Aegis Kleais RSS

    OOP - The scale of method functionality.

    Aegis Kleais Community Member
    Aegis Kleais Oct 14, 2013 12:03 PM

      Imagine I have 2 objects.  A 'user' object, responsible for handling user functionality, and a 'security' object, responsible for handling authorization and authentication.

       

      I would like to hear pros and cons to my current belief of the following.

       

      I have a method in the security object called 'canAccess'.  You can pass it 2 optional arguments, a userID and a pageID.  If no userID is passed, it infers the current user object's ID (which is tied to the session scope), and if no pageID is provided, it infers the current request object's page ID (which is tied to the request scope)

       

      At first, I thought this might be a security risk, because code could pass a userID that did not belong to them, even though all this method does is determine if the user provided has Access rights to the page provided.

       

      I've been thinking about this for quite some time, and my current belief is that this is OK as LONG as the method is not set for remote access (and it is not).  My application supports installable 'modules' which others can code, plugs into my framework, and the pages in those modules could invoke this method and pass whatever user/page ID combo they want to it, but ultimately, it's up to the responsibility of the person who has the core application/framework to approve/inspect any modules they install.

       

      Does this sound as if I am properly assessing the scalability of my object methods?  Any concerns you can bring to light I haven't hit on?

      • 379 Views
      • Tags:
        • 1. Re: OOP - The scale of method functionality.
          duncancumming Community Member
          duncancumming Oct 15, 2013 1:20 AM (in response to Aegis Kleais)

          Firstly, you say your canAccess method has 2 optional arguments for the userID and pageID.  This doesn't really make sense, those arguments should both be mandatory, as the function won't work without them, right?  I'm guessing you're doing something like:

           

          <cfargument name="userID" required="false" default="#session.userID#">

          <cfargument name="pageID" required="false" default="#request.pageID#">

           

          If so, this isn't good OOP because you want to decouple your CFC from referencing any shared scopes.  This is a good article about the basic principles involved:

          http://www.bryantwebconsulting.com/blog/index.cfm/2009/7/9/OO-Principles-Encapsulation-and -Decoupling

           

          Instead your code should be make those arguments required without defaults.

           

          Secondly, I don't see any problem with the basic idea of defaulting to the session ID or the page ID, however I'd move that logic out of your CFC (if that is how you're doing it), and into however you call that function. 

          • 2. Re: OOP - The scale of method functionality.
            Aegis Kleais Community Member
            Aegis Kleais Oct 15, 2013 11:54 AM (in response to duncancumming)

            Thanks Duncan!

             

            An interesting concept of OOP; I had never heard of decoupling, but after hearing your explanation, that makes sense.  Rather than the "benefit" of being able to optionally provide an argument, and have it default to something, it should instead, always rely on data that is passed into it.  Excellent point!

             

            Thanks for the article link!

             

            This OOP stuff is a really great methodology.