Understanding OOP Concepts

[RaddMadd]

I'm trying to understand the concepts of object oriented programming. (specifically in java) I'm not getting it.

1. first question, what is an internal state exactly?

2. and, "a object stores its state in fields" what does that mean?

3. so, you have an object, the object is in a current state. The object is able to do things (behavior) and can do them using methods, which changes its state. the method operates on an objects internal state (don't know what that means) is this right?

4. and then, i understand what an interface is, but not exactly in programming, only in real life objects lol.

5. so help would be appreciated, also, it would be nice if you could describe what i said up there about an object in a real life object, like for example a car's state, method, behavior, internal state, field etc.

thank you <><

 

[csheppard91]

1. first question, what is an internal state exactly?

If I understand what you're asking, then I would say anything that's not static. Remember, static variables are unique to the actual object, not the instance.
internal state is the variables and attributes that define an object. A bankaccount's balance would be state. A lightbulb being on or off would be state. If you alter state, then you alter some attribute of the object. If I have an object called bankaccount and add $100 to it, then I've altered the state of my object.

2. and, "a object stores its state in fields" what does that mean?

That's a dumb way of saying it stores it's state in a variable:

private int age;

public void init()
{
this.age = 12;
}

//I can change the age variable here.
private void setAge(int newAge)
{
this.age = newAge;
}

State can be altered through *setter* methods like above.


To understand what state actually means, take a look at what a thread is. A thread can be alive, dead or waiting. When a thread is waiting on another thread to execute, then you could say it's state is "waiting". When it's alive it's state is "alive".

3. so, you have an object, the object is in a current state. The object is able to do things (behavior) and can do them using methods, which changes its state. the method operates on an objects internal state (don't know what that means) is this right?

You change an object state through methods such as the setters I described above.

4. and then, i understand what an interface is, but not exactly in programming, only in real life objects lol.

An interface can be implemented to give a class more formal behavior. Inside of the interface, you define the methods you want the class to inherit. If a class implements an interface, it must define those same methods before the class will compile.

interface Car
{
public void go();
}

class Porsche implements Car
{
public void go()
{
System.out.println("I'm driving a porsche"):
}
}

Inside the class I am overriding and giving custom behavior to the method defined in the car interface.

5. so help would be appreciated, also, it would be nice if you could describe what i said up there about an object in a real life object, like for example a car's state, method, behavior, internal state, field etc.

thank you <><

can you show what you've done?

 

[superfly]

first you need to realise that there are *objects* and *classes*

CLASS:
a class is like a template. it contains a definition of what the objects should look like.

OBJECT:
an object is an *instantiation* of a class. its an instance of a class, a "real life" version.

think of it like this: a class is like a cookie cutter. your cookie's shape is determined by the cookie cutter. the cookie itself is the object. it's shape is defined by the cookie cutter, but you can get a whole lot of cookies from one single cookie cutter.

to put this into code:

// your class (the cookie cutter)
class Cookie
{
    public CookieShape shape;
}

// your object (the cookie)
Cookie cookie = new Cookie();

 

[superfly]

ok, now that we're on the same page in terms of classes and objects, let's go a step further. we'll need to change our example to a more complicated one. let's choose the good old apple.

you know what an apple is right? but you know how there are different types of apples?

so the *concept* of an apple is the class. an apple can have a species, a colour, a texture, a taste, a size, etc.

but an actual, real, in-your-hand apple is the object. this apple that i'm holding is a starkey (species), it's red (colour), it's crisp (texture), it's sweet (taste) and it's medium sized (size).

so you see how a class contains properties (indicates a storage space for values), also called members, which tell us the types of attributes an apple has, whereas the object (the actual apple in your hand) has attributes (properties with values). those attributes are specific to that instance of the apple. the value of the colour property is red for my apple. your apple's colour property is the value green.

apples also have actions or methods... an apple can grow for instance (think "apple.grow();"). the definition for this method sits in the class, and then the object performs the method, and something happens to the object.

this is all called encapsulation. the class encapsulates the properties and methods related to the class. this means that all the properties and methods are contained within the class itself.

 

[superfly]

the next step i want to talk about is inheritance.

with inheritance, you can make a child class of the parent class. the child class then inherits all the properties and methods of the parent class.

to continue with our apples, let's say that we wanted to make it easier to use a green apple or a red apple specifically.

at this point i'm gonna have to ask you to please excuse my java, i last did java a while ago, and i currently work almost exclusively with php. so please bear with me if i don't stick to java's syntax - i can't remember it.

so we have a green apple and a red apple class we want to create. but since they are both apples, why do i need to go and rewrite the whole class twice? just inherit from it!

class GreenApple extends Apple {
    public GreenApple() {
        this.colour = green;
    }
}

class RedApple extends Apple {
    public RedApple() {
        this.colour = red;
    }
}

so now what we have done is we have made these two new classes, RedApple and GreenApple. if you were to ask java if RedAppl is an Apple, it will tell you "YES", because it is a descendant of Apple.

in each of the classes' constructors i have pre-set the colour. this is called specialisation. i've created a specialised version of the Apple class. now all my objects that were instantiated from RedApple are by default red in colour.

i don't need to redeclare any of the properties or methods that were in the Apple class, because they are in the RedApple class thanks to inheritance. everything i wanted to do with the Apple class i can do with the RedApple class and the GreenApple class.

what you can do further though is to define custom properties and methods for the inherited classes that aren't in the parent class, and that the inherited class possibly needs.

 

[superfly]

the third and final pillar concept of oop is polymorphism.

for this we'll need a slightly more complicated set of objects for our example. let's use a vehicle, with car, boat and aeroplane.

in a nutshell, polymorphism is changing the behaviour of child classes. this means, in a more programmatical sense, taking a method from the parent class and redefining or overriding it.

a vehicle is something that moves from a to b, so our vehicle class has a move() method. it has 3 child classes which all need to redefine move() because their methods of movement are different.

let's see some code:

class Vehicle {
    public void move() {
        // do some moving!
    }
}

class Car extends Vehicle {
    public override void move() {
        this.startEngine();
        this.gearChange();
        this.accelerate();
    }
}

class Boat extends Vehicle {
    public override void move() {
        this.castOff();
        this.startEngines();
        this.fullSteamAhead();
    }
}

class Aeroplane extends Vehicle {
    public override void move() {
        this.startEngines();
        this.takeOff();
        this.fly();
    }
}

Now, we can use each child class as through they are the parent class, and call the move() method to move them, but then the child class's move method comes into play and moves it according to it's redefinition of the move() method.

this becomes useful if you don't know what the exact permutation of an object might be, but you know it descends from Vehicle.

let's say you have an array of these objects. but you don't know whether each object is a plane, car or boat. well, it's quite simple, just typecast it to a Vehicle, and then use the move method.

Vehicle(vehicles[i]).move();

ok, this example is a little on the lame side, but it shows the principle.

 

[superfly]

right, if you are still with me, you have now understood the 3 pillars of object orientated programming: encapsulation, inheritance and polymorphism.

i want to just go through a few bits of terminology which will help you clarify your questions.

instance:
when you create an object, we say that you're creating an *instance* of a class. this means that you're creating an in-memory, fleshed out object from the class. remember that a class is only a template, it's the objects that do everything.

override:
this is in polymorphism, when you redefine a method in a child class. it's called overriding.

property:
can also be called a member. this holds a value when an object is instantiated.

method:
also called a function. this is an action that can be performed on the object once instantiated.

parent class:
a class that has descendants.

child class:
a class that is a descendant of another class (the parent)

specialisation:
when a class is more specific that it's parent. it might have more methods and/or properties specific to this particular class, or just have certain properties preset. [Vehicle -> Car -> Porsche] follow the arrows for specialisation.

generalisation:
when a class is less specific that it's child. it has more generic methods and/or properties that can appear in a number of child classes. [Vehicle <- Car <- Porsche] follow the arrows for generalisation.

that's all good for now.

 

[superfly]

right, now to get back to answering your question . i just needed to go through all of that because that's the basics of OOP, and if you don't get it right, including the terminology, you're gonna find it difficult to understand what's going on, and people are going to find it difficult to understand you.

1. first question, what is an internal state exactly?

i'm not exactly what you mean here, but i think you're talking about the values of properties in an instantiated object?

2. and, "a object stores its state in fields" what does that mean?

ummm... same as above? values stored in properties of the instantiated object.

3. so, you have an object, the object is in a current state. The object is able to do things (behavior) and can do them using methods, which changes its state. the method operates on an objects internal state (don't know what that means) is this right?

ok, following what i understand you saying previously, we're talking about the properties and methods of the instantiated objects. the methods of those objects can only change their own properties' values. they are (normally) not allowed to directly change the values of another object's properties. does this make sense?

4. and then, i understand what an interface is, but not exactly in programming, only in real life objects lol.

what csheppard91 said was pretty accurate. an interface is an abstract thing (even more abstract than a class), but when you assign an interface to a class, that class HAS to implement EVERYTHING that is in the interface. it's very similar to inheritance, but it isn't the same thing. this is handy when you have a class that is already inherited from another class, because for the normal operation of you program it needs to be like that, but you need it to conform to something else for a few other operations. so you implement this interface, and then typecast your object to the interface if necessary, and it will use the methods and properties from that interface. umm... you savvy?

5. so help would be appreciated, also, it would be nice if you could describe what i said up there about an object in a real life object, like for example a car's state, method, behavior, internal state, field etc.

um.... did that without even looking at your question

if you have any more questions, feel free to pm me.

(sorry for the multiple posts, i wanted to break up the concepts and things, and i'm on dialup, i never know when my connection might go down)

 

[RaddMadd]

thank you both for your replies that helped

<><

 

[csheppard91]

they are (normally) not allowed to directly change the values of another object's properties.

If the access specifier is public, then yes, you can change the values directly, but this is terrible design. It's better to use accessors and mutators.

 

[WeakButHopeful]

Another thing that *might* help you think about an object's state is the question of persistence. In real life applications an object (such as a bank account balance) should not have its state disappear into the bit bucket just because of a power failure, so part of working with objects is considering how to persist (save, store, protect) the state of that object instance to some permanent medium (database, file). The idea is that if you save the states of all your objects then later when the user returns to the web site or after the power is turned back on to a PC or whatever the object instances can be recreated and have their state restored. Since the behavior of the objects is programmed in that is not part of state and does not get persisted.

I would also contrast object oriented programming with procedural programming (first I'll do this, then I'll do this, then if necessary this, etc.) It's like following someone's instructions on how to get somewhere you've never been. If you follow them *absolutely* exactly then you'll get there, but you have little idea of where you are, and better hope a teenager doesn't steal a road sign. That's like procedural programming. But if you have an object oriented understanding of how to get somewhere, then you have an idea of the methods (access ramps, exits) and the state (closed for construction, lots of traffic lights, etc.) of each instance of the class highway involved. It may not be a perfect analogy, but I just wanted to show you why procedural programming can be easier for one shot, simple programs whereas professional programming teams use object oriented concepts to keep from getting lost in the complexity of large applications.