Trivial: Get/Set + Function Order in Classes

This is a discussion on Trivial: Get/Set + Function Order in Classes within the C++ Programming forums, part of the General Programming Boards category; Bit of a trivial question here, but anyway. I've decided to order my class functions alphabetically, so I can find ...

  1. #1
    Registered User
    Join Date
    May 2003
    Posts
    37

    Trivial: Get/Set + Function Order in Classes

    Bit of a trivial question here, but anyway.

    I've decided to order my class functions alphabetically, so I can find what I need quicker.

    The problem is, I have a ton of get/set functions for private variables. My question is, by convention, should I order 'em in Get/Set pairs (eg. getEast, setEast, getWest, setWest) or chunk all the Gets together and all the Sets together? (eg, getEast, getWest, setEast, setWest)?

    --Ashiq

  2. #2
    Toaster Zach L.'s Avatar
    Join Date
    Aug 2001
    Posts
    2,686
    I'd put the get/set pairs together, personally.
    The word rap as it applies to music is the result of a peculiar phonological rule which has stripped the word of its initial voiceless velar stop.

  3. #3
    mustang benny bennyandthejets's Avatar
    Join Date
    Jul 2002
    Posts
    1,401
    Does the ordering in the declaration or definition affect the way it will run, or is it just an aesthetic thing?
    benforbes@optusnet.com.au
    Microsoft Visual Studio .NET 2003 Enterprise Architect
    Windows XP Pro

    Code Tags
    Programming FAQ
    Tutorials

  4. #4
    ATH0 quzah's Avatar
    Join Date
    Oct 2001
    Posts
    14,826
    You may also consider having them fall in the order in which your internals are declared:
    Code:
    class Foo
    {
        public:
            int getBar( );
            void setBar( int s );
    
            char getC( );
            void setC( char tothis );
    
            ...and so on...
    
        private:
            int bar;
            char c;
            ...and so on...
    };
    I also like pairs. It's really just personal preference. You should pick one method and try to stick to it, so that your classes have a common form.

    The key is to pick a style and stick with it.

    [edit] To answer the above question, it's purely for looks and ease of readability. [/edit]

    Quzah.
    Hope is the first step on the road to disappointment.

  5. #5
    Registered User
    Join Date
    May 2003
    Posts
    37
    Sounds about right to me. Thankee!

    --Ashiq

  6. #6
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,586
    As well you might think about redesigning some of your classes. If you have a private member but can still access it by public functions - then, in reality, there is no need to declare the member as private.

    If you find yourself doing this frequently then it is time for a re-think of your class structures. Now granted there are times where you will have to use this mechanism, but if you are always using it simply to overcome the protection mechanism built into the private keyword then you are not using it correctly.

    Code:
    class Foo
    {
      int value;
      public:
        Foo(void) {value=0;};
        void Set(int tvalue=0) {value=tvalue;};
        int Get(void) {return value;};
    };
    In this example why is value even private? Value might be private, but it can be accessed like a public member and though this does not illustrate what I'm trying to say in full, it might give you an idea of what my point is. No point in making a member private if you are going to create multiple public functions that override the protection mechanism. Kind of coding in circles.

    So if you have a get and set for every private member in your class, I would tend towards the notion that you are simply using those functions to override the inherent protection mechanisms in C++.

    Just a thought.

    A better way is to derive one or more classes from one or more base classes. This way, the private and protected mechanisms would be used correctly. Private is used for a member that is needed by the current class and no one else. So if another class needs to have access to that member, consider making it protected and derive another class from it. For more information on classes and what the different keywords do check a book on C++ or your help file.

  7. #7
    Registered User
    Join Date
    May 2003
    Posts
    37
    I disagree somewhat with the way you say we should do public functions. Maybe if they're ALL using set/gets, that would be kind of...crap. But using set functions in particular ensures that you don't accidentally change the value of your variable somewhere. I did that in a program once, took me 3 days to track it down. I can see the reasoning behind set/get functions...

    --Ashiq

  8. #8
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,586
    If you find yourself doing this frequently then it is time for a re-think of your class structures. Now granted there are times where you will have to use this mechanism, but if you are always using it simply to overcome the protection mechanism built into the private keyword then you are not using it correctly.

  9. #9
    Cat
    Cat is offline
    Registered User
    Join Date
    May 2003
    Posts
    1,571
    Originally posted by Bubba
    As well you might think about redesigning some of your classes. If you have a private member but can still access it by public functions - then, in reality, there is no need to declare the member as private.
    I agree that this low level of direct access is not typically desirable, but there are significant advantages to use a get/set pair over a public variable.

    1) Separates interface from implementation -- the calling code doesn't need to know how the variable is internally stored, and the internal storage mechanism could change without breaking client code. For example, perhaps the variable for west is actually part of an array of integers.

    One of the "laws" of good OOP is that a published interface is set in stone. Putting implementation details as part of that interface is a bad idea -- it locks you into one kind of implementation only, because you now can't change how you implement that particular variable without defining a new interface.

    2) Permits validation of the data. SetYYYY() can make sure the value being given to it is within the range of valid options. Even if you don't do this at first, it's good to have the option to do this later.

    Overall, I can't think of a good reason to EVER use a public variable except in a struct-like class, where you're not really encapsulating, just grouping data together. You should always use Get/Set pairs and a private variable instead.

    Of course, you're right, you should try to design the interface such that you don't NEED all those functions, but if the interface needs them, use member functions and not public variables.
    Last edited by Cat; 07-08-2003 at 09:26 AM.

  10. #10
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,586
    This:
    As well you might think about redesigning some of your classes. If you have a private member but can still access it by public functions - then, in reality, there is no need to declare the member as private.
    did not imply:

    Overall, I can't think of a good reason to EVER use a public variable except in a struct-like class, where you're not really encapsulating, just grouping data together. You should always use Get/Set pairs and a private variable instead.
    but it did imply:

    Of course, you're right, you should try to design the interface such that you don't NEED all those functions, but if the interface needs them, use member functions and not public variables.
    because again:
    If you find yourself doing this frequently then it is time for a re-think of your class structures. Now granted there are times where you will have to use this mechanism, but if you are always using it simply to overcome the protection mechanism built into the private keyword then you are not using it correctly.
    So real quick:
    • Public variables= bad idea
    • Private variables=good idea
    • Public functions used to continually thwart privacy=bad idea


    So

    if
    public variables==bad idea

    and

    private variables with several public functions which operate on said private variable - thus really treating it like a public variable==bad idea

    then

    time to redesign the class.

  11. #11
    Toaster Zach L.'s Avatar
    Join Date
    Aug 2001
    Posts
    2,686
    Of course, you're right, you should try to design the interface such that you don't NEED all those functions, but if the interface needs them, use member functions and not public variables.
    Sums up my thoughts quite well.
    The word rap as it applies to music is the result of a peculiar phonological rule which has stripped the word of its initial voiceless velar stop.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Getting an error with OpenGL: collect2: ld returned 1 exit status
    By Lorgon Jortle in forum C++ Programming
    Replies: 6
    Last Post: 05-08-2009, 08:18 PM
  2. references to function in classes
    By Chrip in forum C++ Programming
    Replies: 3
    Last Post: 10-21-2007, 11:39 AM
  3. Replies: 28
    Last Post: 07-16-2006, 11:35 PM
  4. Please Help - Problem with Compilers
    By toonlover in forum C++ Programming
    Replies: 5
    Last Post: 07-23-2005, 10:03 AM
  5. Replies: 5
    Last Post: 02-08-2003, 06:42 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21