C++: Ska man endast skapa klasser om man tänker objektorienterat?

Permalänk

C++: Ska man endast skapa klasser om man tänker objektorienterat?

Jag har länge kört C och jag gillar språket. Det är enkelt, minimalt, men man får ändå jobbet gjort. Det tar dock lång tid att programmera, men kvaliteten blir hög på koden.

Nu har jag börjat med C++ för jag ska göra skrivbordsapplikationer och mobila applikationer igenom QT. Jag stöp direkt. Trots detta så är jag väldigt van att skriva Java kod då jag använder Spring Boot väldigt mycket för servrar.

Men det jag märkte när jag använde C++ är hur krångligt det var att få till en fin projektstruktur. Man skulle ha en klass för allt.
Jag är väldigt noga med att ett projekt ska ha en tydlig och logisk struktur, annars blir det skit på slutet.

Så till att börja med så vill jag ställa er fråga:
Om ni använder klasser som enbart funktioner, skulle ni då gå över till funktionsprogrammering då?

Exempelvis detta är en databasklass i C++.

Database_handling::Database_handling(){} Database_handling::Database_handling(QString SQL){ this->qSqlDatabase = QSqlDatabase::addDatabase(SQL); if(!this->qSqlDatabase.isDriverAvailable(SQL)){ QMessageBox::information(nullptr, "Driver", "Driver " + SQL + " is missing", QMessageBox::Ok); } } bool Database_handling::connect_SQL(const QString& hostname, const int port, const QString& schema_name, const QString& table_name, const QString& username, const QString& password){ /* Set connections */ this->qSqlDatabase.setHostName(hostname); this->qSqlDatabase.setPort(port); this->qSqlDatabase.setDatabaseName(schema_name); this->qSqlDatabase.setUserName(username); this->qSqlDatabase.setPassword(password); /* Open the database */ if(this->qSqlDatabase.open()){ /* Create table if not exist */ create_table(table_name); return true; } return false; }

Men jag skulle enkelt kunna skriva om ovan till detta nedan. Så vad föredrar ni om ni endast ska använda klasser som en samling av funktioner? Ska man använda klasser om man verkligen ska använda objekt t.ex. bilar, eller ska man använda funktionsprogrammering?

Jag känner att funktionsprogrammering är den bästa metodiken här då static QSqlDatabase qSqlDatabase; är redan privat och jag kommer inte kunna komma åt den, om jag inte skapar en QSqlDatabase get_qSqlDatabase() [return qSqlDatabase;} funktion.

Ett problem jag ser med koden ovan är att man måste ständigt tänka "Dependency Injection", medan, det behöver man inte i denna kod nedan. Då är det bara anropa, för fälten är redan statiska.

static QSqlDatabase qSqlDatabase; void create_SQL_database(QString SQL){ qSqlDatabase = QSqlDatabase::addDatabase(SQL); if(!qSqlDatabase.isDriverAvailable(SQL)){ QMessageBox::information(nullptr, "Driver", "Driver " + SQL + " is missing", QMessageBox::Ok); } } bool connect_SQL_database(const QString& hostname, const int port, const QString& schema_name, const QString& table_name, const QString& username, const QString& password){ /* Set connections */ qSqlDatabase.setHostName(hostname); qSqlDatabase.setPort(port); qSqlDatabase.setDatabaseName(schema_name); qSqlDatabase.setUserName(username); qSqlDatabase.setPassword(password); /* Open the database */ if(qSqlDatabase.open()){ /* Create table if not exist */ create_table(table_name); return true; } return false; }

Permalänk
Medlem

Om du har en samling funktioner och inget tillstånd att lagra så finns det ingen mening med att implementera dem som statiska metoder i en klass i C++, utan då kan man lika gärna bara stoppa dem i ett namespace istället.

Men skillnaden mellan din klass och den omskrivna koden är att du i den omskrivna koden endast kan ha en enda databas, eftersom din kod faktiskt har ett tillstånd. Detta är en av orsakerna till att man normalt vill undvika globala variabler, eftersom det gör koden svårare att återanvända om man t.ex. senare kommer på ett man behöver flera databaser. Din omskrivna kod garanterar inte heller att databasen faktiskt initialiseras eftersom användaren kan strunta i att anropa create_SQL_database (d.v.s. du använder inte RAII).

Sen rekommenderar dokumentationen för QSqlDatabase att du inte sparar den i en variabel (se första paragrafen som börjar med "Warning:"), utan använder QSqlDatabase::database när du behöver komma åt databasen. Om jag hade skrivit motsvarande kod i C++ så hade jag implementerat det som en klass med namnet på databasen som instansvariabel.

Permalänk
Skrivet av perost:

Om du har en samling funktioner och inget tillstånd att lagra så finns det ingen mening med att implementera dem som statiska metoder i en klass i C++, utan då kan man lika gärna bara stoppa dem i ett namespace istället.

Men skillnaden mellan din klass och den omskrivna koden är att du i den omskrivna koden endast kan ha en enda databas, eftersom din kod faktiskt har ett tillstånd. Detta är en av orsakerna till att man normalt vill undvika globala variabler, eftersom det gör koden svårare att återanvända om man t.ex. senare kommer på ett man behöver flera databaser. Din omskrivna kod garanterar inte heller att databasen faktiskt initialiseras eftersom användaren kan strunta i att anropa create_SQL_database (d.v.s. du använder inte RAII).

Sen rekommenderar dokumentationen för QSqlDatabase att du inte sparar den i en variabel (se första paragrafen som börjar med "Warning:"), utan använder QSqlDatabase::database när du behöver komma åt databasen. Om jag hade skrivit motsvarande kod i C++ så hade jag implementerat det som en klass med namnet på databasen som instansvariabel.

Så du rekommenderar att man tänker det dära "OOP"-tänket med klasser, i klasser, i klasser i klasser?

Jag tror att jag ska tänka på det du säger. Jag fortsätter med klasser då.

Permalänk
Skrivet av perost:

Om du har en samling funktioner och inget tillstånd att lagra så finns det ingen mening med att implementera dem som statiska metoder i en klass i C++, utan då kan man lika gärna bara stoppa dem i ett namespace istället.

Men skillnaden mellan din klass och den omskrivna koden är att du i den omskrivna koden endast kan ha en enda databas, eftersom din kod faktiskt har ett tillstånd. Detta är en av orsakerna till att man normalt vill undvika globala variabler, eftersom det gör koden svårare att återanvända om man t.ex. senare kommer på ett man behöver flera databaser. Din omskrivna kod garanterar inte heller att databasen faktiskt initialiseras eftersom användaren kan strunta i att anropa create_SQL_database (d.v.s. du använder inte RAII).

Sen rekommenderar dokumentationen för QSqlDatabase att du inte sparar den i en variabel (se första paragrafen som börjar med "Warning:"), utan använder QSqlDatabase::database när du behöver komma åt databasen. Om jag hade skrivit motsvarande kod i C++ så hade jag implementerat det som en klass med namnet på databasen som instansvariabel.

Jag citerar igen för jag kände inte att mitt svar var bra förklarat.

Vi säger så här. Om du sitter i en situation där du känner att vanlig funktionsprogrammering kommer lösa problemet, skulle du då välja att strukturera upp ditt projekt i klasser då?

Jag ser att funktioner är enklare att strukturera för att med klasser så måste man alltid ha andra objekt i konstruktören.

Ett objekt som har objekt som konstruktör, och det objektet har ett objekt som konstruktör osv. Detta finner jag rätt svårt då i QT så finns det inget som heter Dependency Injection.

I t.ex Spring Boot så använder man bara @AutoWire på ett fält och vipps så finns ett färdigt objekt där. Superbra och perfekt. På så sett kan man använda vanlig funktionsprogrammering utan att tänka djupt på projektets struktur hur det ska byggas.

Permalänk
Inaktiv

C++ är ett multi-paradigm språk. Du kan blanda. Du bör blanda om du känner att det är bättre för lösningen Frågan hur mycket du ska avvika från objektorienteringen. Jag tar ett exempel.

I min spelmotor (15 000 rader eller nåt, bra strukturerat) har jag mycket grejer som jag kan kalla för "Objekt" då blir klasserna skisser för dessa. Med objekt menar jag som för en textur, en 3D-modell, ett ljud osv. Sedan har jag några få cpp filer som bara innehåller t.ex. systemnära grejer där det inte behövs en klass alls enligt mig. Utan snarare sådant jag vill ska vara globalt tillgängligt så fort man inkluderar headern. Har inget med klasserna Texture, Model eller Sound att göra alls tycker jag.

Exempel på en sådan funktion som är fristående är att hämta var användarens hemkatalog befinner sig på filsystemet. Ofta är sådana här funktioner för mig också totalt oberoende av externa globala variabler. De tar bara indata och skickar tillbaka något resultat (oftast). Ett annat exempel på en bra funktion att inte ha i en klass är varianter på logg-funktion som tar en std::string och skriver ut med std::cout eller annat beroende på plattform.

Men ett tips också, out of topic, man ska vara noggrann med, använd inte globala variabler som inkluderas hejvilt hit o dit. Det kan skapa kaos i designen av större program... Globala funktioner efter inkludering av en header är dock OK.

Lycka till.

Permalänk
Hedersmedlem
Skrivet av heretic16:

Ett objekt som har objekt som konstruktör, och det objektet har ett objekt som konstruktör osv. Detta finner jag rätt svårt då i QT så finns det inget som heter Dependency Injection.

Har du något exempel på det där? Spontant känns det som att man i sådana lägen vanligtvis har ett naturligt objekt att skicka in (till exempel this eller den naturliga ägaren till det nya objektet (det används ju ofta för att se till att minne frigörs vid rätt tillfälle).

Men som sagt får man göra som man vill, men undvik dålig och svårhanterad kod. Publika globala tillstånd är som sagt en felkälla man ofta vill undvika.

Permalänk
Skrivet av Elgot:

Har du något exempel på det där? Spontant känns det som att man i sådana lägen vanligtvis har ett naturligt objekt att skicka in (till exempel this eller den naturliga ägaren till det nya objektet (det används ju ofta för att se till att minne frigörs vid rätt tillfälle).

Jag har ett exempel.

Tänk typ om du har en klass och i denna klass så ska det vara flera klasser som fält. I dessa fällt, som också är klasser, så har den också klasser som fält.

Detta finner jag onödigt. Hela programmet som man skriver blir bara 1 stort objekt, som innehåller massvist med objekt, som innehåller massvist med objekt och så vidare.

Citat:

Men som sagt får man göra som man vill, men undvik dålig och svårhanterad kod. Publika globala tillstånd är som sagt en felkälla man ofta vill undvika.

Självklart är det viktigaste att koden ska vara ren och snygg. Det är därför jag uppfattar att funktionsprogrammering med statiska globala variabler är bättre. Notera att dessa globala variabler är bara globala inom source-filen då dom är statiska.

OOP verkar inte alls omtyckt bland professionella programmerare.
https://www.youtube.com/watch?v=goy4lZfDtCE&ab_channel=Firesh...

Permalänk
Hedersmedlem
Skrivet av heretic16:

Jag har ett exempel.

Tänk typ om du har en klass och i denna klass så ska det vara flera klasser som fält. I dessa fällt, som också är klasser, så har den också klasser som fält.

Detta finner jag onödigt. Hela programmet som man skriver blir bara 1 stort objekt, som innehåller massvist med objekt, som innehåller massvist med objekt och så vidare.

Det blir onödigt och jobbigt om det man försöker modellera inte naturligt kan representeras med klasser, men just grafiska gränssnitt passar väl ofta ganska bra? Ett fönster har typiskt flera kontroller som kanske har kontroller under sig och så vidare. Har du något exempel på att Qt kräver "onödiga" objekt?

Citat:

Det är därför jag uppfattar att funktionsprogrammering med statiska globala variabler är bättre. Notera att dessa globala variabler är bara globala inom source-filen då dom är statiska.

Globala statiska variabler har sina användningsområden, men är det verkligen något att eftersträva? Kan man inte ofta klara sig med privata icke-statiska variabler men i övrigt ungefär samma funktioner? Och kanske en och annan klass för att gruppera?

Permalänk
Skrivet av Elgot:

Det blir onödigt och jobbigt om det man försöker modellera inte naturligt kan representeras med klasser, men just grafiska gränssnitt passar väl ofta ganska bra? Ett fönster har typiskt flera kontroller som kanske har kontroller under sig och så vidare. Har du något exempel på att Qt kräver "onödiga" objekt?

Globala statiska variabler har sina användningsområden, men är det verkligen något att eftersträva? Kan man inte ofta klara sig med privata icke-statiska variabler men i övrigt ungefär samma funktioner? Och kanske en och annan klass för att gruppera?

Självklart är klasser bra om man ska återanvända koden t.ex. trådar.
Men vi säger att koden ska bara köras 1 gång.

QT använder väldigt mycket statiska funktioner man kan anropa t.ex. dialoger kan man anropa statiskt utan att ens skapa en klass. Det tycker jag är smart och rent.

Alltså dom är bara globala inom källfilen, inte utanför källfilen. Jag tycker sådant är rätt bra. Blir väldigt enkelt då.

Permalänk
Hedersmedlem
Skrivet av heretic16:

Alltså dom är bara globala inom källfilen, inte utanför källfilen. Jag tycker sådant är rätt bra. Blir väldigt enkelt då.

För små projekt och så länge man har alla detaljer i färskt minne kanske, men det gäller ju att komma ihåg alla sidoeffekter som funktionerna har. Ett ideal inom funktionell programmering är ju annars att funktioner helst endast skall använda information från sina inparametrar och inte påverka något annat än returvärdet.

Permalänk
Skrivet av Elgot:

För små projekt och så länge man har alla detaljer i färskt minne kanske, men det gäller ju att komma ihåg alla sidoeffekter som funktionerna har. Ett ideal inom funktionell programmering är ju annars att funktioner helst endast skall använda information från sina inparametrar och inte påverka något annat än returvärdet.

Så du rekommenderar att man alltid ha någon form utav this, strukt, objekt som argument om man använder funktionell programmering?

Permalänk
Hedersmedlem
Skrivet av heretic16:

Så du rekommenderar att man alltid ha någon form utav this, strukt, objekt som argument om man använder funktionell programmering?

Helst vill man väl ha så få och så enkla argument som möjligt, men ibland är det ju naturligt att gruppera dem med hjälp av klasser (som en gui-widget eller en Koordinat snarare än separata x/y/z-värden. this är väl nästan alltid mer än vad man behöver (och gör kanske att funktionen som anropas måste veta mer om den som anropar än nödvändigt).

Permalänk
Hedersmedlem
Skrivet av heretic16:

Vi säger så här. Om du sitter i en situation där du känner att vanlig funktionsprogrammering kommer lösa problemet, skulle du då välja att strukturera upp ditt projekt i klasser då?

Jag ser att funktioner är enklare att strukturera för att med klasser så måste man alltid ha andra objekt i konstruktören.

Ett objekt som har objekt som konstruktör, och det objektet har ett objekt som konstruktör osv. Detta finner jag rätt svårt då i QT så finns det inget som heter Dependency Injection.

I t.ex Spring Boot så använder man bara @AutoWire på ett fält och vipps så finns ett färdigt objekt där. Superbra och perfekt. På så sett kan man använda vanlig funktionsprogrammering utan att tänka djupt på projektets struktur hur det ska byggas.

När jag läser detta så får jag mest känslan av att du hellre vill fortsätta med funktionell programmering och skippa detta med klasser. Jag skulle vilja vända på det och säga att om du nu ska använda objektorienterad programmering så ska du använda klasser till allt som går att representera som ett objekt. Jag ser inte riktigt problemet med objekt som innehåller objekt som innehåller objekt. Ett fönster innehåller en Yta som innehåller en Listruta som innehåller en Textsträng. Det är ju så det kan se ut.

Visa signatur

Använd gilla för att markera nyttiga inlägg!

Permalänk
Skrivet av giplet:

När jag läser detta så får jag mest känslan av att du hellre vill fortsätta med funktionell programmering och skippa detta med klasser. Jag skulle vilja vända på det och säga att om du nu ska använda objektorienterad programmering så ska du använda klasser till allt som går att representera som ett objekt. Jag ser inte riktigt problemet med objekt som innehåller objekt som innehåller objekt. Ett fönster innehåller en Yta som innehåller en Listruta som innehåller en Textsträng. Det är ju så det kan se ut.

Jag tycker klasser är något bökiga om man ska bara anropa koden en gång.
Jag finner det enklare att ha statiska globala fält som sätter värden i. Sedan använder man funktioner bara.

Självklart använder jag klasser vid behov.

Permalänk
Medlem

Jag tror inte att det du beskriver faktiskt faller helt inom ramarna för vad funktionell programmering innebär heller, utan det låter mer som någon form av procedurell programmering.

Globala variabler innebär ändå att ditt program har någon form av state som dina funktioner (procedurer/subrutiner) syftar att förändra under programmets gång. De som språk som benämns som rent funktionella jobbar inte med state och tillåter endast rena funktioner, d.v.s. det finns inga sidoeffekter. Givet en viss input kommer funktionen alltid returnera samma värde.

Ditt exempel med databasen jobbar ju fortfarande med ett objekt som har ett internt state och metoder som gör olika saker beroende på dess state. Inom funktionell programmering finns generellt inga objekt utan där jobbar du istället med datastrukturer. En datastruktur är enbart en databärare och har inget eget state och inga metoder som kan anropas.

Du säger att koden bara kommer anropas en gång, men hur kan du garantera att det aldrig kommer hända att du eller någon annan vill återanvända samma funktionalitet i framtiden? Bara för att något fungerar på ett visst sätt här och nu innebär det inte att det alltid kommer vara så.

Procedurell programmering och OOP är närbesläktade paradigmer medan funktionell programmering lutar mer åt det matematiska.
Det är lite som Vänsterpartiet och Socialdemokraterna vs SD om man ska använda en mindre abstrakt (?) analogi.

Visa signatur

AMD Ryzen 7 1700X 3.8 GHz 20MB | ASUS PRIME X370-PRO | MSI GeForce GTX 1080 Gaming X 8GB | G.Skill 16GB DDR4 3200 MHz CL14 Flare X | Corsair RM650x 650W

Permalänk
Skrivet av noMad17:

Jag tror inte att det du beskriver faktiskt faller helt inom ramarna för vad funktionell programmering innebär heller, utan det låter mer som någon form av procedurell programmering.

Globala variabler innebär ändå att ditt program har någon form av state som dina funktioner (procedurer/subrutiner) syftar att förändra under programmets gång. De som språk som benämns som rent funktionella jobbar inte med state och tillåter endast rena funktioner, d.v.s. det finns inga sidoeffekter. Givet en viss input kommer funktionen alltid returnera samma värde.

Ditt exempel med databasen jobbar ju fortfarande med ett objekt som har ett internt state och metoder som gör olika saker beroende på dess state. Inom funktionell programmering finns generellt inga objekt utan där jobbar du istället med datastrukturer. En datastruktur är enbart en databärare och har inget eget state och inga metoder som kan anropas.

Du säger att koden bara kommer anropas en gång, men hur kan du garantera att det aldrig kommer hända att du eller någon annan vill återanvända samma funktionalitet i framtiden? Bara för att något fungerar på ett visst sätt här och nu innebär det inte att det alltid kommer vara så.

Procedurell programmering och OOP är närbesläktade paradigmer medan funktionell programmering lutar mer åt det matematiska.
Det är lite som Vänsterpartiet och Socialdemokraterna vs SD om man ska använda en mindre abstrakt (?) analogi.

Alltså jag menar så här att istället för att jag ska skapa massvis med klasser som har funktioner, men jag har egentligen inget behov utav klassen i sig, utan bara funktionerna. Då kan jag lika gärna skapa funktioner istället? Lite så sitter jag i en situation.

Jag kan ju lösa problemet igenom att skapa en klass som har funktioner. Men det blir mindre kod om jag använder bara funktioner + fält några fält som är statiska. Jag gillar att använda pekare.

Om QT hade dependency injection, så skulle detta vara löst på en gång. Då skulle det vara riktigt roligt.
Se denna bild
https://devopedia.org/images/article/30/4020.1536743448.gif

Den vänstra bilden brukar jag göra. Men i Spring Boot så kan jag använda tekniken som den högra bilden visar.
Denna bild beskriver exakt hur jag har det som nu. Här måste man alltså planera projektets struktur för att det ska fungera. Först den klassen, sedan den klassen och sist den klassen osv. Sådant tar tid.
https://i.stack.imgur.com/S256p.png

Permalänk
Medlem
Skrivet av heretic16:

Alltså jag menar så här att istället för att jag ska skapa massvis med klasser som har funktioner, men jag har egentligen inget behov utav klassen i sig, utan bara funktionerna. Då kan jag lika gärna skapa funktioner istället? Lite så sitter jag i en situation.

Jag kan ju lösa problemet igenom att skapa en klass som har funktioner. Men det blir mindre kod om jag använder bara funktioner + fält några fält som är statiska. Jag gillar att använda pekare.

Om QT hade dependency injection, så skulle detta vara löst på en gång. Då skulle det vara riktigt roligt.
Se denna bild
https://devopedia.org/images/article/30/4020.1536743448.gif

Den vänstra bilden brukar jag göra. Men i Spring Boot så kan jag använda tekniken som den högra bilden visar.
Denna bild beskriver exakt hur jag har det som nu. Här måste man alltså planera projektets struktur för att det ska fungera. Först den klassen, sedan den klassen och sist den klassen osv. Sådant tar tid.
https://i.stack.imgur.com/S256p.png

För min del beror det helt enkelt på vad det är för sorts applikation du bygger.
Om du bara bygger något för dig själv och som det bara är du som någonsin kommer jobba på; kör på precis hur du vill.

Om du bygger något som ska säljas och användas kommersiellt samt att andra utvecklare kan komma att ärva kodbasen; ta dig tiden och bygg det ordentligt.
Den tid du tar dig att tänka igenom projektstrukturen och hur koden ska hänga ihop kan spara dig enorma mängder tid längre fram.

Jag vet inte om jag är helt med på hur du menar att Dependency Injection skulle göra planeringen enklare utöver att du själv slipper skapa klassinstanser? Sådana klasser kommer ju även med helt andra typer av problem som du måste ta hänsyn till. T.ex. eftersom dessa klasser skapas som singletons måste de vara helt stateless eftersom samma instans då kommer användas av alla.

Visa signatur

AMD Ryzen 7 1700X 3.8 GHz 20MB | ASUS PRIME X370-PRO | MSI GeForce GTX 1080 Gaming X 8GB | G.Skill 16GB DDR4 3200 MHz CL14 Flare X | Corsair RM650x 650W

Permalänk
Skrivet av noMad17:

För min del beror det helt enkelt på vad det är för sorts applikation du bygger.
Om du bara bygger något för dig själv och som det bara är du som någonsin kommer jobba på; kör på precis hur du vill.

Om du bygger något som ska säljas och användas kommersiellt samt att andra utvecklare kan komma att ärva kodbasen; ta dig tiden och bygg det ordentligt.
Den tid du tar dig att tänka igenom projektstrukturen och hur koden ska hänga ihop kan spara dig enorma mängder tid längre fram.

Jag vet inte om jag är helt med på hur du menar att Dependency Injection skulle göra planeringen enklare utöver att du själv slipper skapa klassinstanser? Sådana klasser kommer ju även med helt andra typer av problem som du måste ta hänsyn till. T.ex. eftersom dessa klasser skapas som singletons måste de vara helt stateless eftersom samma instans då kommer användas av alla.

Mitt mål är att lära mig. Bli bättre på C++. Har kodat i C väldigt länge nu och känner att jag vill utöka min förståelse att kunna bygga projekt i QT.

Men som jag kodar just nu känner jag att jag kan göra det bättre igenom att göra det mer pedagogiskt.

Permalänk
Medlem
Skrivet av heretic16:

Mitt mål är att lära mig. Bli bättre på C++. Har kodat i C väldigt länge nu och känner att jag vill utöka min förståelse att kunna bygga projekt i QT.

Men som jag kodar just nu känner jag att jag kan göra det bättre igenom att göra det mer pedagogiskt.

C är väl i grund och botten främst procedurellt medan C++ går mer mot OOP. Att då ha som mål att bli bättre på C++ men sedan ändå skriva kod som om det vore C känns väl lite kontraproduktivt?

Visa signatur

AMD Ryzen 7 1700X 3.8 GHz 20MB | ASUS PRIME X370-PRO | MSI GeForce GTX 1080 Gaming X 8GB | G.Skill 16GB DDR4 3200 MHz CL14 Flare X | Corsair RM650x 650W

Permalänk
Medlem
Skrivet av heretic16:

Jag tycker klasser är något bökiga om man ska bara anropa koden en gång.
Jag finner det enklare att ha statiska globala fält som sätter värden i. Sedan använder man funktioner bara.

Självklart använder jag klasser vid behov.

Statiska (eller icke-statiska) globala fält och variabler är nästan alltid en väldigt dålig idé.
I synnerhet om man använder funktionell programmering, då globala tillstånd går rakt emot principerna för funktionell programmering.

Permalänk
Medlem
Skrivet av heretic16:

Mitt mål är att lära mig. Bli bättre på C++.

Vill du bli bättre på C++ så bör du försöka programmera i god C++ enligt konstens alla regler. Inte försöka använda C++ till programmeringsstilar det inte är bra på.

Permalänk
Skrivet av noMad17:

C är väl i grund och botten främst procedurellt medan C++ går mer mot OOP. Att då ha som mål att bli bättre på C++ men sedan ändå skriva kod som om det vore C känns väl lite kontraproduktivt?

Fast C++ handlar inte om att man ska göra koden svår. Visst ska man lära sig klasser och dyligt.

Skrivet av Erik_T:

Statiska (eller icke-statiska) globala fält och variabler är nästan alltid en väldigt dålig idé.
I synnerhet om man använder funktionell programmering, då globala tillstånd går rakt emot principerna för funktionell programmering.

Tycker det fungerar riktigt bra. Man slipper alltså ha ett objekt/struktur som argument.
Men jag gör det BARA om koden är ca 50-100 rader lång. Skriver aldrig mer än 300 rader kod i en fil. Aldrig.

Skrivet av Erik_T:

Vill du bli bättre på C++ så bör du försöka programmera i god C++ enligt konstens alla regler. Inte försöka använda C++ till programmeringsstilar det inte är bra på.

Ja. Vill bli bättre på C++.
Tycker du att jag borde använda Dependency Injection i C++? Detta är väll en modern teknik inom C++?

Permalänk
Medlem
Skrivet av heretic16:

Tycker det fungerar riktigt bra. Man slipper alltså ha ett objekt/struktur som argument.

Ge gärna något exempel på detta. Exemplet du gav i ditt första inlägg har ju inte detta "problem", det är samma argument oavsett om det är en klass eller funktioner. Det är till och med ungefär lika mycket kod, i alla fall om du tar bort alla onödiga this-> i klass-exemplet.

Permalänk
Medlem
Skrivet av heretic16:

Fast C++ handlar inte om att man ska göra koden svår. Visst ska man lära sig klasser och dyligt.

OOP innebär inte att koden blir "svår". I så fall skulle ingen använda sig av det.
Anledningen till att du tycker att koden blir svår är för att du inte förstår OOP.
Allt är svårt innan man lärt sig det.

Visa signatur

AMD Ryzen 7 1700X 3.8 GHz 20MB | ASUS PRIME X370-PRO | MSI GeForce GTX 1080 Gaming X 8GB | G.Skill 16GB DDR4 3200 MHz CL14 Flare X | Corsair RM650x 650W

Permalänk
Medlem
Skrivet av heretic16:

Tycker det fungerar riktigt bra. Man slipper alltså ha ett objekt/struktur som argument.
Men jag gör det BARA om koden är ca 50-100 rader lång. Skriver aldrig mer än 300 rader kod i en fil. Aldrig.

Har inte så mycket med längden av koden att göra, utan att man bör undvika globala tillstånd.

Globala tillstånd tenderar att ställa till det rejält om man använder trådning eller rekursiva funktioner.
Du har nämnt att använda funktionell programmering. Vid klassisk funktionell programmering så är rekursiva funktioner väldigt vanliga.

Att ha ett object/struktur som argument är sällan något problem i sig, och sålunda inget man bör anstränga sig särskilt mycket för att undvika.

Permalänk
Medlem
Skrivet av Erik_T:

Du har nämnt att använda funktionell programmering. Vid klassisk funktionell programmering så är rekursiva funktioner väldigt vanliga.

Detta är nog något av ett missförstånd, heretic16 skrev från början "funktionsprogrammering" och menade nog procedurell snarare än funktionell programmering med tanke på hans C-bakgrund och tidigare trådar. Men globala tillstånd är förstås något man vanligtvis vill undvika oavsett.

Permalänk
Medlem
Skrivet av perost:

Detta är nog något av ett missförstånd, heretic16 skrev från början "funktionsprogrammering" och menade nog procedurell snarare än funktionell programmering med tanke på hans C-bakgrund och tidigare trådar. Men globala tillstånd är förstås något man vanligtvis vill undvika oavsett.

Det har du antagligen rätt i. Jag läste det som "funktionell programmering" då "funktionsprogrammering" inte är något vedertaget begrepp.

Permalänk
Skrivet av noMad17:

OOP innebär inte att koden blir "svår". I så fall skulle ingen använda sig av det.
Anledningen till att du tycker att koden blir svår är för att du inte förstår OOP.
Allt är svårt innan man lärt sig det.

Jag har programmerat i OOP i flera år.

Permalänk
Medlem
Skrivet av heretic16:

Jag har programmerat i OOP i flera år.

Behöver du överhuvudtaget ställa den här typen av frågor om klasser, så är det ju uppenbart att du inte förstår Objekt-Orienterad Programmering särskilt bra.

Permalänk
Skrivet av Erik_T:

Behöver du överhuvudtaget ställa den här typen av frågor om klasser, så är det ju uppenbart att du inte förstår Objekt-Orienterad Programmering särskilt bra.

Jo det gör jag.
Det är alltid enkelt för dig att bedöma mig utan att sett vad jag har gjort. Typiskt internet.