• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
tom_mai78101

What reasonable amount of accessor functions do you need in a C++ class?

10 posts in this topic

I tend to notice that if you have a class for a certain requirement, chances are there will be a lot of accessor methods wrapped nicely in the C++ class itself. (Possibly Java)

I'm curious to know what is the reasonable amount of accessor methods for a class with any one of the following requirements:

1. Game engine: How many are there, do you think that's reasonable enough for maintenence and easier scripting?
2. Mutator methods: Since modifying a variable requires pair(s) of accessor methods, I wondered if we could control the amount of them while implementing a class?
3. Nested accessor methods: Just in case, if C++ allows you to invoke a mutator method via an accessor method, how do we reduce the amount of accessor methods?

Thanks in advance.
0

Share this post


Link to post
Share on other sites
Here are a few thoughts I just conceived upon reading your post.

I really hate mutators/acessor methods quite a bit, due to its bloating-the-class disadvantage. But then, having few mutators and using methods with higher-level of concepts makes the class itself bloated with a lot of higher-level methods in order for the class functions to achieve its goals in a more generic way.

Unless having a bloated class is pretty normal, and very accepting in the industry, using encapsulation wrapping around functions' responsibilities seems like one of the unheard-of, well-known coding practices at school. Thus, I need to do a research on my part.

Am I correct to say that a class should not have a lot of responsibility-encapsulated, higher-level methods and never a lot of mutators/accessor methods, instead, go and "divide-and-conquer" a class into multiple classes with hierarchy-ness in-between (making all of the classes related in some way)?
0

Share this post


Link to post
Share on other sites
I've noticed as I get better at designing/coding my classes have gone from usually having many accessors/mutators to having almost none - objects should just "do things". Too many accessors is, in my opinion bad design. Whats too many completely depends so that itself is not very useful. I wouldn't be afraid of bloating the class with methods, I'd be afraid of bloating its interface (which many accessors/mutators do). If you can encapsulate parts of an object in further objects (and combine with composition) then even better. Just my opinion of course.

I find it quite rare to use accessors/mutators, usually the constructor is enough to setup the object once. If I do need alot of access, such as creating a loader type object (and not wanting to add loading functionality directly to the class) I'll just friend the loadeer object rather than making alot of accessor/mutators.
0

Share this post


Link to post
Share on other sites
[quote name='tom_mai78101' timestamp='1304026959' post='4804158']
I tend to notice that if you have a class for a certain requirement, chances are there will be a lot of accessor methods wrapped nicely in the C++ class itself. (Possibly Java)

I'm curious to know what is the reasonable amount of accessor methods for a class with any one of the following requirements:

1. Game engine: How many are there, do you think that's reasonable enough for maintenence and easier scripting?
2. Mutator methods: Since modifying a variable requires pair(s) of accessor methods, I wondered if we could control the amount of them while implementing a class?
3. Nested accessor methods: Just in case, if C++ allows you to invoke a mutator method via an accessor method, how do we reduce the amount of accessor methods?

Thanks in advance.
[/quote]

Alot of accessor methods: Direct mutators (direct access to modify a member variable) are considered bad OOP because encapsulation of that data allows you to pre-process changes. The same is true with accessors, but post-processing instead. An example of this would be if you were writing a game GUI library. When you want to set the position of a widget, it is considerably more efficient to update its position members relative to the position of the widget containing that widget (panel, window, etc) than it is to calculate the widget's position on screen at render / event handler time. If you care about unnecessary optimization, anyway. Realistically, integer math operations are so fast it shouldn't even touch your framerate even with hundreds or thousands of widgets drawn each frame. It's an example relative to something I'm working on right now, so that's just the first thing that came to mind. Another thing might be updating a player's hp in the game -- generally you'll use a widget to display the player's health. Depending on how you made that work, you may need to update the value in the mutator.

But, realistically, it's up to you to decide whether you want to encapsulate your data. If you know you only need direct access to it, go crazy.

1) If I understand you correctly, you mean a game controlling class (IE the "Game" class in the XNA framework). You shouldn't need mutators and accessors for that, merely behavioral functions.
2) Don't think of limiting them. If they're in header files, they will already be inlined if the compiler thinks they're worthy, which effectively means that there is no function call overhead. If not, then clearly they're really necessary.
3) Nope. Just don't be stupid and cause an infinite recursion

EDIT: In 99 out of 100 cases, Ravyne is completely right in the post above this one.
0

Share this post


Link to post
Share on other sites
Also, if you're not already -- learn how to use "const" correctly to ensure that client code doesn't have unexpected access to your class internals. Use it on parameters, use it on return values, use it on method signatures (const methods) use it on pointer declarations (constant pointers, pointers to const data, and const pointers to const data) -- everywhere you can that is appropriate. Constness is every bit as much a part of the interface as the method calls themselves. It helps clients know what they can or cannot do, discourages unintended side-effects, and also gives the compiler a little more leeway to perform optimizations.

I use it religiously. So should you. So should everyone.
1

Share this post


Link to post
Share on other sites
I only use getters. If the member variable needs to be read and modified as is by *any* class I drop it public and that's it. There is no point in bloating the declaration with accessors to achieve the same result as making the variable publicly accessible.
0

Share this post


Link to post
Share on other sites
Thanks again, everyone.

My preferred languages are C/C++ and Java. Since they both use classes, all of the information I get in this thread are invaluable.
0

Share this post


Link to post
Share on other sites
[quote name='tom_mai78101' timestamp='1304050013' post='4804279']
My preferred languages are C/C++ and Java. Since they both use classes
[/quote]
There is no language called "C/C++", and C certainly does not have classes.
0

Share this post


Link to post
Share on other sites
Generally you need one for each member that needs one.

I am being serious here; there is no fixed amount that is prescribed under any particular circumstances; your code follows your design and not some abstract rules like "you need X amount of thing Y". If your design requires 200, then you need 200. If your design requires 1 then you need 1. Simple as that.
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0