Privata metoder

Hej,
Finns det nån speciell anledning till att man deklarerar metoder som private?

Vad jag förstår är det för att dölja information som användaren inte behöver veta och på så sätt förenkla programmet. Att man anropar private metoder i public metoder. Har jag förstått det rätt då?

Ett case för att försöka reda ut begreppen åt dig:

Tänk dig en kodsnutt som du behöver använda fler gånger i en klass, fast med olika parametervärden, där har du ju en bra kandidat för en metod.

Nu är det så att denna metod bara gör en liten del av det arbete den metod som anropade den gör, till exempel beräknar något, eller kanske sparar något i en databas.

I det senare fallet finns det till att börja med en risk att ha den publik, eftersom man då kan anropa den varifrån som helst och skicka in godtyckligt skräp. Är den däremot privat går den ju bara att anropa inifrån klassen själv. Med detta förfarande kan man lägga in valideringar etc i den anropande metoden och sedan när man vet att datat är ok kan man skicka in det i den privata metoden. I detta fall blir det en bra uppdelning av ansvar med, eftersom den privata metoden endast sparar data, ansvaret för att datat är korrekt läggs på den anropande metoden. Bra återanvändbarhet med andra ord

I detta fallet är den privata metoden endast en "stödmetod" i klassen som inte är meningsfull att anropa utifrån, därför är det säkrast för alla inblandade parter att göra den privat.

Var det ett bra case och förstår du något av det?

Tack för svar! Börjar förstå mycket bättre iaf!

Men hur menar du med återanvändbarhet?

Med det menar jag att metoden kan användas från fler än ett ställe.

Säg att du har tre olika publika metoder som alla vid något ställe anropar den privata metoden.

I det läget vill du ju inte lägga regler för indatat i den privata metoden, eftersom du du snabbt kommer söla ner den med logik för 3 fall, dessutom kommer du bli tvungen att ändra i den om ytterligare publika metoder skulle komma att behöva använda den. Den skulle i teorin kunna växa till en gigantisk ohanterlig amöba beroende på hur många ställen den anropas på i sådana fall.

Om den istället gör EN sak, men gör denna destå bättre (typ spara nån data i en databas) och förlitar sig på att den data den blir försedd med är korrekt betyder det att varje metod som använder den själv ansvarar för att datat är korrekt, på det sättet blir ju den privata metoden återanvändbar, den går utan problem att använda på fler ställen utan att ändra på koden i den.

Hajjaru?

Privata metoder har en väldigt viktig funktion. Om du tänker på hur en kvinnas vagina fungerar så är det ganska fascinerande hur många privata metoder som existerar i implementationen. Massvis med saker händer i bakgrunden när du gör en så enkel sak som att föra in din balle.

Ur användarens synvinkel så vill man inte behöva få vaginan het, blöt, skicka dopamin till hjärnan mm utan det är någonting som ska ske automatiskt vid penetrering.

Ironiskt nog så hade klittan kunnat vara en privat metod som automatiskt hade kallats när man för in snoppen så hade alla våra problem vart lösta. Istället är klittan är publik metod som måste kallas manuellt varje gång och många utvecklare missar att den helt enkelt existerar på grund av dålig dokumentation.

Du kan se ett hus som en metafor av en klass.

Av samma anledning som du inte vill att vem som helst skall ha tillträde till husets funktioner som spisen, toaletten, sängen eller badkaret så vill du inte det heller med funktioner/metoder i en klass.

Har du en klass som skall laga till potatismos och köttbullar finns det ingen anledning att låta vem som helst få tillgång till garaget, veta ditt kontonummer eller kunna snoka runt på vinden.

Allt handlar om "need to know basis".

Denna regel har noll och inget värde i sig för hemmaprogrammeraren men det handlar väldigt mycket om god design och god programmeringssed. Har man tänkt efter lite före så vet man ju vad som skall vara private och inte. Och ute i näringslivet vet du inte hur jävla korkad personen som skall förvalta koden är när du är klar med ditt arbete för att uttrycka sig lite cyniskt.

Så det är bättre att ha både hängslen och livrem än att free wheela och tro att nästa person som tar över är en sansad och eftertänksam dam eller herre.

En annan grej är att du kanske vill ha frihet att ändra din implementering av något.

Säg att du löser ett visst problem med den publika metoden A, som i sin tur tar hjälp av den publika metoden B, ungefär som i Protons exempel ovan.
Efter ett tag kommer du en grej som snabbar upp B avsevärt, vilket tyvärr kräver viss ändring i kommunikationen mellan A och B. Om då någon annan utvecklare har hittat och använder metod B, som är publik, så kan den utvecklaren få ett mindre helvete när du plötsligt ändrar B.

Hade B varit privat så hade ingen annan än du varit beroende av den metoden. Av samma anledning kan det vara vettigt att fundera lite extra innan du ändrar en publik metod eftersom andra kan behöva anpassa sin kod.

Detta är i princip facit, dvs det som idag ofta kallas dependency inversion.

Allt annat som nämnts är bra och ibland (sällan) kritiskt viktigt, men i grund och botten handlar mönstret om slippa skapa dependency till en implementation.

Publika metoder utgör ett kontrakt som andra moduler kan använda. En gränsyta.

Det skapas alltid beroenden explicit eller implicit, men det viktiga är vad man är beroende av och hur hårt det beroendet är.

Dependency inversion säger

Ett sätt att göra detta på är att låta beroenden peka in till en klass (till exempel genom injektion i konstruktorn eller en metod) och inte ut från en klass exempelvis genom att man gör new MittElakaBeroendeTillEnKonkretImplemenation()

Här är en suverän video som beskriver SOLID-principerna och objektorienterade grunder.
https://vimeo.com/17151526

Bra utvecklat, även om det är oklart vad du egentligen svarar på.

Det är ett mindset som hjälper till på i princip varenda plan när det gäller systemutveckling och arkitektur. Speciellt i lägen där det inte verkar så viktigt (det är då man några år senare blir sittande - enormt efterklok - med något som råkade fungera, råkade bli värdefullt, och råkade utvecklas till den groteska stommen i ett kritiskt system).

Vet inte riktigt själv vad jag svarade på heller, det började drifta lite från trådstarten

Men jag håller med och jag tror ändå att det är en god mental modell att ta med sig och även om det är så olyckligt som du beskriver så kan man strategiskt arbeta sig framåt genom att skapa abstraktioner även i ett legacysystem och göra delar beroende av abstraktionen (finns även andra strategier, se Refactoring- Improving the Design of Existing Code av Kent Beck).

Men för att återkoppla till trådstarten så är det väl helt enkelt så att privata metoder inte utgör en del av abstraktionen som någon konsument kan bli beroende av.

För att driva in poängen tar jag med ett citat från Grady Booch om abstraktion