SitePoint Sponsor

User Tag List

View Poll Results: Do you use setters and getters to attributes of a class within that class?

Voters
123. You may not vote on this poll
  • yes

    58 47.15%
  • no

    38 30.89%
  • undecided

    12 9.76%
  • what are you talking about? xD

    15 12.20%
Page 2 of 4 FirstFirst 1234 LastLast
Results 26 to 50 of 93
  1. #26
    throw me a bone ... now bonefry's Avatar
    Join Date
    Nov 2004
    Location
    Romania
    Posts
    848
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    My point was neither that the PHP5 system was not flexible, nor that you or I or anyone else doesn't like it. My point was that because __get()/__set() are error handlers (called only when the property does not exist) rather than accessor handlers they are not a complete accessor solution.
    Oh, sorry I have missunderstood you.

    But still ... PHP does not share the message passing mechanism Smaltalk has.

    So it is logical to first check for real properties and only after that to execute __set/__get. And I really don't see why this bothers you. Python behaves in the same way (as I recall). Ruby only has method calls and properties are emulated. And it's better and more flexible that in C#. Should I mention Java ?

    If the reverse was true and __set/__get were called first, then you had to be very carefull about exceptions/errors throwed, no ? Plus, you would've had to depend on an internal mechanism for throwing "property missing" exceptions for you.
    That's why the current system is flexible.

    Now, I understood your technical point, but could you argument why does this bother you ?

    What is a complete accessor sollution ? Please argument, as you've lost me

  2. #27
    SitePoint Evangelist
    Join Date
    Aug 2005
    Posts
    453
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    If a property or attribute exist it has to public, private or protected -> ever try to validate data for a public property? Without the __set() function you have to validate data anytime in code the object property is set via your calling code. Set the object property at ten different places and you have to validate data @ all ten places, with just one access point -> through __set() you can let the object check for data validity itself. Is this not supposed to be the core of OO programming? What about a property that can be set through your code but you do not want the user to be able to read it? Try that with a public variable.... Classes with public attributes will rarely pass the acid test of time, the set and get functions are simply interfaces for public variables that allow for data validation and access control! I have very few classes that have any public variables or at least variables that are declared as public. Almost all attributes in my classes are accessed via set/get methods. As the programmer I want total control over what is stored in these variables. If you think these are simply error handlers you have missed the point, Please let me know how you validate your data on publicly declared variables!!

  3. #28
    SitePoint Addict mgkimsal's Avatar
    Join Date
    Sep 1999
    Posts
    209
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by bonefry
    So it is logical to first check for real properties and only after that to execute __set/__get. And I really don't see why this bothers you. Python behaves in the same way (as I recall). Ruby only has method calls and properties are emulated. And it's better and more flexible that in C#. Should I mention Java ?

    If the reverse was true and __set/__get were called first, then you had to be very carefull about exceptions/errors throwed, no ?
    Why would you have to be any more 'careful' than you are now?


    Quote Originally Posted by bonefry
    Plus, you would've had to depend on an internal mechanism for throwing "property missing" exceptions for you.
    That's why the current system is flexible.
    Only if you want to know about properties that are 'missing'. But currently everyone thinking PHP5's __get/__set are awesome are relying on the fact that everything they use these for *have* to be 'missing' from the class defintion. You can have a nice class definition with properties defined with defaults, phpdoc comments and all the other niceties we've come to expect from programs over the years, or you can use __set/__get functionality - you can't have both. That's what's so frustrating about this situation. To get the 'cool' functionality you have to break a lot of 'good programming' practices. Why is it considered bad practice to not initialize variables in your code before you use them, but it's good to use the __get and __set in PHP5 as is?
    Michael Kimsal
    =============================
    groovymag.com - for groovy/grails developers
    jsmag.com - for javascript developers

  4. #29
    SitePoint Evangelist
    Join Date
    Aug 2005
    Posts
    453
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    If you want to initialize your varables and comment on them try the _construct function.
    You can still have the 'cool' functions and good programming practices you just have to work at it from a different approach.

  5. #30
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by bonefry
    Now, I understood your technical point, but could you argument why does this bother you ?

    What is a complete accessor sollution ? Please argument, as you've lost me
    Well ... by the logic of the current __set()/__get() magic methods there really should be three methods for each for getting/setting accessors. For example:

    - __set_all() // all accesses to properties go through this function
    - __set_defined() // accesses to defined properties go through this function
    - __set_undefined() // accesses to undefined properties go through this function (current __get())

    Then you would have fine-grained control over how you wanted to handle (or not handle) accessors. The only outstanding question is whether accessing properties via $this would go through __set_all() or __set_defined()? You could go crazy and have public and private versions of these functions. That may seem overkill, but when you need them you usually want much more control than the current error handlers.

    Also, you'd probably want the same thing for __call() as well. Then you could really write powerful things like DI or Persistence code in a clean way.
    Christopher

  6. #31
    throw me a bone ... now bonefry's Avatar
    Join Date
    Nov 2004
    Location
    Romania
    Posts
    848
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by mgkimsal
    Why would you have to be any more 'careful' than you are now?
    Why don't you think before asking ?
    Check the following code:
    PHP Code:
    class BaseClass {
        public 
    myVar;
    }
    // ... and in a different file so it makes it harder to see
    class ChildClass extends BaseClass {
        function 
    __get($property)
        {
             if (
    $property != 'someProp')
                 throw new 
    Exception('missing property '.$property);
        }
    }
    echo (new 
    ChildClass()).myVar
    Quote Originally Posted by mgkimsal
    Only if you want to know about properties that are 'missing'.
    Do you know anyone that doesn't want to know about missing properties ?

    Quote Originally Posted by mgkimsal
    But currently everyone thinking PHP5's __get/__set are awesome are relying on the fact that everything they use these for *have* to be 'missing' from the class defintion.
    Yes, that is correct. Enough said until you give me a counter example and an explanation on why is this a Bad Thing ?

    Quote Originally Posted by mgkimsal
    You can have a nice class definition with properties defined with defaults, phpdoc comments and all the other niceties we've come to expect from programs over the years, or you can use __set/__get functionality - you can't have both.
    Why not ?

    Quote Originally Posted by mgkimsal
    That's what's so frustrating about this situation. To get the 'cool' functionality you have to break a lot of 'good programming' practices. Why is it considered bad practice to not initialize variables in your code before you use them, but it's good to use the __get and __set in PHP5 as is?
    What are those 'good programming practices' ?

    Why do you consider __set/__get as poor programming practice ?
    What does __set/__get have to do with variable initialization ?
    I fail to see it.

    Please provide examples, as we are talking about computer science here and not literature.

  7. #32
    throw me a bone ... now bonefry's Avatar
    Join Date
    Nov 2004
    Location
    Romania
    Posts
    848
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    Well ... by the logic of the current __set()/__get() magic methods there really should be three methods for each for getting/setting accessors. For example:

    - __set_all() // all accesses to properties go through this function
    - __set_defined() // accesses to defined properties go through this function
    - __set_undefined() // accesses to undefined properties go through this function (current __get())

    Then you would have fine-grained control over how you wanted to handle (or not handle) accessors. The only outstanding question is whether accessing properties via $this would go through __set_all() or __set_defined()? You could go crazy and have public and private versions of these functions. That may seem overkill, but when you need them you usually want much more control than the current error handlers.

    Also, you'd probably want the same thing for __call() as well. Then you could really write powerful things like DI or Persistence code in a clean way.
    I see your point now, but that's not a possibility.

    PHP was designed (with other languages as well) so that you can have direct access to a property.

    And direct access to defined properties cannot be faked.
    The question is, what are you setting/getting, a reference, or a value ?
    The system needs to make sure that access to defined properties is done according to established rules.

    A more clear approach would be the one in Ruby where properties are just faked with methods. But that's a phylosophy that PHP doesn't follow.

    *edited*
    The general programming practice is to have private properties and setters/getters for all of them ... and the __set/__get methods help here.

    *edited*
    Another thing to add is that you can always use reflection for persistance and stuff. PHP has reflection.

  8. #33
    _ silver trophy ses5909's Avatar
    Join Date
    Jul 2003
    Location
    NoVa
    Posts
    5,467
    Mentioned
    1 Post(s)
    Tagged
    1 Thread(s)
    I use them in java and c# but not php. Why? b/c when i learned java, i just learned it was good practice and it carried over to .net. But I learned php a few years back and I'm still trying to write proper OO code in php. It isn't coming natural to me.
    Sara

  9. #34
    SitePoint Guru
    Join Date
    Nov 2002
    Posts
    841
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    What we need for PHP 6 is a way to define real accessor methods. For example:

    PHP Code:
    class Rectangle {

        private 
    $_width;
        private 
    $_height;

        public 
    property $width get $_width set setWidth;
        public 
    property $height get $_height set setHeight;
        public 
    property $area get getArea;

        protected function 
    setWidth($value) {
            if (
    $value 0) {
                
    $this->_width $value
            
    } else {
                throw new 
    exception('Negative dimension');
            }
        }

        protected function 
    setHeight($value) {
            if (
    $value 0) {
                
    $this->_height $value
            
    } else {
                throw new 
    exception('Negative dimension');
            }
        }

        protected function 
    getArea() {
            return 
    $this->height $this->width;
        }


    Java, C#, Python and Ruby all have a standard form of expressing accessor methods. (With varying degrees of verbosity with Ruby at the terse end and Java at the prolix end.)

    How can PHP expect to seriously compete against these languages without native support for accessor methods?

  10. #35
    throw me a bone ... now bonefry's Avatar
    Join Date
    Nov 2004
    Location
    Romania
    Posts
    848
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Selkirk
    Java, C#, Python and Ruby all have a standard form of expressing accessor methods. (With varying degrees of verbosity with Ruby at the terse end and Java at the prolix end.)

    How can PHP expect to seriously compete against these languages without native support for accessor methods?
    Java doesn't have built in syntax or any kind of native support. If you are refering to JavaBeans, it's all based on conventions and reflection. And you can do it in PHP too.

    C# indeed has setters and getters, but as I exemplified somewhere in this thread, you can emulate such things with __set/__get + reflection.

    Python has almost the same behaviour as PHP. In fact I think that's were the PHP authors came up with the __set and __get ideea.

    Ruby doesn't count because it doesn't allow direct access to properties ... one can only access methods.

    In fact, I think better setters/getters support should be on the bottom of everyones list. PHP badly needs other things.

  11. #36
    SitePoint Addict
    Join Date
    May 2003
    Location
    Calgary, Alberta, Canada
    Posts
    275
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by DarkAngelBGE
    Just wondering whether you access the class's attributes within the class itself directly or via their getter methods, which are meant for the public.

    The advantage would be less code (saving some brackets) and one would probably have special methods anyway if one needs the attributes in a special format.

    How do you go about it?
    Access them directly until you need to use the setter because of added functionality is my vote.

    As for the get/set conversation going on, heres some food for thought:
    Dealing with Properties

    Quote Originally Posted by MartinFowler
    Dynamic properties carry a heavy burden of disadvantage, the lack of clarity of the interface, the difficulty in using operations instead on stored data.
    A long read but very well thought out showing advantages / disadvantages / strategies of fixed and dynamic property access.

  12. #37
    throw me a bone ... now bonefry's Avatar
    Join Date
    Nov 2004
    Location
    Romania
    Posts
    848
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Brenden Vickery
    A long read but very well thought out showing advantages / disadvantages / strategies of fixed and dynamic property access.
    Well, of course there are disadvantages.
    But there are also disadvantages in dynamic typing in general.
    Should we all use static languages now because of the interface clarity ?

  13. #38
    SitePoint Addict
    Join Date
    May 2003
    Location
    Calgary, Alberta, Canada
    Posts
    275
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Please read the article. The advantages and disadvantages have nothing to do with static and dynamic languages.

  14. #39
    SitePoint Guru
    Join Date
    May 2003
    Location
    virginia
    Posts
    988
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Simple example of advantages... Pass in optional args, can remove the getter, without breaking API.

    PHP Code:
    class DataSource {
        
        var 
    $data;
        
        function 
    set(){
            
    $args func_get_args();
            
    $name array_shift(args);
            
    $method 'set' $name;
            if( 
    method_exists($this$method) ){
                
    call_user_func_array(array($this$method), $args);
            }else{
                
    $value array_shift($args);
                
    $this->data[$name] = $value;
            }
        }
        
        function 
    get(){
            
    $args func_get_args();
            
    $name array_shift(args);
            
    $method 'set' $name;
            if( 
    method_exists($this$method) ){
                return 
    call_user_func_array(array($this$method), $args);
            }elseif( isset(
    $this->data[$name]) ){
                return 
    $this->data[$name];
            }
        }
    }

    class 
    Product extends DataSource {
        
        function 
    Product(&$data){
            
    $this->data =& $data;
        }
        
        function 
    getPrice($format=false){
            if(
    $format){
                return 
    number_format($this->data['price'], 2);
            }
            return 
    $this->data['price'];
        }
        
    }

    $product =& new Product(
        
    DBC::getRecord(
            
    'SELECT * FROM product WHERE id=:id:',
            array( 
    'id'=>1)
        )
    );

    echo 
    $product->get('price'1); 

  15. #40
    SitePoint Guru
    Join Date
    Nov 2002
    Posts
    841
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by bonefry
    Java doesn't have built in syntax or any kind of native support. If you are refering to JavaBeans, it's all based on conventions and reflection. And you can do it in PHP too.
    You can, but a lot of people don't do it that way. The benefit to having the language define a standard way is that everybody's components can cooperate. And thats what JavaBeans are designed to facilitate.

    Martin Fowler's opinion on properties and accessor methods is quite clear. Native language support good.

    Quote Originally Posted by bonefry
    C# indeed has setters and getters, but as I exemplified somewhere in this thread, you can emulate such things with __set/__get + reflection.
    There are a number of problems with __get and __set:
    1. They mess up reflection.
    2. They are not re-entrant, so you cannot access properties inside your class in the same way you would access properties outside your class.
    3. They are slow
    4. They result in some funky error message reporting. (not my complaint, his)
    5. They pretty much require that you inherit from a base class to implement them

    I created the following class based on your simulated property example:
    PHP Code:
    class PropMark {

        var 
    $prop 'hello world';
        
        function 
    getSimulated() {
            return 
    'hello world';
        }

        function 
    __get($property) { 
            try { 
                
    $method = new ReflectionMethod(get_class($this), 'get'.(strtoupper(substr($property,0,1)).substr($property,1))); 
                return 
    $method->invoke($this); 
            } 
            catch (
    ReflectionException $e) { 
                throw new 
    Exception("$property getter is not defined"); 
            } 
        }
        

    and tested the following:
    PHP Code:
    $x "hello world"// calibration base line
    $x $mark->prop;
    $x $mark->getSimulated();
    $x $mark->simulated
    The method call was 4 times slower than the direct property access.
    Your __get method was 67 times slower than the direct property access and 16 times slower than the direct method call.

    Python has almost the same behaviour as PHP. In fact I think that's were the PHP authors came up with the __set and __get ideea.
    Python has properties.

    Ruby doesn't count because it doesn't allow direct access to properties ... one can only access methods.
    Um, how does this not count?

    In fact, I think better setters/getters support should be on the bottom of everyones list. PHP badly needs other things.
    The PHP community as a whole needs a standard for accessor methods more than any individual PHP developer does.

  16. #41
    SitePoint Wizard
    Join Date
    May 2003
    Location
    Berlin, Germany
    Posts
    1,829
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    @Mitchell: Think you got a small error in your get() method? Shouldn't it append 'get' to the method instead of 'set'? I like this concept, but I am really feeling for the disadvantage of attribute name independency.

    However, going to read Brenden's article before I elabrate any further, thanks for the link.

    Nice, hadn't thought this thread would turn out to be such an interesting discussion, ...with such an interesting poll result.

  17. #42
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Selkirk
    What we need for PHP 6 is a way to define real accessor methods. For example:

    PHP Code:
    class Rectangle {

        private 
    $_width;
        private 
    $_height;

        public 
    property $width get $_width set setWidth;
        public 
    property $height get $_height set setHeight;
        public 
    property $area get getArea
    Java, C#, Python and Ruby all have a standard form of expressing accessor methods. (With varying degrees of verbosity with Ruby at the terse end and Java at the prolix end.)

    How can PHP expect to seriously compete against these languages without native support for accessor methods?
    I like where you are going with this, and I think this would really help solve the problems within a class. But what about things like DI or Persistence where you want to intercept accesses (or calls) but you won't know what the properties or methods will be. Can you just do:

    public property get getAll set setAll;
    Christopher

  18. #43
    SitePoint Guru momos's Avatar
    Join Date
    Apr 2004
    Location
    Belgium
    Posts
    920
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Properties are nice and all, but for the moment we have to do it with getters and setters...

    Nice design requires them.... getInstance (singleton-pattern)

  19. #44
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    My point was neither that the PHP5 system was not flexible, nor that you or I or anyone else doesn't like it. My point was that because __get()/__set() are error handlers (called only when the property does not exist) rather than accessor handlers they are not a complete accessor solution.
    In spite of all the discussion on this, I don't quite see it. What specifically is incomplete? Are you saying that there is something you can't do with it, and if so, what? Or is it just inelegant?
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  20. #45
    SitePoint Guru thr's Avatar
    Join Date
    Jun 2003
    Location
    Sweden
    Posts
    664
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    For get/set:ers in Active Record classes, etc. I use __call, example:

    PHP Code:
    <?php
    class DomainObject{
        
        protected 
    $Id = -1;
        protected 
    $Name;
        protected 
    $Age;
        
        public function 
    setId($id){
            if(
    $this->Id !== -1){
                
    $this->Id $id;
            }
        }
        
        public 
    funciton __call($method,$args){
            
    $property substr($method,3);
            if(
    substr($method,0,3) == 'get'){
                return 
    $this->{$property};
            }elseif(
    substr($method,3,0) == 'set'){
                
    set $this->{$property} = $args[0];
            }
        }
        
    }
    ?>
    This way you get getProperty/setProperty for all properties in your class. You can also "overload" the default (__call) by defining an own setField/getField(setId($id) in this example, to get an immutable Id). I've used this approach for a while and i recently also read about it in sweatj's book.

  21. #46
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by dagfinn
    In spite of all the discussion on this, I don't quite see it. What specifically is incomplete? Are you saying that there is something you can't do with it, and if so, what? Or is it just inelegant?
    It's not necessarily inelegant, but these magic methods are error handlers. They only intercept accesses to properties that don't exist. So you can't intercept access to properties that do exist. The same goes for __call(). Say you wanted to create a siimple Persistence capablity like:
    PHP Code:
    // use the simple convention that the database table is the class name and properties are column names
    class products extends Persistence {
    public 
    $id;
    public 
    $sku;
    public 
    $price;
    public 
    $name;

    // ...

    }

    $item = new product($key);

    // the record is automatically fetched the first time  a property is accessed
    $sku $item->sku;

    // destructor automatically updates record if properties changed (or inserts) when script ends 
    Other things you might want to do are Dependency Injection where you want to intercept method calls to check some aspect before permitting the call.
    Christopher

  22. #47
    SitePoint Guru thr's Avatar
    Join Date
    Jun 2003
    Location
    Sweden
    Posts
    664
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Here's an alternative approach to bonefire's method(with timer tests):

    PHP Code:
    <?php
    // Functions for time:ing:
    function mfloat()
    {
       list(
    $usec$sec) = explode(" "microtime());
       return ((float)
    $usec + (float)$sec);
    }
    function 
    timer($mode=false){
        static 
    $count 0;
        static 
    $timerStart 0;
        if(
    $mode === false){
            
    $count++;
            
    $timerStart mfloat();
        }elseif(
    $mode === true){
            
    $timeEnd mfloat()-$timerStart;
            echo 
    "Time #$count result: $timeEnd\r\n<br />";
            
    $timerStart 0;
        }
    }

    // Testclass
    class Test{
        
        public 
    $int1;
        protected 
    $_int2;
        protected 
    $_int3;
        
        public function 
    __get($outerVar){
            
    $innerVar "_".strtolower($outerVar);
            
    $getVar "get".$outerVar;
            if(
    method_exists($this,$getVar)){
                return 
    call_user_func(array($this,$getVar));
            }else{
                return 
    $this->{$innerVar};
            }
        }
        
        public function 
    __set($outerVar,$value){
            
    $innerVar "_".strtolower($outerVar);
            
    $setVar "set".$outerVar;
            if(
    method_exists($this,$setVar)){
                
    call_user_func(array($this,$setVar),$value);
            }else{
                
    $this->{$innerVar} = $value;;
            }
        }
        
        public function 
    setint3($value){
            
    $this->_int3 $value;
        }
        
        public function 
    getint3(){
            return 
    $this->_int3;
        }
        
    }

    // Test
    $p = new Test;
    timer();
    for(
    $i=0;$i 1000;$i++){
        
    $p->int1 20;
        echo 
    $p->int1;
    }
    timer(true);
    timer();
    for(
    $i=0;$i 1000;$i++){
        
    $p->int2 20;
        echo 
    $p->int2;
    }
    timer(true);
    timer();
    for(
    $i=0;$i 1000;$i++){
        
    $p->int3 20;
        echo 
    $p->int3;
    }
    timer(true);
    ?>
    For the lazy ones, these were the results of the test on my machine(Debian GNU/Linux,256Ram,800Mhz,PHP5.0.5,Apache1.3.34):

    #1 result: 0.0045080184936523 (normal public prop)
    #2 result: 0.032196044921875 (__get/__set call without setX() getX() methods)
    #3 result: 0.05104398727417 (__get/__set call with setX() getX() methods)

  23. #48
    SitePoint Guru momos's Avatar
    Join Date
    Apr 2004
    Location
    Belgium
    Posts
    920
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    OO requires getters and setters, but not for every class-variable, I don't think there is a black/white solution...

  24. #49
    SitePoint Guru
    Join Date
    May 2003
    Location
    virginia
    Posts
    988
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by DarkAngelBGE
    @Mitchell: Think you got a small error in your get() method? Shouldn't it append 'get' to the method instead of 'set'? I like this concept, but I am really feeling for the disadvantage of attribute name independency.
    Oops, not tested! Your're right! To note, I only use this for my template engine/view objects. I wouldn't use this in place of a solid interface/API.

    -matt

  25. #50
    SitePoint Wizard
    Join Date
    May 2003
    Location
    Berlin, Germany
    Posts
    1,829
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I'd like to throw in a quote of Fowler:

    Quote Originally Posted by Martin Fowler, Refactoring - Improving the Design of Existing Code, Page 171
    When it comes to accessing fields, there are two schools of thought. One is that within the class where the variable is defined, you should access the variable freely (direct variable access). The other school is that even within the class you should always use accessors (indrect variable access). Debates between the two can be heated. (See also the discussion in Auer [Auer] on page 413 and Beck[beck].)
    [Auer] - Auer, Ken. "Reusability through Self-Encapsulation." In Pattern languages of Program Design 1, edited by J.O. Coplien and D.C. Schmidt. Addison-Wesley 1995.

    Is this book available to somebody? I am very interested in the discussion Fowler's talking about in that book.

    Our current poll results really reflect Fowler's quote: there seem to be two equally populated camps/schools regarding how to use accessor/modifier methods.


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
  •