11 Replies - 487 Views - Last Post: 05 November 2017 - 11:10 AM Rate Topic: -----

#1 geos59  Icon User is offline

  • New D.I.C Head

Reputation: 1
  • View blog
  • Posts: 46
  • Joined: 30-August 15

Understanding objects.

Posted 04 November 2017 - 11:06 AM

I already know about classes, there a place to store variables (usually private) and functions (usually public) that belong to that class.

What I don't understand is what is the point of an object? For a function that I created in header file, why can't I just call that function - why do I need to create an object first? (Like instead of objectName.FunctionName(); why can't you do something like FunctionName();?)

Also does a object of a class contain (perhaps contain is the wrong word) the variables inside? [If not, how do I access the variables?] FYI I do know that I can make getters/setters to access the variables, I'm just wondering if an object that you create has any of the actual variables inside it.]

TLDR:

1.) What's the point of an object?

2.) Why can't I just call the member function by itself - why do I have to associate an object with the member function?

3.) Are the member variables you create in a class actually within the object? If not (like I assume is the case), then how do you use them? [Besides getters/setters]

My point about #3 is - couldn't I just access the variables in the class and use them rather than create an object?

Is This A Good Question/Topic? 0
  • +

Replies To: Understanding objects.

#2 sepp2k  Icon User is offline

  • D.I.C Lover
  • member icon

Reputation: 2512
  • View blog
  • Posts: 3,992
  • Joined: 21-June 11

Re: Understanding objects.

Posted 04 November 2017 - 01:27 PM

Non-static members belong to the object, not the class. So each object has its own set of the member variables defined in its class.

Think of a Person class with the members name and age. Let's say there you create two objects of type Person: Alice and Bob. It make sense to ask "What's the age of Alice?" or "What's the age of Bob?", but it doesn't make sense to ask "What's the age of Person". There is no age that applies to all Persons, each Person has their own age.
Was This Post Helpful? 0
  • +
  • -

#3 jon.kiparsky  Icon User is offline

  • Chinga la migra
  • member icon


Reputation: 10690
  • View blog
  • Posts: 18,308
  • Joined: 19-March 11

Re: Understanding objects.

Posted 04 November 2017 - 01:51 PM

Quote

What's the point of an object?

Object-oriented programming is ultimately a design pattern, which is reified in certain languages as a language construct. The point of the pattern is to simplify design and maintenance by associating functionality with the data that it relates to.
Thus, objects (instances of a class) can be thought of as nouns which come pre-packaged with state and potential actions. The actions are defined independently of the state of any particular instance, so they should behave sensibly for any instance of that class.

So the point of any particular object is to represent something in your program and provide access to the functionality that that thing needs to execute in order to be itself.

Quote

Why can't I just call the member function by itself - why do I have to associate an object with the member function?


If you mean, why are functions associated with objects, well, that's just the way OO programming is set up. You could certainly write programs without objects - people do it all the time. Then you'd want to find some other principle on which to organize your code and keep it maintainable as it grows in complexity. Many programmers have come up with many ways to solve this problem, take your pick.
If you mean, why is it set up that way, it's because it makes the most sense to do it that way. A in instance method is designed to work on the instance of which it is a method. It doesn't make sense to get into a car, insert the key into the ignition, and then decide which car you're going to start up, does it? And you would find it suprising if your car asked you which battery you wanted to draw power from and which engine you wanted to start, wouldn't you? In the same way, instance methods operate on their instances because this reduces the potential for confusion and error in the user and the maintainer.

Quote

Are the member variables you create in a class actually within the object? If not (like I assume is the case), then how do you use them? [Besides getters/setters]


Depending on what you mean, the answer is "yes, but not exactly". Obviously, specifics vary from language to language but in general when you instantiate an object, you are asking your machine to allocate a certain area of memory which will be used to store the data in your object. In a language like Java or C, some of that data will be in the form of primitives like integers and characters and so forth. These primitives are final data and live directly in the area of memory you've been granted. Other data will also be objects, and these will be "stored" as pointers to their actual locations in memory. Also, class variables are stored separately from any instance in most languages (if not all), and must be referenced by looking at the object's class - how this is organized is language-dependent, but the overall idea is pretty consistent.

So if you mean "is all of the composing this object located in a single coherent block in memory addressed by this object?", the answer is no. Some of it is parceled out in other areas of memory. If you mean "is all of the data related to this object's instance fields accessible through the instance?" then the answer is "yes, absolutely".

All of that is sort of vague and abstract. If you have further questions, make them more specific for better results.
Was This Post Helpful? 2
  • +
  • -

#4 #define  Icon User is offline

  • Duke of Err
  • member icon

Reputation: 1852
  • View blog
  • Posts: 6,661
  • Joined: 19-February 09

Re: Understanding objects.

Posted 04 November 2017 - 02:31 PM

A class is basically a data type and an object is a variable of that type.

There is one class but there can be many objects (or instances) of that class.
Was This Post Helpful? 0
  • +
  • -

#5 snoopy11  Icon User is online

  • Engineering ● Software
  • member icon

Reputation: 1378
  • View blog
  • Posts: 4,320
  • Joined: 20-March 10

Re: Understanding objects.

Posted 04 November 2017 - 02:54 PM

Thats a great answer jon,

Again your technical knowledge shines through... !

Objects yeah, whats the point ?

To encapsulate data in a better way primarily,

Objects can be created or destroyed as required in your program.

This increases functionality and decreases overhead,

For example you may create a Sprite Object for a Direct X or OpenGL game.

This means you can create or destroy multiple Sprites in your program,

when and if required the advantages of this are many and obvious,

The class manages the lifetime of the Sprite, creating new resources or

releasing them without you having to constantly write huge swathes of code.

Just create a new instance and away you go.... or call delete on the Object and

again overhead reduced...

Of course this doesn't just apply to Games, it could be database Tables with complex

SQL algorithms that you don't have to constantly rewrite just to create or destroy a new

Table...

The list of uses for Objects are only limited by your imagination really...
Incredibly useful things !
Was This Post Helpful? 1
  • +
  • -

#6 geos59  Icon User is offline

  • New D.I.C Head

Reputation: 1
  • View blog
  • Posts: 46
  • Joined: 30-August 15

Re: Understanding objects.

Posted 05 November 2017 - 10:02 AM

@jon.kiparsky

For the member variables inside the object question (#3), I mean if you created a class like letís say a car class:

class Car
{
private:

int price;
int year;
};



And then you created an object of that class (Ex: Car limo) - would the int values price and year already be inside the object automatically or is there a way to access them manually?

Hopefully thatís more descriptive.
Was This Post Helpful? 0
  • +
  • -

#7 jon.kiparsky  Icon User is offline

  • Chinga la migra
  • member icon


Reputation: 10690
  • View blog
  • Posts: 18,308
  • Joined: 19-March 11

Re: Understanding objects.

Posted 05 November 2017 - 10:15 AM

I'm not sure what you mean by the variables "being inside" the object. Can you say more about what this would mean?
Was This Post Helpful? 0
  • +
  • -

#8 GazinAtCode  Icon User is offline

  • D.I.C Head

Reputation: 18
  • View blog
  • Posts: 70
  • Joined: 26-September 16

Re: Understanding objects.

Posted 05 November 2017 - 10:26 AM

View Postgeos59, on 05 November 2017 - 10:02 AM, said:

And then you created an object of that class (Ex: Car limo) - would the int values price and year already be inside the object automatically or is there a way to access them manually?


Not sure I understand correctly, but they could just be totally unrelated values found at that particular location in memory.

You could make those fields public and access them from outside the class:
class Car
{
public:
    int price;
    int year;
};

int main()
{
    Car limo;
    limo.price = 50000;
    limo.year = 2010;
}



Or keep them private and set them at object creation using a public constructor:
class Car
{
public:
    Car(int price, int year)
    {
        this->price = price;
        this->year = year;
    }
private:
    int price;
    int year;
};

int main()
{
    Car limo(50000, 2010);
}


Was This Post Helpful? 1
  • +
  • -

#9 geos59  Icon User is offline

  • New D.I.C Head

Reputation: 1
  • View blog
  • Posts: 46
  • Joined: 30-August 15

Re: Understanding objects.

Posted 05 November 2017 - 10:39 AM

Yes this! This is what I mean. I like the second example better as the variables are still private and you're using a constructor.

So when you create a member variable - you have to use the objectName(Member Var, Member Var) like the second example.

I guess the member variable is inside the class and the object is just an empty vessel you use for your member variables and member functions?

This post has been edited by ndc85430: 05 November 2017 - 10:43 AM
Reason for edit:: Removed quote of previous post. Just press "Reply" in future.

Was This Post Helpful? 0
  • +
  • -

#10 ndc85430  Icon User is offline

  • D.I.C Lover
  • member icon

Reputation: 597
  • View blog
  • Posts: 2,494
  • Joined: 13-June 14

Re: Understanding objects.

Posted 05 November 2017 - 10:47 AM

View Postgeos59, on 05 November 2017 - 05:39 PM, said:

I guess the member variable is inside the class and the object is just an empty vessel you use for your member variables and member functions?


I don't know what you mean by "empty vessel". The class defines what it means to be a Car in this case - i.e. it has a price and a year. Each object will have its own values for those variables.

Also, please note that there's no need to quote the previous post in its entirety. Just use the "Reply" button in future, please.
Was This Post Helpful? 0
  • +
  • -

#11 GazinAtCode  Icon User is offline

  • D.I.C Head

Reputation: 18
  • View blog
  • Posts: 70
  • Joined: 26-September 16

Re: Understanding objects.

Posted 05 November 2017 - 10:49 AM

Yes, it's good practice to keep member variables private and set (and possibly get) them via constructors or member functions.

And yeah, they are empty in the sense that they don't contain any meaningful data at first, but in C++ they're not automatically set to 0. You could use a default constructor for that.

class Car
{
public:
    Car()
    {
        this->price = 0;
        this->year = 0;
    }
    Car(int price, int year)
    {
        this->price = price;
        this->year = year;
    }
private:
    int price;
    int year;
};

int main()
{
    Car limo; // now you're sure they're both 0
}


This post has been edited by GazinAtCode: 05 November 2017 - 10:49 AM

Was This Post Helpful? 1
  • +
  • -

#12 jon.kiparsky  Icon User is offline

  • Chinga la migra
  • member icon


Reputation: 10690
  • View blog
  • Posts: 18,308
  • Joined: 19-March 11

Re: Understanding objects.

Posted 05 November 2017 - 11:10 AM

View PostGazinAtCode, on 05 November 2017 - 12:49 PM, said:

Yes, it's good practice to keep member variables private and set (and possibly get) them via constructors or member functions.


The practice of using setters and getters is questionable, to be honest. Yes, the member variables should be private, and yes, if the user of the class wants to set them their access should be controlled to avoid unfortunate states, but it's not clear to me for most objects why you'd want to allow other classes to have access to the internal workings of this class. After all, the point of an object is to encapsulate the data and provide the functions needed to work on that data - so why should any other class ever have "need to know"? The same goes doubly for setters - once the object is created, it's not clear to me that there's a good case for allowing other objects to set state directly. Instead, they should call methods which ask the object to take some action, which might modify its state.


Quote

And yeah, they are empty in the sense that they don't contain any meaningful data at first, but in C++ they're not automatically set to 0. You could use a default constructor for that.


+1
Was This Post Helpful? 1
  • +
  • -

Page 1 of 1