Welcome to the Treehouse Community

Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.

Looking to learn something new?

Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.

Start your free trial

Java Java Objects Meet Objects Constructors

What is the purpose or main idea behind this PezDispenser code?

I don't quite understand what it is we are doing with all this code. Craig uses a Pez Dispenser as an example of an object, but I don't get what the code actually does. I know this question is ambiguous, but the problem is I was lost from the beginning of this section. Feel free to ask me questions to clarify.

Why are we using the public and private commands in the code? I know it hides certain parts of the code and allows other parts to be accessed, but what is the point of doing this? If this wasn't in the context of the pez dispenser, I would be completely lost.

3 Answers

Hello

I would not use the word secret when I describe a class. I would say it a bit differently.

A class is a blue print to make objects. You hide some of the implementations (how the object is made .... exmple, how the dispenser dispenses pez, how pez are loaded into the dispenser into the dispenser ... and so on). But the party(ies) using your class do not or should not care how you dispense a pez, they just want a pez pull the head.

Think of a radio as an object made of a class .... you have a blue print that you used to produce radios. Each radio has knobs and buttons to switch between different stations. the buttons and knobs are your public interfaces. when you turn a knob to change to a different radio station, something equivalent to internal setters, getters and public methods are called to make the change for you. If you now open the radio and re-wire things to make the radio more efficient or to improve the sound, the user still see/do same thing when operating the radio. he/she still turn the knob to switch to a different radio station, but now your getters, setters and public interfaces will be calling different internal implementation (the re-wired and improved ones) to make the switch. You just made a class class changes, without impacting the end users.

Now if users think your class is not good enough ... then they can always inhered your class as a base-class and make a new pez or radio design(class) that meets their taste; and they can use the new class they made to make their own version of dispensers or radios.

hope this helps.

Yes, thanks! That analogy actually does make things a lot clearer!

Hi

Let take the Pez as an example to discuss the need for public and private designation

Let say this object (the pez) needs to be reloaded after you consumed all the goodies in the pez.

so I have (pseudo code ... and just for demo):

Class PzDespenserClass(){
  public maxNumberOfPezToReload;
  public numberOfPezInDespenser;

  //and down here I have a method 
  public reloadPz(){
      numberOfPezInDespenser = maxNumberOfPezToReload

  }
}

//here is a fake main()
public static void main(String[] args){
   PzDespenserClass myDespenser = new PzDespenserClass();
   myDespenser.maxNumberOfPezToReload = 1000;
   myDespenser.reloadPz();   <<<<<<<<<<<<<<<< I just put 1000 pez in a despenser that can takes 20 only????
}

Certainly YOU wouldn't load 1000 pez, because you know that a dispenser can only takes 20 pez. But you are not writing the class for your self ... I am the user ... and I have no clue what the max capacity of a dispenser... so I may put 500, 1000, who know ... the more the merrier. The key to understand ... a class with everything having public access .. is a disaster in making.

Noe let refactor the class.

Class PzDespenserClass(){
  private static final maxNumberOfPezToReload=20;
  private numberOfPezInDespenser;

  public void setNumberOfPezInDespenser(int pezToAdd){
     if (pezToAdd > maxNumberOfPezToReload ) {
         FatWarining();
     }
     else if(maxNumberOfPezToReload  < 1){
         StarvingWarning();
    } 
    else
         numberOfPezInDespenser = pezToAdd;
  }
  //
  private void FatWarning(){
     System.out.Println("Hey ... you are making me too fat.   Too many pez");
  }

  private void StarvingWarning(){
     System.out.Println("Comon man... some pez please.   TI am starving");
  }
}

//here is a fake main()
public static void main(String[] args){
   PzDespenserClass myDespenser= new PzDespenserClass();
   //  myDespenser.maxNumberOfPezToReload = 1000;           <<<<<<<<<<<<< and to that any more
   //myDespenser.reloadPz();   <<<<<<<<< no more direct access
   //
   // what you can do is
   myDespenser.setNumberOfPezInDespenser(1000); // <<<<<<<< you will get the message from FatWarning
   myDespenser.setNumberOfPezInDespenser(-500); // <<<<<<<< you will get the message from StarvingWarning
   myDespenser.setNumberOfPezInDespenser(10) // works, and now you / I got 10 pez to enjoy.

this is all pseudo code typed in very cumbersome text area, but I hope it conveys the concept. Class attributes must be private modifier as much as possible (if not in all cases), and access to them should be done via public setters and getters.

Hope this helps. If this answers your question, please mark question as answered.

Okay, I kind of get it but there are still some holes in my understanding. From what I can understand (and this might be wrong), the class is like the "secret" blueprint that you don't want the consumer or user to see.

Next, the private and public modifiers prevent and allow access to that blueprint right?

I am a little confused with the meaning of setters and getters. I'm also not sure of the difference between a method and modifier/ all the other terminology that's being used.

I just finished this exercise, so I might not quite get it either, but I understood it less like "secret blueprints" and more like a warning. Like, for example your PC has some really important system files that can brick your machine if you edit or delete them, and if you were to try, Microsoft (on PC of course) will tell you "NO!"

You know that the files are there, and if you really want to, you could force your way in (administrator) and delete your system32 or something, but Microsoft makes it abundantly clear that you really shouldn't do that. Likewise, a private class warns the consumer that that bit of the class is really important and really shouldn't be touched. If the consumer wants to, they can just go in and change it (if they know how to edit the file directly, like an administrator), but they really shouldn't.

Is that right?

EDIT: Just noticed this post is 6 months old, sorry for necro.