Objektorienterad programmering, varför?

Det är ett sätt att abstrahera problem. Vissa problem är lättare att hantera när man kan använda objektbegreppet. Ett bra exempel är t.ex. GUIn, där det är väldigt vettigt att representera knappar och dylikt med objekt.

Strukturen i större projekt, samt återanvändningen av kod. Det blir enklare att skriva projekt som kan växa, om man tänker ut sina objekt och klasser ordentligt.

Det är som You säger, ett annat sätt att tänka och se på saken.

Från The C++ Programming Language [Special 3rd Edition], Bjarne Stroustrup, section 24.3, p. 732:

Tycker det beskriver OO ganska bra. Du skapar ex. ett objekt av en klass som i sig innehåller ett gränssnitt för användaren. Du slipper känna till krångliga detaljer och du kan skapa väldigt portabla klasser på ett sätt som inte är lika enkelt med funktioner.

Ex. har jag lagt ganska mycket tid på att lära mig microsofts ODBC, istället för att kontinuerligt använda det (enligt mig) ganska avancerade gränssnittet så byggde jag en klass som förenklar användandet för mig så jag kan fokusera på att använda enbart ett fåtal relevanta funktioner men ändå behålla de viktiga delarna från ODBC.
Istället för att bygga funktioner runt varje anrop till ODBC som hanterar felmeddelanden etc. så sköter min klass det. Istället för typ:

if(SQLAllocHandle(/* .. */) != SQL_SUCCESS){
	//Hantera felmeddelanden etc.
} //Upprepa för varje "Handle" som man behöver, totalt 3 eller 4 stycken

SQLReturn = xx; 
if(xx != SQL_SUCCESS && xx != SQL_SUCCESS_WITH_INFO){
		//Hantera felmeddelanden etc.
} //Försök ansluta, kan bara göras om de tidigare gått bra
else if(xx == SQL_SUCCESS_WITH_INFO){
	//Hantera felmeddelanden men fortsätt programmet
}

Jag kan inte fortsätta om ex. SQLConnect inte innebär någon form av success. Då måste jag bygga in någon form av ex. enum som håller koll på programmets status åt mig, detta måste jag hålla koll på överallt i programmets gång.
I min klass kan jag skriva ex.

minKlass x(/*...*/);
x.connect();
if(x.errMssg() != 0)
	errmssgstruct minErrmsg = x.getMssg();

if(x.state() == READY)
	x.prepare(/*SQL statemnt */);

Jag tycker det senare är mycket enklare att läsa och hantera. Jag har förenklat funktionerna så allt jag behöver känna till är enkla kommandon som connect och prepare, samt hur strukturen för felmeddelanden ser ut. Koden är ren och fin samtidigt som klassen är portabel och relevant för mig.
Klassen håller reda på olika former av datatyper åt mig, hur den vet om det finns olästa felmeddelanden etc., med funktioner hade jag varit tvungen att pilla in allt i funktioner som hade gjort mig tvungen att fokusera mycket energi på hur koden ser ut i main() istället för att separera det så jag fokuserar på en bra klass och en bra main.

Man hade kunnat skapa en funktion som kallar mindre funktioner som utför de olika stegen. Funktionen hade sedan kunnat returnera ett värde som visar vad som hänt etc., men jag är kvar i att jag i main måste hålla koll på alla datatyper som krävs, hur många meddelanden som finns etc., alltså fokus från själva programmet till att få ihop funktionerna rätt.
Håller funktionen reda på datatyper, status, felmeddelanden etc. så är det Nästan en klass. Skillnaden är att alla funktioner är åtkomliga för mig som användare. I en klass kan man begränsa åtkomsten så man inte kan missbruka funktionerna. Du kan alltså skapa funktionalitet och säkerhet på ett väldigt smidigt sätt.

Om någon tycker jag har fel så rätta mig gärna! Det är så här jag ser på OO i alla fall.

OO är ett väldigt brett begrepp. Man kan säga att det innefattar dels rent tekniska saker som klasser, objekt och namespace:s. Men också lite mer abstrakt designtänk så som inkapsling och datagömning.

Eftersom begreppet är så brett är det konstigt att fråga sig varför man ska använda OO. Man använder OO hela tiden mer eller mindre. Till och med när du skriver en vanlig funktion så skulle man kunna säga att man gör lite enkel OO.

Till vad man ska använda vilka tekniker (OO eller annan) kan man bara utröna efter den speciella situationen man är i. Men en bra sak att tänka på är att inte allt i ett projekt behöver vara OO eller vice versa. Det bästa är oftast att blanda lite olika tekniker och använda sunt förnuft.