Thread: practice with classes

Say u wanted to make an employee roster. You could use multiple classes and inheritance. THe base class could be employee which wouldhave the salary and hours worked functions. Then in the other classes which would derive from Employee class they would have individual functions. Say a Construction guy would have a Equipment function to subtract equipment money from his pay.

Well, for a noobish example you could make a Triangle class.

You'd have many things to consider.
Have 3 private data members contain the coordinates of each point. It would also be wise to make an (X, Y) structure to hold both numbers in a easy to handle package.

struct XYpair
{
int theXcord;
int theYcord;
};


Or you could have 3 private data members be the length of each size.


One of the mmbr functions could be getTriangleArea(), which calculates the area of the triangle.

You could also think about optimization. Would it be better to have another data mmbr that stores the area of the triangle, and automatically updates any time the triangle changes, that way if someone repeatedly accesses the triangle's area but changes the triangle very little then you have increrased performance at the sacrafice of having that extra data mmbr taking up space. Or not have the data mmbr and have the area be recalculated everytime the area is requested.

In theory, any problem can be approached using object oriented design. Just think about the objects in a problem. In a bank, employees, customers, and money are all objects. In a zoo, monkeys, lions, and penguins are all objects. In any problem you can just look at the things in your problem and realize, 'hey, I can make that an object.' Whether or not OOP is always the best way to go is up for debate, but you should be able to code out most anything using this approach.

I think that most programmers who were always taught top down design and then learn OOP are most confused by the simplicity of OOP. Everythings an object. It's that simple.