Game programming and good programming practises

Quote:

Original post by ace_lovegrove Why exactly are Getters and Setters bad coding practices, doesn't not using them mean that, in a class for example, u would have to make the member data in question, public.

Quote:

This would mean that this member data could be read or written too with no moderation at all.

Quote:

Can i also add that this would remove the point of encapsulation.

Quote:

Ive read C/C++ books that recommend this as a good coding practice.

Quote:

Original post by paulecoyote A setter may break down a value from a string into several internal int values for example. Or a getter may take several values and combine them whenever needed. Or a setter / getter may normalise something (eg make sure strings are kept in lower case). They are also useful for things like form designers whom, again, want to store the state of an object. Saying that they are always bad is jumping on a particular fashionable bandwagon. They can still be useful when used correctly and with caution.

// Of course, lots of constructor type stuff etc. is missing...class Foo {  int x;  int y;  public:  int getX() { return x; }  int getY() { return y; }}class Bar {  Foo myFoo;  public:  int getFooProduct() {    return myFoo.getX() * myFoo.getY();  }}

// and similarly here.class Foo {  int x;  int y;  public:  int product() { return x*y; }}class Bar {  Foo myFoo;  public:  int fooProduct() { return myFoo.product(); }}

Quote:

Original post by paulecoyote ... if x was price in your example - would it not make sense to have a "getPrice, setPrice" for a product is say a point of sell system?

struct bill_item{    string item_id;    string item_description; //In case comments need to be attached.    int quantity; //negative for returns, 0 for uncounted psuedo-items    price_t price() const; //actual end price    price_t base_item_price; //base item price, factoring in direct per-item discount. Get/set privilages needed anyways, dosn't need to update price() since that's a calculation instead of a variable.    double discount; //percentage, factored into base_item_price in price(), Get/set privilages needed anyways, dosn't need to update price() since that's a calculation instead of a variable.    //Rationale:    //This allows for tracking transaction-price seperately    //from item price, which may change after the item has    //been bought. Also allows for case-specific discounting.};

Quote:

SetPrice could have something that prevents a negative figure being input for example.

Quote:

What about if a product was rebranded, like from "Jif", to "Cif" like happened here recently - or "Opel Fruits" to "Starburst"... seems like a setter for the product name (make sure it has a name, doesn't allow less then x characters in a name) and a getter to get the name would also be valid.

Original post by MaulingMonkey

struct bill_item{    string item_id;    string item_description; //In case comments need to be attached.    int quantity; //negative for returns, 0 for uncounted psuedo-items    price_t price() const; //actual end price    price_t base_item_price; //base item price, factoring in direct per-item discount. Get/set privilages needed anyways, dosn't need to update price() since that's a calculation instead of a variable.    double discount; //percentage, factored into base_item_price in price(), Get/set privilages needed anyways, dosn't need to update price() since that's a calculation instead of a variable.    //Rationale:    //This allows for tracking transaction-price seperately    //from item price, which may change after the item has    //been bought. Also allows for case-specific discounting.};

[/quote]

The whole point about classes and objects is to split the domain up into lots of concepts that have very clear contracts and look after the data they have in charge well. A item that keeps track of a base price, a discount price... what happens when you want to add another sort of discount? Say if you want to add a student discount to item, perhaps an OAP one... a special wednesday one... why on earth would you want to add a special case to each item? What if the discount is 10%... means your storing 10% against every single item you have. Or what about no discount, you're storing 0% for every item, what's the point in that?

(Looks like you're using a struct anyway, so everything is public by default. If it's a struct and you're just using it as a data store and exposing all the internal workings for anything to directly manipulate, then it's just data and doesn't really need to be a class at all, just data. Meaning you can keep all your functions external - like your COBOL I guess)

Better to keep Discount seperate - as stated above. A discount could keep a list of item ids, item types, or whatever that it is applied to... when it can be applied... lifetime of discount, etc. What a waste if each item had to keep track of things like that.


And that posturing about COBOL and all that POS stuff? It's not like I'm a newbie straight out of university either you know, my software is used many thousands of times a day across libraries and learning centres all over the uk. It's mature, stable and gets the job done.

So anyway, getters and setters CAN be used sensibly when contracts of the classes in the system are clear, and are backed up with more complex functions for the more complex business logic. They can provide a non-bespoke standardised method (if named consistantly) of getting to things you would expect to be accessible in a class, and a way of automatically ensuring values kept in a class are valid. If used properly they are very different from being public variables in a class structure.

I noted you did not have a go about their usefulness in COM and form designers, so I guess you concede that at least even if the rest of it gets your back up.

[Edited by - paulecoyote on November 24, 2004 7:31:58 AM]

Quote:

Original post by johnnyBravo so say i got a class which jus has information like: x y z width height depth etc etc should i not use getter/setters? I find it quite annoying to have to getsets on classes like these. ALso note a class like that only exists to hold that information

Quote:

Original post by johnnyBravo ... should i not use getter/setters? I find it quite annoying to have to getsets on classes like these. ALso note a class like that only exists to hold that information

Quote:

Original post by Fruny Quote: Original post by johnnyBravo ... should i not use getter/setters? I find it quite annoying to have to getsets on classes like these. ALso note a class like that only exists to hold that information Make it a struct and directly access the (public) data members.

Quote:

Original post by LucidIon Moose6912: An optimising compiler should inline the get/set functions. It won't make any performance difference. A programming practice normally considered bad, which can increase performance, is the use of goto's - which can be quite useful. Without goto

Event event;int run = 1;while(run) {     event = EventHandler.poll();     switch (event.type) {         case Event.EXIT: run = 0;         // other events     }}

Quote:

With goto, the code is easier (IMO) to follow and more efficient (no need to test run each time round the loop).

Event event;while(true) {    event = EventHandler.poll();    switch (event.type) {        case Event.EXIT: goto exit_event_loop;        // other events     }}exit_event_loop:

// How I would probably actually write this particular example:while(process(EventHandler.poll())); // no bodybool process(Event e) {  switch (e.type) {    case Event.EXIT: return false;    // other events  }  return true;}// Another way which actually illustrates using the return to// break multiple levels:processEvents();void processEvents() {  Event event;  while(true) {    event = EventHandler.poll();    switch (event.type) {      case Event.EXIT: return;      // other events    }  }}