The Big Programming Thread - Page 138

On May 29 2012 22:59 tofucake wrote:
He specifically said he was using C++, and using stuff is (imo) the best way to learn it. And getters do suck. Just because they are prevalent doesn't make them good.

On May 29 2012 17:50 heishe wrote:
Suggesting friends for his problems makes no sense. You'd have to add a friend to the class for every type that wants to access its members, which is one of the least generic and hardest to maintain ways to program imaginable.

Friends suck. They introduce code-level dependencies between classes (the class who befriends another must know it, because you have to actually declare the friend in the header), while not really solving any problems.

The only case where they're actually useful is if you purposefully absolutely require that only a specific set of classes must have access to your private data. However, in practice, this should very, very rarely be the case.

If outside classes need to access your private data in its raw form to do stuff with it, there's either no reason to make it private or you're handling your private state in regards to the public interface incorrectly (I think in practice this probably usually means that you've divided responsibilities incorrectly, resulting in the fact that one type of problem needs to access another type of problem's private data because it can not make do with whatever the class provides publicly).

Getters don't suck. Apart from the minimal typing overhead, there's no downside to them. Optimizing them away is one of the most basic optimizations there is, and as such, they're not even slower, since even if you don't mark them as inline, compilers (even GCC which is relatively bad at inlining) will inline them basically all the time, completely removing the cost of a function call.

For data access, usually either make it public, or use getters and(or) setters. Which of the two depends on your problem. If you think that the way of accessing the data in the member is never going to be anything else other than a direct read or write (such as would be the case with matrices or vectors, for example), then simply make them public.
For other cases (where you're not sure, or you already have accessing behavior that is not just read/write) use getters and setters.

On May 29 2012 22:59 tofucake wrote:
He specifically said he was using C++, and using stuff is (imo) the best way to learn it. And getters do suck. Just because they are prevalent doesn't make them good.

On May 29 2012 22:59 tofucake wrote:
He specifically said he was using C++, and using stuff is (imo) the best way to learn it. And getters do suck. Just because they are prevalent doesn't make them good.

On May 29 2012 23:33 tofucake wrote:
First, explaining why they suck takes a lot of time that I don't have. Basically it boils down to making huge assumptions, which is bad, and it's just adding more complication to code. The only real time they should be used is when they have to do something (first article gives examples) other than set or get.

this and this are good write ups about why they suck, in detail.

On May 29 2012 23:33 tofucake wrote:

It's dumb. See my above post.

On May 29 2012 06:16 snively wrote:
i have a question. suppose i delcare a class in c++. is there any way to make the variables "read-only" outside of the class, so to speak? as in, functions not part of the class could read the variable, but not change its value.

any help wuold be appreciated.

On May 30 2012 00:02 gedatsu wrote:

Getters have been suggested, but generally getters and setters should be avoided because they are bad design. Only use them if you want a complete dummy class whose only purpose it to be a group of variables. Usually what you want to do is move the computations into that class.

Bad design:
class asdf {
void dosomething() {
if (jkl.getNumber() > 5) {
//do something
}
}
}

class jkl {
private int number;
public int getNumber() {
return number;
}
}



Better design:
class asdf {
void dosomething() {
jkl.dosomethingifover5();
}
}

class jkl {
private int number;
public void dosomethingifover5() {
if (number > 5) {
//do something
}
}
}

class Warehouse
{
    public int getItemCount(ItemType)
    {
    //dull implementation
    }
    private void changed()
    {
     for each OrderManagmentObject o
         o.notifyChange();
    }
}
class WarehouseStockManagementObject // bad name lol :D
{
    //this should probably be a method that is only visible to warehouse.
   public void notifyChange() 
   {
   if(warehouse.getItemCount(LightBulb)+ordermanager.getTotalOrdered(LightBulb) < 5)
    {
     // place order 
    }

    }
}

On May 30 2012 00:25 Morga wrote:


I disagree, if the knowledge of the >5 belongs in the 'bad design' part of the code then your 'good' design is horrible. Imagine this situation :
A Warehouse needs to be restocked & orders have to be placed for this, to manage the ordering of stock you check what items need to be ordered extra. I'ts not because you can solve it with polymorphism that you should.

class Warehouse
{
    public int getItemCount(ItemType)
    {
    //dull implementation
    }
    private void changed()
    {
     for each OrderManagmentObject o
         o.notifyChange();
    }
}
class WarehouseStockManagementObject // bad name lol :D
{
    //this should probably be a method that is only visible to warehouse.
   public void notifyChange() 
   {
   if(warehouse.getItemCount(LightBulb)+ordermanager.getTotalOrdered(LightBulb) < 5)
    {
     // place order 
    }

    }
}

There are many other factors that need to be considered obviously but don't ever say things like that's bad because the design is bad.

On May 30 2012 00:24 tofucake wrote:

Actually, there's a lot wrong with getters, particularly when they only get and don't do. There's no need to encapsulate a variable that's going to be modified outside the class with getters and setters, just make it public. If it doesn't need to be modified, friend! Or even public still.


Holub may be a blowhard but he doesn't just make things up; he's got plenty of good points in there.




1. Your initial 3rd point. It's dumb. It's pointless complexity. It being the first lesson is also dumb. "Always use getters and setters" is a stupid lesson and I hated it in every course I took. The later courses were better and taught to use them properly. And now that I think about it, comparing C++ to Soccer is also dumb.

2. So telling him to try something else isn't okay? Go away. You don't learn new stuff by doing the same thing over and over.

3. Sorry I used a colloquialism in a forum post and then linked to more formal pages. I'll remember that this is a sprsrsbsns forum from now on and will only use the most proper English possible and will not post without first having my post reviewed by at least 4 different editors from the writing staff. Or I'll just continue posting how I want. Yeah I like the second option there.

On May 29 2012 23:33 tofucake wrote:
First, explaining why they suck takes a lot of time that I don't have. Basically it boils down to making huge assumptions, which is bad, and it's just adding more complication to code. The only real time they should be used is when they have to do something (first article gives examples) other than set or get.

this and this are good write ups about why they suck, in detail.

On May 30 2012 01:26 typedef struct wrote:
Moving the functionality into the class you are accessing (the technique getdatsu posted) is only the correct solution if said functionality is something the class is directly responsible for. If not, you're just adding more responsiblities to the class (in violation of the Single Responsiblity Principle).

On May 30 2012 01:55 gedatsu wrote:

Even if you don't want to delegate the whole subroutine to the jkl class, you should still avoid a getter and make a specific-purpose test method.

asdf class:
if (jkl.testcertainconditions()) {
//do something
}

jkl class:
public boolean testcertainconditions() {
return number > 5;
}

This in no way violates SRP, but in fact it strengthens it as it ensure that no other class gets the responsibility of fiddling with jkl's variables. It also creates a higher degree of abstraction, as it hides implementation details of class jkl. The warehouse example could use a similar approach:
if (warehouse.itsTimeToBuyNew(LightBulb)) {
//code to buy new light bulbs
}

On May 30 2012 01:26 typedef struct wrote:
This debate says a lot about object-oriented programming in general.

You'd never find this kind of disagreement about a fundamental concept in a functional language/style.