6 Replies Latest reply on Sep 20, 2007 7:43 PM by brado77

    Flex component encapsuion

    brado77 Level 1
      Hello,

      I have a question regarding the design of Flex components. Those of us coming from the OO programming world probably all very quickly notice that components in the Flex API pretty much ignore the fundamental principle of object-oriented programming of encapsulation. Virtually all exposed properties on Flex components are public member variables (or properties, if you want to call them that). Additionally, components created declaratively with MXML seem to expose all contained declarative subcomponents by default. I wanted to ask if there is any particular technical reason, other than the perception of convenience, that this is done. Does this have some kind of negative effect on databinding, or something along these lines?

      I am very curious, as using publicly scoped member variables is generally accepted as poor object design, the reasons which I will not go into here. I'm really trying to get at the reasons why exposing public properties is a *good* idea. If there is a worthwhile technical reason, then that's one thing. But if otherwise, I'd like to design my components according to the long-established sound principles of object design.

      Thanks -- you input is valued.

      Cheers,

      Brad
        • 1. Re: Flex component encapsuion
          Senor_Roberto Level 1
          I think you'll find if you dig a little deeper, that those publically scoped member variables are actually virtual properties, similar to C#. So:

          public class TestMembers {

          // This is the private member
          private var _encapsulatedMemberVariable:String;

          // This is the public GET accessor
          public function get member () : String {
          return this.encapsulatedMemberVariable;
          }

          // this is the public SET accessor
          public function set member (value:String) : void {
          this.encapsulatedMemberVariable = value;
          }

          }

          The class can then be used like:

          var test:TestMembers = new TestMembers();

          test.member = "X";

          trace(test.member);


          So in this regard, the encapsulation is maintained, just not via methods (a la Java getX,setX) instead by property constructs (like C#). I agree that exposing a member variable publically is poor design.

          If you dig through the source code for the Flex API you'll find most public properties are done this way and encapsulate the internal member variable.

          Whether property constructs are better getX/setX methods are another debate :)
          • 2. Re: Flex component encapsuion
            brado77 Level 1
            Roberto --

            That's about the best answer I could have received....thank you. I haven't read the Flex API source code, so I was unaware of that. As a follow up question, is it possible to limit the visibility of subcomponents declaratively added to an MXML file, so that external objects cannot access declarative components by ID?

            Thanks again for your help!

            Brad
            • 3. Flex component encapsuion
              Senor_Roberto Level 1
              This is an excellent question.

              I assume you mean this in the context of building a discrete component, so that external users can't fiddle with internals and only access the component through a defined interface contract.

              The answer is probably not. According to the documentation, child components must be declared as public if you're writing it in ActionScript. I assume this limitation is the same as declarative MXML sub components.

              If you look at the source code generated from MXML, all sub components are public.

              I wonder what happens if you change the generated source code to private or protected? :)

              Edit:

              Actually, I checked some other documentation and on this page:

              http://livedocs.adobe.com/flex/201/html/wwhelp/wwhimpl/common/html/wwhelp.htm?context=Live Docs_Book_Parts&file=creating_comps_041_1.html

              There is an example near the bottom where they are declaring member components as private and it says they are not accessible to MXML. This is news to me and I think it's a good thing to do (depending on the component).

              This doesn't help you with defining MXML sub components privately, but at least you know you have an option.

              Cheers

              • 4. Re: Flex component encapsuion
                brado77 Level 1
                quote:

                Originally posted by: Senor Roberto
                According to the documentation, child components must be declared as public if you're writing it in ActionScript. I assume this limitation is the same as declarative MXML sub components.



                Unless I misunderstand the statement, I don't know if this is correct. Perhaps it is, but I'm not sure. If you don't assign an ID to a child component, and just add a newly created child to the component (without declaring it at all) I think it can only be accessed via child position in the collection.

                Interesting, I wonder what the rule is on that.

                Brad
                • 5. Re: Flex component encapsuion
                  Senor_Roberto Level 1
                  You are right - see my edit.

                  The only time the child components must be public is when you want to access them in your custom component class as a member.
                  • 6. Re: Flex component encapsuion
                    brado77 Level 1
                    Thanks Roberto!