Turns out typical oop (object oriented programming ) with its nested inheritance structures can
be neatly defined using high school set theory knowledge.
some definitions:
A set is a mathematical ideology for a group.
A group of things. Not to be confused with the same mathematical object , group , in group theory.
In real i.e physical life, we have no problem with the idea of a group.
like a fridge - for holding food. A school bag for holding books and stationery,
a wallet for holding money etc. An office for holding staff,machines,puters,and bosses.
operations on sets include - query for membership.
e.g
in the set of alphabets - a,b,c,e....z. the number 1 isnt a member of that set.
2.) intersection
two sets intersect to create another set.
the result of an intersection is a set , which contains elements that both sets have in common.
e.g
if A = letters in the word fish
B = letters in the word meat
A intersection B = null/empty set. cuz fish and meat have no letters in common.

3.) Union,
union is analogous to mathematical addition.
with a union the combined sets create a larger resultant set.
e.g
A = letters in the word fish
B = letters in the word meat
A union B = fishmeat.

Application to oop.
-----------------
Memberships and inheritance . Relationships can be modelled using set theory.

lets say Ade is a father and he works as a teacher in a secondary school and is married to Ada.

oop constructs would be:

class Father{

public abstract int number of children();
}

class/interface Employee{
public string nameOfWorkPlace();
public string nameOfOccupation();
}

class Man{
public String Name();
public Sex Sex(){return Sex.MALE;}
}

Father extends Man{}

A problem quickly arises.
Many abstract classes and interfaces have to b created to model the relationship
properly.
like a human class has to be super class from which male and female sub classes are derived
etc.
Employee has to be made an interface to work around single inheritance problems etc

it goes on and on ...

With set theory - it gets flatter and easier.
Father = set of all fathers.
Employee = set of all employees
Male = set of all men
Wife = set of all wives
etc
Person = an object that is a base element in the sets.
A person can be amember of more than 1 set . Logical.
so lets create the person object and register it with its respective set.
Person adeP = new Person("Ade",M);
lets create the fathers set. Fathers = Set.createSet("Fathers";
Fathers.register(adeP);
etc...
querying.
is ade a father?
Fathers.isMember(adeP) = if it returns affirmative - you gat your answer.
in oop , the solution is clumsy - traversing the inheritance tree!!- yikes. hyper ugly.

is ade an employee?
Employee.isMember(adeP)?

is ade a Husband?
Husbands.isMember(adeP)?

lets say - ade gets fired from his teaching job.
what happens - he exits the set of employees and joins the set of JobSeekers.
Employees.disMember(adeP) .
JobSeekers.register(adeP);

etc

Ade dies . he leaves the set of living things . joins set of deceased.

More work...
in a set theoretic language. Objects would be broken into two broad classes. Sets, elements.
A set can contain sets.
all the contents in a set are elements.
elements can tell what sets they belong to.
e.g
Ade /person object could be queried directly to determine what sets it belongs to.
Person.getBelongingSets(); // returns a Set of names of sets it is members of.
etc

Outcomes:
Actually using this approach - one thing stands out.
Multiple inheritance (thinking c++) here is more natural and reflective of real life relationships than
single inheritance. With single inheritance mechanism of mainstream oop, lots of scaffolding has to be
written to model relationships properly and even with that it just doesnt work right . Think
interfaces,abstract classes,etc.