[jawny80]

I'm working on the "Breakfast for Lumberjacks" exercise on pages 359/360. In the form class there are these lines of code for adding flapjacks:

private void addFlapjacks_Click(object sender, EventArgs e)
{
Flapjack food;
if (crispy.Checked == true)
food = Flapjack.crispy;
else if (soggy.Checked == true)
food = Flapjack.soggy;
else if (browned.Checked == true)
food = Flapjack.browned;
else
food = Flapjack.banana;

Lumberjack currentLumberjack = breakfastLine.Peek();
currentLumberjack.TakeFlapjacks(food,
(int)howMany.Value);
RedrawList();
}

The problem is that Flapjack does not exist in the form class only the Lumberjack class. Flapjack is an enum in the Lumberjack class. Am I missing something or does this code in the book not make sense?

[walbaloushi]

Actually the Flapjack enumeration is not part of the LumberJack class. I believe that what the authors did was enter all the code including LumberJack and Flabjack as part of the Form class.

CODE

public partial class Form1 : Form {
   //Form code and methods

   enum FlapJack { //code }

   class LumberJack { //code }
}

If you wanted to separate your code into multiple files, this can be done, and one thing that was not mentioned in the book is that enums DON't have to be part of a class. You can have something like this:

FlapJack.cs

CODE

namespace <whatever namespace name> {
  //notice no class here
  enum FlapJacks { //code }
}

LumberJack.cs

CODE

namespace <whatever namespace name> {
  class LumberJack { //code }
}

Form.cs

CODE

namespace <whatever namespace name> {
  //whatever form code goes here
}

As long as the namespaces are the same you won't have problems' otherwise you will need to include using statements or use class or enum names that contain the namespace.

Hope this helps.

[jawny80]

I have them in two different classes but I realized that I wrote:

private Queue<Lumberjacks> breakfastLine;


Once I added the:
= new Queue<Lumberjacks>();

it then worked without error for some reason.

[walbaloushi]

Without seeing what the errors were I can't tell you what the problem was, but based on your fix I can guess that you were getting something about varaible not pointing to a reference of an object or something of that sort.

To use a the generic Queue<Lumberjacks> you need to create an instance of it, and that is why you need to do

private Queue<Lumberjacks> breakfastLine = new Queue<Lumberjacks>();


This is the same as if you want to use the LumberJack class yo need to create an instance of it, so that:

LumberJack ted;
ted.SomeFunction();

Will error out, because ted doesn't point to an actual instance of LumberJack.

To get it to work you need to do this:

LumberJack ted = new Lumberjack();
ted.SomeFunction();

[jawny80]

I'm still having trouble understanding why you make some things private vs public. For example I see may private randoms/Lists<> being put in the constructor. In the Go Fish exercise the game class is private.

Can anyone explain why you would add a private class to a form? I am having a hard time understanding how a program "fits together" (like using a game class in Lab2).

[AndrewStellman]

I'm still having trouble understanding why you make some things private vs public. For example I see may private randoms/Lists<> being put in the constructor. In the Go Fish exercise the game class is private.

Can anyone explain why you would add a private class to a form? I am having a hard time understanding how a program "fits together" (like using a game class in Lab2).

That's a really good question, and it deserves a good answer. It's one of the hardest concepts for programmers to get, and understanding the answer is one of those things that can really help turn you into a better programmer.

The short answer is that making everything in one class public means that another class can access those things, and that's an easy way to accidentally create bugs in your programs. Every class has a purpose, and its public interface -- its public properties and methods -- is how other classes in your program use it for that purpose.

You have a lot of freedom to choose how that class does what it's supposed to do. You can make it easy to use or you can make it hard to use. What makes a class easy or hard to use has a lot to do with how intuitive its interface is: are the methods and properties named in a way that makes sense, did you choose ones that are easy to understand or figure out, etc.

Even if you're the only one who will ever use the class that you wrote, making it easy to use still matters. Every programmer who's been building software for a long time recognizes this thought: "Crap, what was I thinking when I wrote that?" -- genuinely trying to figure out what you meant this bit of code to do.

That's where private methods, properties and fields come in really handy. When you're trying to use a class that you wrote three weeks ago, it's hard to remember exactly what you meant to be used to control the class versus what's purely internal "stuff" that you only care about if you're trying to build or fix that class. Making that internal stuff private makes it really easy for you to see how the class is meant to be used, so three weeks later you don't have to think, "Wait, is this method what I'm supposed to call, or do I call this other method, or do I just set the fields?"

I know that may still seem a little weird. I'll give some thought to this to see if I can come up with an example that will help this make a little more sense. If I can think of something, I'll make it into a blog post.

[AndrewStellman]

I just wanted to let you guys know that I turned this in to a blog post called Understanding C#: Why make things private?

It's adapted from some of the new material that we're putting into the second edition, which is going to come out at about the same time as Visual Studio 2010.

Thanks again for asking the question!