OO confuses me

This isn't strictly C#, but since that's what I'm using , I'll post it here. OO-ing stuff confuses me.

I have a thing, it's say a location.

Code:

class Location
{
    ... coords;
}

Now, I actually want a whole pile of locations, say a grid:

Code:

class Grid
{
    ... dimensions
    Location[,] gridinfo;
}

Now I want different things to use my grid. I want actually the same grid to be used in different ways. I want something to show my grid, but not be able to mutate it. I also want something to mutate my grid, but not show it. So I make two more classes?

Code:

class GridPainter
{
}
class GridMutator
{
}

Now I could inherit a Grid:

Code:

class GridPainter : Grid
{
}

Or I could make its own private grid as a member of it, and write like a copy constructor, taking a Grid as an argument to the initializer:

Code:

class GridMutator
{
    Grid mutate;
    GridMutator( Grid toMutate ) { mutate = toMutate; }
}

(Except that's not actually a copy constructor, and it wouldn't even be worth using one here, since on the mutator I actually do want to mangle what I'm being passed, not just a copy of it).

I don't understand how to decide what is best. OO has always confused me, because I'm used to straight up C. I kinda get the is-a / has-a thing, but I'm still hung up on this. I'm not even sure there isn't another better way to do either of these.

See the Mutator has-a grid, actually it should be that it receives-a grid - or can I inherit a grid and have it be operating on the original? Ok, I make a base instance:

Code:

Grid mine = new Grid( 100, 100 );

Now I want to make a Mutator that works off of this one. Does this work? Does it even make sense?

Code:

GridMutator mut = new GridMutator( mine );

Is that even right? I don't get the inheritance thing. I mean I see how you can do it, if you just make a new instance, but what if I want to use an existing one? Do you not use inheritance there?

I'm too old to learn new tricks I think.


Quzah.

I also want something to mutate my grid, but not show it.

You could declare a function within the grid class to do so, if I'm not totally mistaken about what you mean by 'mutate'.
my_grid.mutate(/*params*/);
is much more natural than what you were trying.

By mutate I just mean have it change parts of it in a specific way. Lets turn this into cars:

Code:

class Car
{
    ...things a car has...
}

class CarModifier
{
    ChangeWindows() {}
    ChangeTires() {}
    ChangeEngine() {}
}

class CarOperator
{
    Start() {}
    Stop() {}
    RollDownWindow() {}
    RollUpWindow() {}
    Wash() {}
}

I want two distinct interfaces. I want to be able to specify the parts of the car, and I want to have someone be able to operate the car, but the person that operates the car doesn't get to be the person that swaps out the engine. Like the difference between your mechanic, and you driving the car around.

So that's the same sort of thing as my earlier example. I don't want the interface that lets you get values from the locations to be the same one that lets you change them.

I guess I'm just not sure how to correctly assign two different interfaces to the same set of data.


Quzah.

Then you could use inheritance....which solves your problem about passing the car around.

Can I inherit the same object twice?

Code:

class Car {}
class Driver : Car {}
class Mechanic : Car {}
...
Car mycar = new Car();
Driver me = mycar; // ? that doesn't seem right
Mechanic bob = mycarr // ?

I don't understand how to make a new class inherit an existing object, or even if you can. It all seems like you can make a new class have properties of the other class, but not actually make a Driver have the car attached, then un-attach the car, and hand it to the mechanic.

That's why I say OO confuses me.


Quzah.

I was confused by it too...because I was thinking in terms of C++..where making interfaces can be a lot of trouble.

But I just found out that C# supports 'interface's like java, which is just made to address this problem.
Now I understand why C# is touted as friendly !

You can always have the car as an attribute. I'll make an example with cars.

Code:

class Car
{
/*put either public attributes and only have mechanic touch them, or make them private and make Mechanic a friend of Car*/
}
class Driver
{
Car myCar;
public Driver(Car setCar)
{
myCar = setCar;
}
class Mechanic
{
Car myCar;
public Mechanic(Car setCar)
{
myCar = setCar;
}
/*either make the mechanic a friend of the car, or use public car attributes with functions that you put HERE*/
}
//usage
Void main()
{
Car mCar = new Car();
Driver me = new Driver(mCar);
Mechanic Joe = new Mechanic(mCar);
return;
}

You cannot inherit an OBJECT. Inheritance means that the class will get everything except the protected parts from the base class. Like in IO. You got a class that opens a file, so both in and out classes can inherit, since both need to open a file!

The reason you have to either make Mechanic and Car friends or have the Car attributes public is that Mechanic needs either one to access Car attributes.
Making them public is the easy way, friend system is harder, but more secure.

I was just looking at interfaces too.

C# 4.0 Programming: Interfaces

I think I'm going to have to just pass Car around to whoever needs it, because I don't think there is a way to have multiple interfaces attached to the car without all of them being available to everyone who wants to use the car:

Code:

class Car : IDriver, IMechanic
{
}
...
Car mycar = new Car();

mycar.SomeMechanicThing();
mycar.SomeDriverThing();

I think every instance of Car would let you both drive and be the mechanic. So I think I have to do:

Code:

Car mycar = new Car();

Mechanic mymechanic = new Mechanic( mycar ); // attach my car to this mechanic
mymechanic.DoesAllTheMechanicWork();
...
Driver me = new Driver( mycar );

Or maybe I can get away with having a Driver interface, so the mechanic can drive the car to see if it works, but not give the driver a mechanic interface, so that I don't take my car apart and not know how to get it back together again.

I was thinking for some reason that you could have an instance of an object, then make an instance of an object that inherits that type sort of extend onto the previous:

Code:

Car mycar = new Car();
Driver me = mycar; // inherit my settings from mycar
me.DriveAround();
me.Crash();

Mechanic mymechanic = mycar; // give him my car
mymechanic.FixCar();

But I don't think that works, so the limited interface thing might work. I'll have to mull it over some more.


Quzah.

I'm actually trying to draw a portion of a grid, specified by bounds. I'm also trying to do stuff to the grid, separately. The thing that draws only needs to be able to see the grid, not mess it up. The thing that modifies the grid doesn't need to show it. I have my base data chunk, and different things need to do different things with it.

Code:

class Grid {}
class Viewer
{
    private readonly Grid data;
    public Viewer( Grid g ) { data = g; }
    public void Display( Vector2 ul, Vector2 lr ) { ... draw that chunk of the grid }
}
class Mangler
{
    private Grid data;
    public Mangler( Grid g ) { data = g; }
    public void Fill( Vector2 here ) { data[here.X,here.Y].Value = something; }
    public void Empty( Vector2 here ) { data[here.X,here.Y].Value = somethingelse; }
}

I guess I'm going to have to end up with something like that. That's what I had in the first place, but it just seemed like there should be a better way to do that than to have to keep passing my grid around.


Quzah.

Originally Posted by manasij7479

I was confused by it too...because I was thinking in terms of C++..where making interfaces can be a lot of trouble.

But I just found out that C# supports 'interface's like java, which is just made to address this problem.

A C++ abstract base class without member variables (except maybe static const member variables) is a pure interface that is akin to a C# or Java interface construct.

Originally Posted by quzah

I think I'm going to have to just pass Car around to whoever needs it, because I don't think there is a way to have multiple interfaces attached to the car without all of them being available to everyone who wants to use the car:

Yes and no. Yes, because the Car would implement all the interfaces. No, because if you pass a Car through a particular interface, the Car may only be accessed/modified through that interface.

I suggest reading about the Interface Segregation Principle (PDF; C++ examples).