Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[EnigmaticHat]

Functionally I'd describe an object as a container that you put variables into, and methods for manipulating those variables.  Whereas a non-static class is a blueprint or mold for an object.

Think of it like this: in Super Mario Brothers, there was only one Mario, so you could just make marioX, marioY, ect. as single variables.  But there's an indefinite number of enemies.  You could go and make enemy1X, enemy1Y, enemy2X, enemy2Y, enemy3X, enemy3Y ect.  This would require manually naming a ton of different variables and then writing some pretty silly code to know which variable to refer to at a given time.  Or you could make an enemy object that stores all those variables and then have as many or as few of that object as you need at the time.  Functionally its about the same thing but writing it out using OOP is much cleaner.

[Rose]

Except that in this case, there is one enemy class, which has x and y variables, as well as probably enemy type.

And then there's a bunch of enemy objects, each of which have the x and y actually set.

the class says that an enemy has an x and a y position.

An object says that this enemy has x = 15, and y = 20

[TheBiggerFish]

EnigmaticHat:That doesn't make sense.  An object containing all the enemies is a rather useless thing because you still have to code the enemies and you'd be re-implementing arrays.  And the enemies are objects. 
And Mario is an object, not a primitive type.  He's got stuff he does and states to store.

[TheBiggerFish]

To be honest, almost all examples of sub-classing are bad examples. The mechanism itself is very over-rated, and leads to poor code that's hard to maintain. It's just an example.

For example, the canonical "person, student, teacher" example is very obviously flawed. What do you now do if a teacher themselves enrols in a subject?

Uh...They get a separate instance as a Student?  I mean, that's what would happen at an actual school I'd think...

[Reelya]

But now you have two references of the same data, e.g. their address. If they move, you have to update records in two separate places, which is less than ideal as a "solution" to the problem, and sort of defeats the original purpose of doing the inheritance-thing.

[TheBiggerFish]

Yes, but the teacher being a student isn't dependent upon their being a teacher.

[Reelya]

That's not the issue. Your database now has redundancy in it, and the potential for mismatched data that that entails.

The whole point of having the heirarchy of "person" at the top and subclasses of "student" and "teacher" becomes broken if you have two separate people in the database who are the same person: you shouldn't have done the inheritance that way. That's the point.

It also doesn't deal well with changes of status. If a student leaves, they're no longer a student, but they should still be in the database. So you'd want to set them to "person", "alumni" and possibly "teacher" in the future. But that entails making a new object and deleting the old object, which is ... messier than needed.

[TheBiggerFish]

You're right, I guess.

[Skyrunner]

To be honest, almost all examples of sub-classing are bad examples. The mechanism itself is very over-rated, and leads to poor code that's hard to maintain. It's just an example.

For example, the canonical "person, student, teacher" example is very obviously flawed. What do you now do if a teacher themselves enrols in a subject?

Some of the better examples of subclassing seem to usually be basically interface - implementation cases. Eg, python's unittest module, or XNA's Game class where you can hook up your onRender, onUpdate events and let the rest of the engine handle everything else.

[Antsan]

It's a joke. In Python there's no distinction between classes, objects, or structs. They're just classes.

Nah, you're wrong. They're all objects, only that classes are objects that are also used to instantiate other objects.

The examples used by the others were kind of strange, because they were about inheritance, not instanciation.
There is the "dog" class. Our dog "Dina" is an instantiation of that class, that is, an object of type "dog".
As far as I know in Python the "dog" class is also an object of some class that probably is called something like "class".

To be honest, almost all examples of sub-classing are bad examples. The mechanism itself is very over-rated, and leads to poor code that's hard to maintain. It's just an example.

For example, the canonical "person, student, teacher" example is very obviously flawed. What do you now do if a teacher themselves enrols in a subject?

You use automated multiple inheritance. There was a library for lisp with which you could do this:

Code: [Select]

(make-instance '(teacher student))
It would automatically create the subclass of the classes "teacher" and "student" (if it wasn't defined already) and than make an instance of that class.

[Avis-Mergulus]

To be honest, almost all examples of sub-classing are bad examples. The mechanism itself is very over-rated, and leads to poor code that's hard to maintain. It's just an example.

For example, the canonical "person, student, teacher" example is very obviously flawed. What do you now do if a teacher themselves enrols in a subject?

Yeah, that seems like something you'd use to describe compounding instead of inheritance. Like, we're all persons, but we have slots for different roles, of which there may be more than one?

[Reelya]

Yeah, you make everyone just a Person, and have a "subject" class, which has a "Person *teacher" and a list of "Person *students". If the number of students grows really large, to the point that doing a search for what classes someone is in would use too much CPU time, then each person can themselves have a list that cross-references what "roles" they currently have: but this part is optional.

We can learn a lot here from how relational databases do things. With poorly planned OOP sometimes we invent overly-complex "solutions" that have very obvious flaws, which already have perfectly working solutions in the database world. You can implement the same patterns in your code.

Dynamic multiple inheritance might seem like a cool idea, but it's not something you can implement in more than a handful of languages. It's not a solution that you can e.g. roll out in a Java or C# version of your library, and has real issues in C++ such as the diamond problem. Additionally, if each subclass modifies the data of the parent class, then what happens when both modify the parent data? That breaks the principle of encapsulation, since now the two sub-classes need to know what each other are doing.

If you do things from the subject -> person direction, you just avoid all the above problems.

[Putnam]

EnigmaticHat:That doesn't make sense.  An object containing all the enemies is a rather useless thing because you still have to code the enemies and you'd be re-implementing arrays.  And the enemies are objects. 
And Mario is an object, not a primitive type.  He's got stuff he does and states to store.

they worked in assembly, no explicit classes AFAIK

actually, I know this stuff somewhat, here's my implementation of Super Metroid's enemy structure in lua (for SMHack, which I feel like working on again actually):

Code: [Select]

local enemyMeta={}

enemyMeta.__newindex=function(t,k,v)
    local base=0xF7A+(t.id*0x40)
    if k=='pos' then
        mainmemory.write_u16_le(base,v.x)
        mainmemory.write_u16_le(base+4,v.y)
    elseif k=='hp' then
        mainmemory.write_u16_le(base+0x12,v)
    end
end

enemyMeta.__index=function(t,k)
    local base=0xF7A+(t.id*0x40)
    if k == 'pos' then
        return {x=mainmemory.read_u16_le(base),y=mainmemory.read_u16_le(base+4)}
    end
    if k=='collisionBox' then
        local camx = mainmemory.read_u16_le(0x000911)
        local camy = mainmemory.read_u16_le(0x000915)
        local worldx=mainmemory.read_u16_le(base)
        local worldy=mainmemory.read_u16_le(base+4)
        local screenx = worldx - camx
        local screeny = worldy - camy
        local xrad = mainmemory.read_u8(0x0F82 + (t.id * 0x40))
        local yrad = mainmemory.read_u8(0x0F84 + (t.id * 0x40))
        return {x1=screenx + (xrad * -1),y1=screeny + (yrad * -1),x2=screenx+xrad,y2=screeny+yrad}
    end
    if k=='hp' then
        return mainmemory.read_u16_le(base + 0x12)
    end
end

enemyMeta.__tostring=function(t)
    return 'Enemy: '.. 0xF7A+(t.id*0x40)
end
local enemiesMeta={}

enemiesMeta.__index=function(t,i)
    local oend = 20
    local base = 0xF7A
    if i > 0 then
        base = 0xF7A + (i * 0x40)
    elseif i>oend or i<0 then
        return nil
    else
        base = 0xF7A
        i=0
    end
    local enemyTable={id=i}
    setmetatable(enemyTable,enemyMeta)
    return enemyTable
end

enemiesMeta.iter=function(t,k)
    k=k+1
    local v=t[k]
    if v then return k,v end
end

enemiesMeta.__pairs=function(t)
    return enemiesMeta.iter,t,-1
end

enemiesMeta.__ipairs=enemiesMeta.__pairs

sm.enemies={}
setmetatable(sm.enemies,enemiesMeta)

"__index" is called whenever you try to ask for a nonexistent index in a table. So if I type sm.enemies[3], it'll give me a table that begins at memory index 0xF7A+(3*0x40). Huh, you're actually right, I did just sorta reimplement arrays. But Lua doesn't have arrays like C++ does, so that's fine.

actually really looking at that they basically just implemented OOP into assembly didn't they

EDIT: this is actually really cool already, wow. I have functions to read and write Samus's position, hp, missiles, super missiles, power bombs and speed boost state right now. Like, I type sm.samus.super_missiles.cur and it'll tell me how many super missiles she currently has available to use (i can replace "cur" with "max" to get the total).

EDIT 2: I even wrote an iter function for the enemies haha what I can just sorta go

Code: [Select]

for k,enemy in ipairs(enemies) do
  enemy.hp=1
end


[i2amroy]

Yeah, the person, teacher, student stuff is pretty bad, and honestly I find that most "real-world" examples don't work very well as sub-classes. Where I do find it works fairly well is with more "gamified" type of stuff. For example:

Code: [Select]

    Creature
     /    \
  Human  Simple Monster
  /   \
NPC  PlayerWith a system like this we can have a basic "Creature" class that defines the basic things that the vast majority of creatures need (creation functions, blood type data (or lack thereof), corpse creation calling. Then from then we can split down into Monsters (that have reduced data stored, only a single health pool, and other simplified features) from humans (that have body part tracking, can equip weapons, and so forth). Then humans can be further subclassed into whether they are NPC's (including the AI code and so forth) or Players (in which case you include the UI code). (Alternatively if you wanted more intelligent monsters you might consider splitting along the "Intelligent/Animal" boundary and then maybe a second split of Intelligent along the "Interactive/Noninteractive").

Examples like that work well because as part of a game you are able to define clear-cut boundaries that lend themselves well to subclasses, and their use allows for sensible "defaults" to automatically exist for the vast majority of things, reducing the amount of code that you actually need to manually implement. Real-world examples, on the other hand, are rarely as simple and well-defined enough to lend themselves well to subclasses due to their overlaps and mutability as time goes on.

[Malus]

All this talk about inheritance and OOP and subclassing just reminds me of this great blog post from one of the programmers of The Witness.

Relevant excerpt:

Spoiler (click to show/hide)

We all know how to program in C++, don’t we? I mean, we’ve all read a selection of wonderful books by the gaggle of bearded fellows who defined the language in the first place, so we’ve all learned the best ways to write C++ code that solves real-world problems.

First, you look at the real world problem — say, a payroll system — and you see that it has some plural nouns in it: “employees”, “managers”, etc. So the first thing you need to do is make classes for each of these nouns. There should be an employee class and a manager class, at least.

But really, both of those are just people. So we probably need a base class called “person”, so that things in our program that don’t care whether you’re an employee or a manager can just treat you as a person. This is very humanizing, and makes the other classes feel less like cogs in a corporate machine!

There’s a bit of a problem, though. Isn’t a manager also an employee? So manager should probably inherit from employee, and then employee can inherit from person. Now we’re really getting somewhere! We haven’t actually thought about how to write any code, sure, but we’re modeling the objects that are involved, and once we have those solid, the code is just going to write itself.

Wait, shoot — you know what? I just realized, what if we have contractors? We definitely need a contractor class, because they are not employees. The contractor class could inherit from the person class, because all contractors are people (aren’t they?). That would be totally sweet.

But then what does the manager class inherit from? If it inherits from the employee class, then we can’t have managers who work on contract. If it inherits from the contractor class, then we can’t have full-time managers. This is turning out to be a really hard programming problem, like the Simplex algorithm or something! OK, we could have manager inherit from both classes, and then just not use one of them. But that’s not type-safe enough. This isn’t some sloppy JavaScript program! But you know what? BAM! I’ve got the solution right here: we templatize the manager class. We templatize the manager class on its base class, and then everything that works with manager classes is templatized on that as well!

This is going to be the best payroll system ever! As soon as I get all these classes and templates spec’d out, I’m going to fire up my editor and get to work on the UML diagrams.

Needless to say, I've been a happier programmer ever since I stopped worrying about classes and objects up-front and just refactored my code as my understanding of the solution to the problem it was solving grew.