Objektorientering boktips

Objektorientering boktips

Hej,

Läser på universitetet och förstår grunderna beträffande objektorientering, skulle vilja fördjupa mina kunskaper i området och önskar gärna hitta en bok om det.

Jag hittade boken Objektorienterad analys och design på biblioteket, men den kom ut 2001. Jag vet inte om det är så att den fortfarande är aktuell då principen borde vara likadan idag. Men det skulle kännas ganska onödigt om boken inte vore så "aktuell" och man inser det efter att ha läst den.

Mvh

Skrivet av askeetit:

Hej,

Läser på universitetet och förstår grunderna beträffande objektorientering, skulle vilja fördjupa mina kunskaper i området och önskar gärna hitta en bok om det.

Jag hittade boken Objektorienterad analys och design på biblioteket, men den kom ut 2001. Jag vet inte om det är så att den fortfarande är aktuell då principen borde vara likadan idag. Men det skulle kännas ganska onödigt om boken inte vore så "aktuell" och man inser det efter att ha läst den.

Mvh

Föråldrad bok. Dessutom är OOP rätt föråldrad teknik också. De flesta problem idag löses igenom funktionsprogrammering, d.v.s enkel programmering. Den minsta koden är ju den bästa koden som det sägs.

Något som jag dock skulle rekommendera är att kunna arv och interface och dess tillämpningar.
Jag brukar säga att:

Arv = Om du vill utöka en klass istället för att skriva om en hel klass
Interface = Om du vill filtrera bort funktioner och fält från en klass

Mer än så brukar jag inte använda och detta duger om du vill skapa feta applikationer. Något som jag också rekommenderar är Spring Framework som innehåller DI - Dependency Injection.

DI används när du vill att ditt objekt ska vara åtkommpligt överallt vid uppstart utav ditt program. Detta underlättar, annars får du själv hålla på deklarera objeket med objekt i konstrukören.

Exempel:

class A { private C c; public A(C c){ this.c = c; } } class B { private C c; public B(C c){ this.c = c; } } // Nu har både b och a, c i sig. Så ändras något i c från klass A eller B så kan dom "tala med varandra". Dom delar alltså samma minne. class D { private C c; public D(C c){ c = new C(); B b = new B(c); A a = new A(c); } }

Då är det bättre att göra så här:

class A { @Autowired private C c; public A(){ } } class B { @Autowired private C c; public B(){ } } // Nu är objektet c åtkommlig i klasserna A, B, D då dom delar samma minne. Detta används i Spring Framework. class D { @Autowired private C c; public D(){ } }

Senast redigerat 2020-01-26 18:11

@askeetit:
Det beror lite på vad du är ute efter? Hur man använder OO eller något mer teoretiskt? Om du känner att du förstår grunderna bra men vill få bättre förståelse för hur man går vidare och bygger/organiserar lite större program så skulle jag rekommendera Domain-Driven Design: Tackling Complexity in the Heart of Software av Eric Evans. Det är inte en bok om OO utan man kan använda koncept från DDD både inom OO och FP(funktionell programmering).

Skrivet av heretic16:

Föråldrad bok. Dessutom är OOP rätt föråldrad teknik också. De flesta problem idag löses igenom funktionsprogrammering, d.v.s enkel programmering. Den minsta koden är ju den bästa koden som det sägs.

Något som jag dock skulle rekommendera är att kunna arv och interface och dess tillämpningar.
Jag brukar säga att:

Arv = Om du vill utöka en klass istället för att skriva om en hel klass
Interface = Om du vill filtrera bort funktioner och fält från en klass

Mer än så brukar jag inte använda och detta duger om du vill skapa feta applikationer. Något som jag också rekommenderar är Spring Framework som innehåller DI - Dependency Injection.

DI används när du vill att ditt objekt ska vara åtkommpligt överallt vid uppstart utav ditt program. Detta underlättar, annars får du själv hålla på deklarera objeket med objekt i konstrukören.

Exempel:

class A { private C c; public A(C c){ this.c = c; } } class B { private C c; public B(C c){ this.c = c; } } // Nu har både b och a, c i sig. Så ändras något i c från klass A eller B så kan dom "tala med varandra". Dom delar alltså samma minne. class D { private C c; public D(C c){ c = new C(); B b = new B(c); A a = new A(c); } }

Då är det bättre att göra så här:

class A { @Autowired private C c; public A(){ } } class B { @Autowired private C c; public B(){ } } // Nu är objektet c åtkommlig i klasserna A, B, D då dom delar samma minne. Detta används i Spring Framework. class D { @Autowired private C c; public D(){ } }

Tack, jag håller på med abstrakta klasser och interfaces nu i Java.
Det känns inte särskilt svårt direkt, inte just nu iallafall, men det jag personligen har problem med att förstå är vad man ska göra klasser av.
Jag gjorde ett kortspel till en examination och då hade jag
Spelare-Hand-Kort
Man kunde ju istället haft just här
Spelare-Kort
Så jag är inte helt hundra på vad som avgör vad som ska vara en klass eller inte.
Ett substantiv kan/ska vara en klass har jag hört men då blir det väl en hel del klasser?

Så du menar att man inte programmerar objektorienterat längre? Men är inte det hela grejen med Java, C++ etc.

Skrivet av jclr:

@askeetit:
Det beror lite på vad du är ute efter? Hur man använder OO eller något mer teoretiskt? Om du känner att du förstår grunderna bra men vill få bättre förståelse för hur man går vidare och bygger/organiserar lite större program så skulle jag rekommendera Domain-Driven Design: Tackling Complexity in the Heart of Software av Eric Evans. Det är inte en bok om OO utan man kan använda koncept från DDD både inom OO och FP(funktionell programmering).

Tack jag ska kika på den, jag beskrev mitt problem i svaret till heretic.

Skrivet av askeetit:

Tack, jag håller på med abstrakta klasser och interfaces nu i Java.
Det känns inte särskilt svårt direkt, inte just nu iallafall, men det jag personligen har problem med att förstå är vad man ska göra klasser av.
Jag gjorde ett kortspel till en examination och då hade jag
Spelare-Hand-Kort
Man kunde ju istället haft just här
Spelare-Kort
Så jag är inte helt hundra på vad som avgör vad som ska vara en klass eller inte.
Ett substantiv kan/ska vara en klass har jag hört men då blir det väl en hel del klasser?

Så du menar att man inte programmerar objektorienterat längre? Men är inte det hela grejen med Java, C++ etc.

Tack jag ska kika på den, jag beskrev mitt problem i svaret till heretic.

Klart det fortfarande finns folk som programmerar objektorienterat, och för en del typer av problem så är det faktiskt den bästa lösningen.
Vad som har hän är snarare att all hype runt objektorientering har dött ut, och folk har börjat begripa att objektorientering kanske inte är lösningen på alla problem trots allt.

Vad man skall ha som klasser är en bra fråga, som inte har något definitivt svar. Själv skulle jag rekommendera att hålla nere antalet klasser, och inte skapa nya klasser utan ett tydligt behov av dem.

@heretic16:

Tanken med DI är inte att Objekt ska vara tillgänglig vid uppstart.

Interface är inte till för att gömma fält.

Till ursprungs frågan, det är tråkigt med att svara med en video, men är precis vad det handlar om. Tar upp det första med din fråga om substantiv.

https://www.youtube.com/watch?v=o9pEzgHorH0