Object Oriented Programming Questions

[Kieth89]

I need some clarification on some stuff. I'm using the "SAM's C++ in 21 days" book and am getting introduced to object oriented programming. In the book examples it always defined (created) the class before the main function. I tried that and it worked, so then I tried creating the class in the main function, and that worked, too. So, should I always create classes before I get to any other function due to the same reason we create function prototypes, or does it matter?

Another question I had was about private and public access to function members. In the book it tells me that it is best to keep all members private and access them using accessor functions, which I assume is what I should do. However, it says the reason for this is "You can later change how the data is stored without having to rewrite any of the other functions in your programs that use that data". What I don't get is why would it affect other functions? When you create an object then you change the data member of that object, you don't change the data member of that class, so how would the object affect other things in the programs. I can't really explain that well, but I think that makes since.

[tummychow]

You should not create classes in functions unless you intend for them to be local. There is a difference between a class defined outside and one inside. In particular, a local class has a number of restrictions on it that I forget.
Now then, about encapsulation?
The idea of encapsulation is that you create a continuous interface for your class and separate it from the implementation of the class. That way the user has no ability to mess with the way it works. You control how stuff is accessed. Let's say you have to suddenly change the name of a variable. You'd have to go back and change the stuff that uses it. Instead of that you can streamline the function interface that accesses your class. That enables you to change it without fear of backlash. To make sure that people don't mess with variables you encapsulate them - make them private.
I really didn't do that explanation well but I'm too lazy to grab my book of C++ and explain it better right now. Sorry.

[jsmith]

I assume that you mean it uses global variables? (ie, variables that are not declared
inside a struct, class, or function). If so, global variables are rarely a good thing and
can almost always be eliminated. In C++, you should limit the "scope" (lifetime) of
variables to only what is needed.

Public/private. In theory, making data members public breaks encapsulation (one of
the big tenets of OOP) in that it exposes to the user of the class an internal detail of
the class. Moreover, it allows the user to modify the internal state of the class
without the class' knowledge, which means that the class cannot enforce any kind
of invariant (eg, "this here pointer can never be NULL". Well, if the user can just
set it to NULL without the class knowing...)

You are thinking too literally. Suppose you have a class A that has a public int member
named "foo" and you have another function somewhere else that adds 1 to it.

Now suppose later you want to change "foo" from int to std::string. Now your
other function which added 1 to foo is broken because std::string does not allow
you to add integers to strings.

[Duthomhas]

Sam's is not the best course to take in C++...

Beware of always/never rules. They are usually wrong.


Classes (not instances or objects, mind you) should generally be declared outside of functions.

class fooey
  {
  ...
  };

int main()
  {
  fooey foo;  // here we create an instance of the class: an object
  ...
  }

Generally speaking, you should avoid using global variables/objects unless you have a very good reason to do so.

I do not know the context of the quote, so I cannot comment much on it. I think he is making a reference to how an object is accessed - this is the concept of encapsulation, which is part of OO.

The purpose of an object is to abstract and encapsulate its internal properties. An example would be the STL iostreams. You have the standard streams, which read and write to the console. You have file streams, which read and write with disk files. You have sockets, strings, etc. But in all cases, all you need to know to use them is astream << "Hello"; Keep in mind that the way you use them may be specific to the type of stream it is, but the mechanics of using it is the same across all streams.

Hope this helps.

[edit] Good grief, I type slow... [/edit]

[Kieth89]

@ Duoas: What would be a good book to use? I had trouble finding one that starts from the very beginning, like most that I looked at assumed that the reader had general knowledge of programming already, which I don't. Plus I don't really have a wide selection of choices, as the nearest book store is a ways away, and my parents won't use their credit card on the web, and I'm only 16, so no credit card for me (Which is probably a good thing).

Thanks to everyone who responded, thanks for your help. I get it a lot better now (I think).

[tummychow]

Look for a book that covers OO specifically if you really want to understand the material. Most intro books don't do the job too well, because they have to be introductions to the layman first (no offense). C++ Primer 4e, the book I use, does a fair job but the organization of the book isn't too hot, because it tries to be an introduction and a reference.