Need a little help understanding objects

  • (3 Pages)
  • +
  • 1
  • 2
  • 3

30 Replies - 3897 Views - Last Post: 12 March 2013 - 09:56 PM

#1 spertuit  Icon User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 6
  • Joined: 02-February 13

Need a little help understanding objects

Posted 02 February 2013 - 10:56 AM

I'm trying to get the logic right behind classes, objects, methods, properties, and all that jazz.

Let's say we have a class called "Car", the car has properties, or attributes..color, weight, model,etc
This car has methods...stop, go, turn, etc...

I understand that, but what if I want a weight reduction on the car. This is something that would modify the properties of the car. What would this be considered?

Would this be a method of the "Mechanic" class that would just modify the properties of the instanced objects of the class Car?

Is This A Good Question/Topic? 0
  • +

Replies To: Need a little help understanding objects

#2 Ryano121  Icon User is offline

  • D.I.C Lover
  • member icon

Reputation: 1362
  • View blog
  • Posts: 3,002
  • Joined: 30-January 11

Re: Need a little help understanding objects

Posted 02 February 2013 - 11:04 AM

You would probably have a mutator method in the Car class to reduce the weight of the car by a certain amount e.g

public void reduceWeight(int howMuch) {
   weight = weight = howMuch;
}


Then you have a method in the Mechanic class to perhaps reduce the weight of a car

public void reduceWeightOfCar(Car car) {
    // some logic here to determine how much to reduce it by
    car.reduceWeight(someAmount);
}


Now you could just make the weight attribute public so it's accessible to anyone, but thats bad design as anyone can change it's value anywhere. You can see here that I could put a check in the reduceWeight method to check if I will be reducing it by more than its current weight which of course is not possible. I could then produce an error if this happened. Making the field public however you could not do these checks to keep the integrity of the attribute. This is encapsulation - one of the founding ideas of object oriented programming.

So really you have a method in the Car class to do something to the attribute of the Car, you then allow other classes (i.e the Mechanic) to use this method to do something.

I think I've gone off in a bit of a tangent here, but I hope I've answered your question.
Was This Post Helpful? 1
  • +
  • -

#3 modi123_1  Icon User is offline

  • Suitor #2
  • member icon



Reputation: 9206
  • View blog
  • Posts: 34,588
  • Joined: 12-June 08

Re: Need a little help understanding objects

Posted 02 February 2013 - 11:06 AM

In theory - yeah. Either your program is the 'mechanic' class and it operates/interacts with the object, or you build a mechanic class that has a 'car' property.
Was This Post Helpful? 1
  • +
  • -

#4 spertuit  Icon User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 6
  • Joined: 02-February 13

Re: Need a little help understanding objects

Posted 02 February 2013 - 11:12 AM

I'm going to research "mutator methods". I had the understanding that methods where actions the object could perform. This throws off my thinking. The reduction is something being done to the car, so this is an action being formed to the object.
I'll pick apart your post and research each part to understand this more.

I appreciate the detailed response. I am very skilled in procedural coding, but for some reason I'm having a difficult time grasping object oriented.

View Postmodi123_1, on 02 February 2013 - 11:06 AM, said:

In theory - yeah. Either your program is the 'mechanic' class and it operates/interacts with the object, or you build a mechanic class that has a 'car' property.



I'm lost on the idea of giving the mechanic a car property. The mechanic would be manipulating the "Car" object. Would you somehow tie the property "car" of the mechanic to the instanced object of the "Car" class?
Was This Post Helpful? 0
  • +
  • -

#5 spertuit  Icon User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 6
  • Joined: 02-February 13

Re: Need a little help understanding objects

Posted 02 February 2013 - 11:18 AM

View PostRyano121, on 02 February 2013 - 11:04 AM, said:

You would probably have a mutator method in the Car class to reduce the weight of the car by a certain amount e.g

public void reduceWeight(int howMuch) {
   weight = weight = howMuch;
}


Then you have a method in the Mechanic class to perhaps reduce the weight of a car

public void reduceWeightOfCar(Car car) {
    // some logic here to determine how much to reduce it by
    car.reduceWeight(someAmount);
}


Now you could just make the weight attribute public so it's accessible to anyone, but thats bad design as anyone can change it's value anywhere. You can see here that I could put a check in the reduceWeight method to check if I will be reducing it by more than its current weight which of course is not possible. I could then produce an error if this happened. Making the field public however you could not do these checks to keep the integrity of the attribute. This is encapsulation - one of the founding ideas of object oriented programming.

So really you have a method in the Car class to do something to the attribute of the Car, you then allow other classes (i.e the Mechanic) to use this method to do something.

I think I've gone off in a bit of a tangent here, but I hope I've answered your question.



This would mean that the method in the mechanic class is the "getter", or the "
accessor" and the method in the car class is the "setter". This keeps the integrity of the encapsulation.
Am I on the right track?
Was This Post Helpful? 0
  • +
  • -

#6 modi123_1  Icon User is offline

  • Suitor #2
  • member icon



Reputation: 9206
  • View blog
  • Posts: 34,588
  • Joined: 12-June 08

Re: Need a little help understanding objects

Posted 02 February 2013 - 11:22 AM

You may be getting lost in the words to objects. Sometimes that doesn't translate to a hard line.

As I said there are multiple ways to set this up (and it depends on how they will be used), but in general you would have a car object... which has variables, properties, and methods.

Then you would have a mechanic object. A mechanic object would have a car variable... because a mechanic can only work on one car at a time. The mechanic then has methods like 'do oil chance' or 'fix unicorns poking holes in the exhaust' and so forth... but it needs a car object to do that.
Was This Post Helpful? 1
  • +
  • -

#7 spertuit  Icon User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 6
  • Joined: 02-February 13

Re: Need a little help understanding objects

Posted 02 February 2013 - 11:31 AM

View Postmodi123_1, on 02 February 2013 - 11:22 AM, said:

You may be getting lost in the words to objects. Sometimes that doesn't translate to a hard line.

As I said there are multiple ways to set this up (and it depends on how they will be used), but in general you would have a car object... which has variables, properties, and methods.

Then you would have a mechanic object. A mechanic object would have a car variable... because a mechanic can only work on one car at a time. The mechanic then has methods like 'do oil chance' or 'fix unicorns poking holes in the exhaust' and so forth... but it needs a car object to do that.



I see what you mean now. It basically depends on if the program is based off the actions of the mechanic or if it is based off the car.
Was This Post Helpful? 0
  • +
  • -

#8 Ryano121  Icon User is offline

  • D.I.C Lover
  • member icon

Reputation: 1362
  • View blog
  • Posts: 3,002
  • Joined: 30-January 11

Re: Need a little help understanding objects

Posted 02 February 2013 - 11:33 AM

Not quite. I don't know what language you are using to start OOP, but here goes.

Methods are things that give behaviour to objects. A big part of this is allowing other objects to retrieve or change the attributes of an object. Lets give a definition of your Car

class Car
{
    // private so no other object can directly access it (discussed above)
    private int weight;

    // we have the 'do' methods as you thought
    public void go() {}

   // But then we have 'accessor' methods that allow other objects to retrieve and therefore use the attributes of this class. In this case the only attribute is the weight, so we provide a method that returns it
   public int getWeight() {
      return weight;
   }

   // We also have 'mutator' methods that can directly modify the attributes of the class. In this case we subtract a value from the weight. Here we are CHANGING the value which is not the case for the accessor which is simply returning its value somewhere.
   public void reduceWeight(int howMuch) {
       // add more logic here
       weight = weight - howMuch;
   } 
}


So now we have our Car class with accessors, mutators and other methods to 'do stuff'.

We can now have our Mechanic class that encapsulates a Car object. Same thing as above instead of instead of an int we use a Car.

class Mechanic
{
    // private so no other object can directly access it (discussed above)
    private Car car;

   // We have our accessor to retrieve the Car object the mechanic is currently working on
   public CargetCar() {
      return car;
   }

   // We also have 'mutator' methods. In this case we modify what Car the mechanic is working on
   public void setCar(Car newCar) {
       // add more logic here
       car = newCar;
   } 

   // But now we have our 'do' methods that well do stuff with our properties. In this case we have our Car which we can call methods of to change its attributes

   public void reduceWeightOfCar() {
       // some logic here to determine how much to reduce by
      car.reduceWeight(someAmount);
   }
}


That's pretty much one of the main concepts of OOP. We encapsulated an integer called weight in our Car and defined methods to retrieve its value and change its value (reduceWeight). We also defined the 'do' methods like go().

Then we encapsulated a Car object in our Mechanic class. Again we provided accessors to get the Car, mutators to change the car being worked on, and 'do' methods that can do stuff on the attributes. In this case we used the mutator method of the Car class .reduceWeight to change the value of its attribute weight.

I hope I haven't confused you more there.

Edit - aah syntax highlighting as failed me in that code. Sorry about that.

This post has been edited by Ryano121: 02 February 2013 - 11:34 AM

Was This Post Helpful? 3
  • +
  • -

#9 spertuit  Icon User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 6
  • Joined: 02-February 13

Re: Need a little help understanding objects

Posted 02 February 2013 - 12:06 PM

Excellent reply, I ran through your code and understood all of it except one part is a little cloudy to me.
The variable car in mechanic. The idea of this variable is not actually any type of link to the object but more like
an ID in a database, if I'm making sense.

For instance if I did a loop statement and would increment i
Than I would say car = i, and than would call car.reduceWeightOfCar(500)
In this case if the objects of the Car class would be 1,2,3,etc
This would perform the weight reduction to all the objects, but your code maintains encapsulation by keeping the variables private.

I know that's a little sloppy, but I'm just trying to wrap my head around the logic. I'm currently working in Objective-C, my background is strong in web development.(PHP)
Was This Post Helpful? 0
  • +
  • -

#10 Ryano121  Icon User is offline

  • D.I.C Lover
  • member icon

Reputation: 1362
  • View blog
  • Posts: 3,002
  • Joined: 30-January 11

Re: Need a little help understanding objects

Posted 02 February 2013 - 12:40 PM

I think you half get it.

The variable car is a reference to a car object somewhere in memory. It can point to any car but only one at a time.

You said that the variable is not a link to the object, but it kind of is really. It's a pointer to the object if you are familiar with pointers. But you also said thats its an id in a database which in an abstract way is kind of true if you consider memory as being a sort of database. You hold an id (or a reference) to a location in memory (or the database).

I think you are trying to move on to arrays of Car objects after that, not just simply references. Not sure if thats intentional.
Was This Post Helpful? 1
  • +
  • -

#11 spertuit  Icon User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 6
  • Joined: 02-February 13

Re: Need a little help understanding objects

Posted 02 February 2013 - 01:30 PM

Pointer, makes sense now.
Thanks for all your help. I'm finally getting to the point with Objective-C where I can manipulate the data and get some feedback displaying. Hopefully by tonight I can write a program with a little complexity.
Was This Post Helpful? 0
  • +
  • -

#12 Skydiver  Icon User is offline

  • Code herder
  • member icon

Reputation: 3576
  • View blog
  • Posts: 11,117
  • Joined: 05-May 12

Re: Need a little help understanding objects

Posted 03 February 2013 - 05:53 PM

I'm sorry to butt into this thread, but I have to point out a hole in the logic:

Quote

Now you could just make the weight attribute public so it's accessible to anyone, but thats bad design as anyone can change it's value anywhere. You can see here that I could put a check in the reduceWeight method to check if I will be reducing it by more than its current weight which of course is not possible.


The method reduceWeight() is still public. So anyone can still change the weight of the car. It's not limited to just a Mechanic that can change the weight. It's anybody who can access the public method.

class BankRobber
{
    private Car MiniCooper = new Car();

    public ImproveCarForBankHeist()
    {
        MiniCooper.reduceWeight(165);
    }
};


Was This Post Helpful? 0
  • +
  • -

#13 BobRodes  Icon User is offline

  • Your Friendly Local Curmudgeon
  • member icon

Reputation: 574
  • View blog
  • Posts: 2,989
  • Joined: 19-May 09

Re: Need a little help understanding objects

Posted 04 February 2013 - 03:20 PM

View PostSkydiver, on 03 February 2013 - 06:53 PM, said:

I'm sorry to butt into this thread, but I have to point out a hole in the logic:

Quote

Now you could just make the weight attribute public so it's accessible to anyone, but thats bad design as anyone can change it's value anywhere. You can see here that I could put a check in the reduceWeight method to check if I will be reducing it by more than its current weight which of course is not possible.


The method reduceWeight() is still public. So anyone can still change the weight of the car. It's not limited to just a Mechanic that can change the weight. It's anybody who can access the public method.

class BankRobber
{
    private Car MiniCooper = new Car();

    public ImproveCarForBankHeist()
    {
        MiniCooper.reduceWeight(165);
    }
};



Actually that isn't quite so, because you can put logic in the method to make sure that the caller is entitled to make the change. You can't do that if you make the attribute public.
Was This Post Helpful? 0
  • +
  • -

#14 BobRodes  Icon User is offline

  • Your Friendly Local Curmudgeon
  • member icon

Reputation: 574
  • View blog
  • Posts: 2,989
  • Joined: 19-May 09

Re: Need a little help understanding objects

Posted 04 February 2013 - 04:11 PM

spertuit, encapsulation means that the internal implementation of an object is hidden from the user of it, and that it exposes its functionality via a known interface. This promotes code reusability.

This concept of interface has been around in hardware of all sorts for a long time, pretty much since Henry Ford with his systems of interchangeable parts. (You can think of software objects as interchangeable parts, too, and not be inaccurate.) Suppose you have a toaster. For it to work, you have to plug it in. Now, you have a lamp. For it to work, you have to plug it in. And now a power saw. Also have to plug it in. The point is that the wall socket and plug are examples of interfaces, and also of encapsulation. We don't care how electricity flows through the cord. We just care that if we want our appliance to work, we have to plug it into a wall socket (and of course, we have to have power). We are hiding the details of electrical engineering, and exposing the result through an interface: the power cord and socket. This interface is ubiquitous, and doesn't change so long as you don't leave the country. In other words, it is highly reused.

Similarly in software objects, we have attributes (characteristics of an object) and methods (stuff an object does). These attributes (we'll say "properties" to be more accurate; I'll explain that next) and methods comprise the object's interface. One of the things that an object does is set the value of attributes, and get the current value of them when asked. Those are the mutator and accessor methods that ryano is describing. A combination of an attribute and its mutator and accessor methods is generally what is called a "property."

Of course, objects do other things besides interact with their attributes, so there are plenty of other methods besides these specialized ones.

Another thing that objects do is associate with other objects. One way to formalize this is to have an attribute of one object that is actually a reference to an instance of another object. So, a mechanic works on a car. The mechanic object will have a car attribute which is a reference to an existing car object. The mechanic object will have mutator and accessor methods that will allow, say, a service writer to assign a car to a mechanic, or to see which mechanic is working with a given car. Then the mechanic will have other methods, say changeTire(whichOne), changeOil(), pullEngine(), etc.

There are other ways to formalize object associations that are more rigidly defined. Aggregation implies that the objects are in some way intrinsically related. For example, a Car object will be an aggregate of other Part objects. Next, Composition implies that objects are not only intrinsically related as in Aggregation, but have a shared lifetime. If you are running a junkyard, you would keep track of a Car's parts independently of the car; you could remove a Seat from inventory without removing the Car. That's aggregation. However, if you were running a car factory, this would not be the case: once you added the Seat to the Car object, the Seat would no longer be considered a separate entity, and would be bound permanently to the Car object. That's composition. So you see that whether to use simple association, aggregation or composition is often dependent on context.

For further information on this, you might want to investigate UML Class diagrams. I hope all this sheds further light on the subject for you.

This post has been edited by BobRodes: 04 February 2013 - 04:17 PM

Was This Post Helpful? 2
  • +
  • -

#15 Skydiver  Icon User is offline

  • Code herder
  • member icon

Reputation: 3576
  • View blog
  • Posts: 11,117
  • Joined: 05-May 12

Re: Need a little help understanding objects

Posted 04 February 2013 - 06:22 PM

View PostBobRodes, on 04 February 2013 - 05:20 PM, said:

View PostSkydiver, on 03 February 2013 - 06:53 PM, said:

I'm sorry to butt into this thread, but I have to point out a hole in the logic:

Quote

Now you could just make the weight attribute public so it's accessible to anyone, but thats bad design as anyone can change it's value anywhere. You can see here that I could put a check in the reduceWeight method to check if I will be reducing it by more than its current weight which of course is not possible.


The method reduceWeight() is still public. So anyone can still change the weight of the car. It's not limited to just a Mechanic that can change the weight. It's anybody who can access the public method.

class BankRobber
{
    private Car MiniCooper = new Car();

    public ImproveCarForBankHeist()
    {
        MiniCooper.reduceWeight(165);
    }
};



Actually that isn't quite so, because you can put logic in the method to make sure that the caller is entitled to make the change. You can't do that if you make the attribute public.


Yes, it quite true that you it's difficult to do that kind of checking on a public attribute. I'm having a hard time visualizing how you would do the check to make sure that the caller is entitled to make changes in a language neutral manner, and without muddling the method parameters to take some kind of authorization or identity object.
Was This Post Helpful? 0
  • +
  • -

  • (3 Pages)
  • +
  • 1
  • 2
  • 3