Few newbie questions.

Pages: 12
I am entering the real deal- object-oriented programming.
I want you hardcore programmers to answer a few questions and feed my brain for a bit.Don't go too hard on me if these questions are repost.

1.) (Class) why do we need get-and-set functions?how is it different from just
litterally 'declaring' the variable as public? What is the advantage of using it?

2.) Struct vs Class.Which one?

3.)what is different between constructor/destructor and the get-and-set function? I mean,to me,it just looks the same.

4.) is constructor/destructor useful? in which cases?

5.) When and in which situation is class/struct useful?

6.) What's the real 'meaning' of object-oriented programming?


- Please explain any of these questions as if you're explaining to a 5-year-old kid.Any help will be appreciated.I will be waiting for your answers brothers and sisters!


-Minwoo Ju
Last edited on
1) You don't. Lol. But the point of having classes is re-usability and encapsulation. Let's say you have a function that takes a string, converts it to a number, then adds 10 to it, and stores it inside a variable of the class. What is the point of this function if someone can directly change the variable by themselves? And what if you don't want anyone changing that variable? Make it a private member, and use get-and-set functions to limit what the user can do with the variable.

2) Google is your friend.
http://forums.codeguru.com/showthread.php?t=332571
http://msdn.microsoft.com/en-us/library/aa288471%28v=vs.71%29.aspx
http://social.msdn.microsoft.com/forums/en-US/Vsexpressvb/thread/6923cbe6-12b7-4e97-a4f5-3d9ebdfc75f2

3) constructor is called when an object is created. destructor is called when an object is destroyed. Definitely not the same. What exactly are YOU looking at?

4) They are extremely useful. Especially when you start using dynamic memory.

5) Google.

6) Classes. Classes are templates for objects.

- Go and read a book. If you are entering the real deal, then read a real deal book. A simple C++ book can teach you a lot more, and a lot faster, than asking questions on a forum.
1- set/get functions are important for version consitency, and for good code management. Setting a variable with the first version of your program may be acceptable when you first write your program; but in the future, you may need to update some other variable when this first variable is changed. set/get methods solve this dilemma, where the user will still have the same interface independent of what is being done inside.

2- structs or classes are exactly the same, only that structs are a follow-up from C language. Use classes to follow the C++ program paradigm. The only practical difference between structs and classes, is that classes have private access by default, and structs have public by default.

3- A constructor is the class that gets called when the object of your class is created. It's a method, with which, you can ensure that all your variables are initialised when the object is created. Destructors are exactly the opposite, where they're called when the object is destroyed, and their purpose, in general, is ensuring that all memory clean-up calls are done.

4- I explained in $3.

5- classes (or structs) are useful for realistic things. You may create a class for a light-bulb, and give it the methods on() and off(). Or you may create a class for 2D shapes, and have a method called area to calculate the area, so that you could store different shapes in different objects. (Read more about object oriented programming. I don't think we can explain everything here).

6- Object oriented programming is the new approach programming of Black-Box. Where you could create a "black-box", and have some inputs/outputs attached to it, and another programmer could take this black-box and use it without even knowing what you programmed inside it. It's a way for specialisation, per se.

For example, I could create an array class and call it vector (which exists), and make it very nice for you to use, where it allocates memory automatically, and resizing it is a very easy task for you, and you can take it and use it without even knowing what the hell is going on inside it. That's the whole purpose of object orriented programming.


The break-through of Windows XP over Windows ME was successful due to the XP programming approach, which involves:

1- Object oriented programming
2- Programming in pairs (so 2 programmers program stuff together to ensure better reusability).

Object oriented programming is the reason why operating systems are extremely stable compared to 12 years ago (Windows ME and 98, where we needed to format our computers every 3 months).

Hope this helps :)
Last edited on
In regards to number one, I don't understand why college courses push the idea of accessors and mutators. In very few situations does this not break encapsulation.

Anyone else have any opinions (differing or not) on this?
1) A get and set function set can help to filter or format values on their way in or out. For example:
1
2
3
4
5
void myclass::set_percent(float percent) { 
  if (percent > 100) _percent = 100;
  else if (percent < 0) _percent = 0;
  else _percent = percent;
}


Or perhaps the value is an output value only and not meant to be set or an input value and not meant to be used for other things.

2) Really the only difference is that classes are private by default and structures are public. Some people will say that structures are deprecated, but I prefer them if there in instances where I just need a few basic types without special constructors, private members or member functions. I use classes whenever I need templates, member functions, inheritances, unknown sized members (like strings) or anything more complicated.

3) A constructor is called when an object is created. Let say that your class will be for network communication. You might use the constructor to open a port and establish communication. The destructor would terminate communication and close the port. It's more intuitive to do this in a function IFF it needs to be done once and only once. Another example would be opening a file for logging. If you are just storing types in a class, then the constructor is an easy way of initializing the class, it serves no greater purpose in that case.

4) See my answer to #3.

5) A little tough to explain. A class' scope is up to you. It could be used to schedule your entire program, by containing a timer callback funciton, an initial function (called by the constructor) and a iterating function called every X milliseconds by the callback function. It could also just contain someone's name and employee number, then be used an an array to keep the values togeather and associated.

6) let's say that you are simulating a car. You might program the properties of a tire. The elasticity, how it can handle torgue, the friction during braking, the tread wear/life, etc. Now a car has 4 tires, so are we going to write 4 versions of each function and of each parameter of the tire? No! What if a tire falls off, it would be a mess to code! In object-oriented programming we would program the properties of only one tire, then use it over and over as an object. If our car has 5 tires, then we just create 5 objects of the tire class.

If it's a multi-engined aircraft, we only need to program one engine, then make more instances of it. If we are programming a restaurant, we would only program one glass and then make many copies of it. We could also program a few different types of glasses: wine glasses, beer glasses, champaign flutes, coffee mugs, etc. All of these would have something in-common: They can all hold liquid. Therefore we could program that property only once and then all of these containers could inherit that property. Now it starts to get deeper.
In all situations, accessors and mutators should not break encapsulation.
If they do, then the programmer is doing it wrong.
Wiki says:
In a programming language, encapsulation is used to refer to one of two related but distinct notions, and sometimes to the combination[1][2] thereof:

- A language mechanism for restricting access to some of the object's components.[3][4]
- A language construct that facilitates the bundling of data with the methods (or other functions) operating on that data.[5][6]
Last edited on
I guess accessors are more 'safer' way of using class data.I kind of get it.I think I know why declaring data public can cause disasters.

I guess it's like beating around the bush- using sneaky methods to use the data that is prohibited from you.I 'think' that way,the program can be more neat and safe to use.

I know I should be reading from a book,but you see,I'm in that awkward age where I'm kind of limited to resources.So please excuse me.
Exactly. Safer is always better. There are good reasons to declare some data public and some private.

Ah. I see. In that case, reading tutorials on line and asking questions is probably the most you can do for now. This isn't a bad thing. But, don't start your questions off with a condescending voice. Everything is done for a reason. No one would want to write an entire book on something that is wrong and useless.
Also. By using mutators and accessors, the user doesn't have to do as much work.

private data member:
string myName = "eric";

public accessor method:
char * getNameAsCString () {...};

As you can see here. If the user wants 'myName' as an array of characters instead of a string, the class has a method for that. Now the user can move on with what he is doing and not have to worry about making his own string to cstring converter.
Last edited on
Actually, getters and setters should be avoided whenever possible. Most of the time they break encapsulation and are little to no better than just straight out making the field public.

Naturally they can't always be avoided, but they can more often than most people seem to imagine.
ahh,I apologise.I was just trying to be all friendly.I guess I really do need to read from a book.I'll try and get my hands on the books.

What books would you recommmend that handles these kind of things pretty well?

I'll try to get my hands on them.
Actually. They do not need to be avoided. They are useful just like everything else in the world. If you think we should toss them all out because YOU don't know what to use them for, then you should reconsider your outlook on life.

A whole class can be avoided. Doesn't mean it should be.
If you know the user wants some data to be displayed in three different ways, then what would you do?

1) make three data members with the three possible ways. (think about how much extra memory is being used if the member is an array of 10000000 characters.)

2) make three functions to convert the stuff back and forth.
Last edited on
hanst09 but what about times where you have to do complicated things and make certain amount of things in the program within the class?

I think,with just a guess,that accessors will be good if you handle them well.It might as well be safe,and produce a satifysing results.Just my guess.
Last edited on
you know,it MIGHT just avoid bugs when you program things that handles alot of data.
Hmm. I'm not sure what books will do you good these days. Any typical book will have typical information. But is sounds like you are looking for "the best choice" kind of book. You'll just have to do some research and hope you find the book for you.
yeah.As I said,I'm limited to resources,so the books have to be the 'best choice possible'.
Yeah. What hanst99 meant to say is:

"Actually, getters and setters should be checked and rechecked again whenever possible. Some times, bad programmers make them break encapsulation, which result in them being little to no better than just straight out making the field public."

That is a good answer.
Also. To back up my argument.

Look at C#. They put set and get functionality directly into the code. And don't you dare say C# is a crap language or this thread might blow up.
Last edited on
I heard C# is a bit underrated and it's actually a good language to learn.Might move onto that one once I'm fluent in C++.
Pages: 12