OOP och publika egenskaper eller "getters"/"setters"

Permalänk
Medlem

OOP och publika egenskaper eller "getters"/"setters"

Hej,

Jag har programmerat i ett antal år nu, och jag har lite funderingar kring objektorienterad programmering och publika egenskaper. Jag sitter just nu och skriver på ett program som kommer att ha en klass som innehåller ganska många variabler, dessa variabler kommer att behövas på flera ställen och flera gånger medan programmet körs. Kan även nämna att variablerna används mest av klassen där de är placerade men även utav andra klasser.

Jag är fullt medveten om att använda publika egenskaper anses inte vara objektorienterat, och i de flesta fall är det inte ett stort problem eftersom att oftast om man har en bra design på sitt program är det ytterst få getters/setters som behövs. Jag tror även att jag har en förståelse för varför man hellre har en get/set metod än att ha en publik egenskap, det gör att det blir lättare att göra förändringar i en klass utan att påverka andra klasser.

Men jag sitter nu och skriver ett program för eget bruk och min kod kommer förmodligen aldrig att vara intressant för någon annan. Därför valde jag att använda publika egenskaper i en klass istället för att lägga till 15 get metoder. Så, det påstås vara fel, eller inte objektorienterat osv, men varför lägga ner tid på att skriva en massa get eller set metoder som bara returnerar värdet i en privat variabel istället för att göra variabeln public? Så min fråga är, vad anser ni om detta? Finns det någon som kan hålla med om att get/set metoder kan vara ganska löjliga ibland eller tycker ni att man borde hålla sig till att skriva dom även om chansen att de kommer att behövas är minimal?

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av Goose7
Så, det påstås vara fel, eller inte objektorienterat osv, men varför lägga ner tid på att skriva en massa get eller set metoder som bara returnerar värdet i en privat variabel istället för att göra variabeln public? Så min fråga är, vad anser ni om detta? Finns det någon som kan hålla med om att get/set metoder kan vara ganska löjliga ibland eller tycker ni att man borde hålla sig till att skriva dom även om chansen att de kommer att behövas är minimal?

Har du publika variabler så har du ingen kontroll på dess värde. Har du en setter kan du validera indatan först. Sen beror det lite på språk också tror jag. Getters/setters är normen när du skriver t.ex. Java, men inte alls lika vanligt i vissa andra språk.

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av You
Har du publika variabler så har du ingen kontroll på dess värde. Har du en setter kan du validera indatan först. Sen beror det lite på språk också tror jag. Getters/setters är normen när du skriver t.ex. Java, men inte alls lika vanligt i vissa andra språk.

Jo, jag säger inte att det inte finns fördelar med att använda setters och getters, men i väldigt många tillfällen tycker jag att det känns helt onödigt.

Kan tillägga att jag just nu för det mesta skriver i C# men även en del i Java. I C# använder man väl kanske properties(eller heter det så?), alltså "public typ Värde { get { blabla.. } set { blabla.. } }", men det är ju i princip samma sak.

Permalänk
Medlem

Re: OOP och publika egenskaper eller "getters"/"setters"

Citat:

Ursprungligen inskrivet av Goose7
tycker ni att man borde hålla sig till att skriva dom även om chansen att de kommer att behövas är minimal?

Ja. Priset du betalar för att införa dem är litet jämfört med priset du riskerar att betala om du istället har en naken publik klassmedlem.

Allra helst om du, som du antyder, skulle ha dem för att manipulera instanser av klassen från ett flertal ställen i koden. Du kanske nån gång får in ett tramsvärde som kraschar ditt program. Var kom det värdet ifrån? Det är betydligt lättare att hitta om du har en setter för egenskapen - släng in en loggning, eller ännu hellre, kasta ett exception om indatan du får in är dålig.

Sitter man med en naken publik variabel om liknande behov uppkommer, blir man lätt ganska ledsen. Jag lärde mig själv det den hårda vägen för några år sedan, när jag var i samma situation som du och tänkte "ääh men orka!!". Och så någonstans, bland mina 10 000 rader spaghettikod, sattes ett dåligt värde som pajade en grej. Förvirrad badboll felsökte febrilt, men det slutade med att jag fick skriva om så att jag hade min setter till slut, som vaktade mot dålig indata. Därefter var felet lätt att hitta.

Att de skulle vara jobbiga att skriva eller motsvarande är ett dåligt argument, då vettiga IDE:er kan autogenerera dem. Och en vettig IDE bör man ha om man programmerar någonting av större storlek i Java.

Dessutom kan man ju med getter/setter-uppdelningen senare ta bort en setter ifall man hittar ett sätt att strukturera om sin kod så att egenskapen inte behöver manipuleras utifrån alls. Det är faktiskt bara positivt om man kan fixa det.

Citat:

Men jag sitter nu och skriver ett program för eget bruk och min kod kommer förmodligen aldrig att vara intressant för någon annan.

Du gör ju naturligtvis som du vill med din egen kod, du behöver inte göra dig till för någon annan. Jag kan gå runt i min lägenhet en hel dag i kalsonger och en smutsig t-shirt, det är ingen annan som behöver se eller lida av det. När jag går till jobbet och knackar kod ser jag däremot till att ha på mig rena kläder och skriva setters.

Permalänk
Medlem

Re: Re: OOP och publika egenskaper eller "getters"/"setters&a

Citat:

Ursprungligen inskrivet av badboll
Ja. Priset du betalar för att införa dem är litet jämfört med priset du riskerar att betala om du istället har en naken publik klassmedlem.

Allra helst om du, som du antyder, skulle ha dem för att manipulera instanser av klassen från ett flertal ställen i koden. Du kanske nån gång får in ett tramsvärde som kraschar ditt program. Var kom det värdet ifrån? Det är betydligt lättare att hitta om du har en setter för egenskapen - släng in en loggning, eller ännu hellre, kasta ett exception om indatan du får in är dålig.

Sitter man med en naken publik variabel om liknande behov uppkommer, blir man lätt ganska ledsen. Jag lärde mig själv det den hårda vägen för några år sedan, när jag var i samma situation som du och tänkte "ääh men orka!!". Och så någonstans, bland mina 10 000 rader spaghettikod, sattes ett dåligt värde som pajade en grej. Förvirrad badboll felsökte febrilt, men det slutade med att jag fick skriva om så att jag hade min setter till slut, som vaktade mot dålig indata. Därefter var felet lätt att hitta.

Att de skulle vara jobbiga att skriva eller motsvarande är ett dåligt argument, då vettiga IDE:er kan autogenerera dem. Och en vettig IDE bör man ha om man programmerar någonting av större storlek i Java.

Dessutom kan man ju med getter/setter-uppdelningen senare ta bort en setter ifall man hittar ett sätt att strukturera om sin kod så att egenskapen inte behöver manipuleras utifrån alls. Det är faktiskt bara positivt om man kan fixa det.

Du gör ju naturligtvis som du vill med din egen kod, du behöver inte göra dig till för någon annan. Jag kan gå runt i min lägenhet en hel dag i kalsonger och en smutsig t-shirt, det är ingen annan som behöver se eller lida av det. När jag går till jobbet och knackar kod ser jag däremot till att ha på mig rena kläder och skriva setters.

Tack för svaret, det ni båda säger är väl sant, har även diskuterat saken lite med en vän nyligen som hjälpte till att övertyga mig. Som du sa, med min egen kod kan jag ju göra som jag vill men jag har nog blivit övertalad ändå och kommer fortsätta skriva mina setters/getters, eller auto generera dom. Anledningen till att jag började fundera på det nyligen var för att jag verkligen inte kunde hitta något sätt att komma runt att använda massor av dom för en specifik klass i mitt program, vilket ju brukar tyda på en dålig design, men ändå var jag övertygad om att det inte skulle gå att lösa på något snyggt sätt. Men för en halvtimme sedan så kom jag på något som jag helt hade missat, vilket gjorde att med ganska lite jobb så kan jag ha privata variabler utan att behöva alla setters/getters. Efter den aha-upplevelsen är jag plötsligt på bättre humör och känner mindre behov att ta massa dåliga genvägar ;).

Permalänk

När det kommer till C# har man ju tillgång till Auto-Implemented Properties vilket gör det enkelt att implementera getters/setters som sedan ännu enklare kan ändras i efterhand om du skulle vilja begränsa settern med validering, etc.

public class Klass { public int Nummer { get; set; } public string Namn { get; set; } }