Tjena hur ser syntaxen ut om jag ur en funktion vill retunera ex 3 variabler. Hur ser syntaxen för att skicka samt för att ta emot ut?

MVH Henrik L

<code>
public void Foo(out string var1, out int var2, out float var3)
{
var1 = "Bar";
var2 = 17;
var3 = 4711.0;
}

...

void Main()
{
string v1;
int v2;
float v3;

Foo(out v1, out v2, out v3);
}
</code>

Hoppas detta hjälper!

/Mattias

Det beror ju lite på hur du vill ha det.
Du kan ex skicka in en array som innehåller 3 poster, behandla den o returnera den tillbaka. Eller så kan du göra en metod som tar 3 input parametrar.

Allt handlar om syftet med metoden.

//Johan N

Ok fast det var tvärt emot jag undrade. Jag vill ju retunera 3 värden ur funktionen tuy:
<code>
return val1, val2, val3;
</code>

Hur görs detta?

Du kan inte returnera flera värden från en funktion m.h.a. return, finns det något språk som kan det??? Hur skulle syntaxen på anropande sida se ut? Jag ser det som att det som jag visade i mitt föra inlägg är det enklaste (dvs att använda parametrar märka som out), fast jag förklarade ju inte så mycket...

C# har ett keyword vars syfte är precis det du vill göra, det heter out. Att använda out som keyword framför en parameter betyder att den inte tar emot ett värde på invägen, utan att det bara returnerar ett värde. Kodexemplet var alltså inte ett exempel på hur man anropar en funktion med tre parametrar, utan ett exempel på hur man returnerar tre olika saker från en funktion.

Om du fortfarande tycker det är oklart så får du säga till!

Man kan ju iofs tänka sig att returnera en array av object (object[]), men då får du ju ingen kontroll av datatyper och det är (tycker jag) mycket mer komplicerat.

/Mattias

Snyggast vore ju att returnera en colletion med de 3 värden du vill ha. Eller en struct som du fyller i din metod. En entitetsklass fungerar lika bra.

Här följer ett Entitetsexempel.

<code>
public class Foo
{
protected string value1 = null;
protected string value2 = null;
protected string value3 = null;

public string Value1
{
get{return(value1);}
set{value1=value;}
}
public string Value2
...
}

public class Foo1
{
public Foo GetValues()
{
Foo myFoo = new Foo();
myFoo.Value1 = "John Doe";
myFoo.Value2 = "John Doe2";
myFoo.Value3 = "John Doe3";

return(myFoo);
}
}

public class Foo2
{
Foo myFoo = new Foo1().GetValues();
Console.WriteLine(myFoo.Value1);
...
}
</code>


Mattias exempel ovan med Out är oxå en bra lösning. Fast lite begränsad då du måste bryta interfacet om du i framtiden vill kunna returnera ex 4 värden.
Det hela handlar fortfarande om hur du vill hantera dina saker. Syftet, användbarheten, versionering m.m. Skall den alltid returnera 3 värden, så tycker jag du skall använda dig av Mattias exempel, då det kräver mindre kodande m.m.

//Johan N

Johan, det var ju ett bra alternativ att använda entitetsklass. Själv skulle jag bara göra det om de returnerade värdena verkligen hade ett samband med varandra, dvs de kan ses som attribut på samma klass.

Sedan tycker jag nog att det är samma versionsproblem med entitetsklass som parametrar, nästan värre faktiskt :-) Om man skapar en sådan klass kanske man återanvänder den på flera ställen, och när man då ändrar den så märks det ju inte i kompileringen (att man inte använder ett nytt attribut). Om man däremot har parametrar så märker man ändringen genom kompileringsfel. Men alla tycker vu ju lite olika...

/Mattias

jag röstar för out-parametrarna! :-)

det är lätt att se vad som returneras och koden blir inte bloatad med massa massa extraklasser.

//Roger

Hej.

En liten fråga till dig vad gäller "out".
Det borde väl gå lika bra att använda sig av "ref". Vad är skillnaden? Och varför använder man den ena i stället för den andra?

Tack på förhand.

// Thomas

När du använder ref så måste du tilldela ett värde till varibeln som du skickar in:

<code>
int x = 0;

minFunc( ref x )
</code>

Använder du dig av out så behöver du inte först tilldela ett värde:

<code>
int x;

minFunc( out x )
</code>

OBS! Andra .Net språk så är det ingen skillnad på out och ref. I C# så ses dom som out och ref men i andra språk så ses dom som enbart ref.

/Fredrik N

jag frågade en kompis om hur det funkade i vb.net , och han sa att det går att skriva:

Function Plop(<out> Blah as String)

så det funkar ju tydligen där oxo..

//Roger

Jag är ledsen att säga att din kompis har tyvärr fel.

Out finns tyvärr inte i Vb.Net.

/Fredrik N

hehe , han viste tydligen inte vad out gjorde i c#

det finns ett <out()> attrib men det är ju för native interop , och har inget med "out" i c# att göra..

jaja , så var det med det...

//Roger

Hej Mattias.

Förstår vad du menar. Var lite otydlig. Om de 3 värderna inte kan bindas till en class så skulle jag valt out utan tvekan. Jag skulle kanske tryckt mer på detta i min förklaring. Det var dock rätt sent. :-)

Men om de nu hör ihop så man kan binda dem till en class skulle entitetsclass vara
ett bra allternativ.
Det snygga med entitetsklasser är ju just att man inte behöver spräcka interfacen.
Om man lägger till ett extra attribut så förstörs ingen kod. du behöver inte bry dig
om att ändra någonstans. (så länge du inte ändrar de attribut som finns.) På detta
vis får du en ny version som kommer att fungera utan problem. Så varför det skulle
vara en nackdel vet jag ej. Spårbareheten i koden finns fortfarande kvar. Då man
programmerar OO så hoppas jag ju att man även har en bra Utv-model där man även har class diagram som är ens karta i djugeln och inte enbart koden.

Det är tack vare dessa modeller och desingmönster som utv tid har minskat, och ny versioner kunnat publiceras relativt fort. Men det handlar ju oxå om dess syfte. Om jag visste att min metod som skall returnera 3 värden kommer att behöva förändras för det finns en plan med utökning som man inte har tid med nu skulle jag utan tvekan välja en design som entitets exemplet. Särskilt om jag vill återanvända värderna i andra classer då man lätt sätter entitets classen som en input parameter.

Jag stävar oftast efter att saker ev kommer att behöva återanvändas, så jag bygger saker så generellt som möjligt. (allt som ligger i BUS och DAL.)

Det är väl mina argument ang Enitiets lösningen. Men den syftar mer på återanvändbarhet, och OO där entitets attributen hör ihop.

//Johan N

jag tycker nog som sagt att det beror på vad man är ute efter,
jag använder min egen port av java entity beans i .net när jag kodar db saker.

men om jag skulle göra tex en metod som ska hitta ett valfritt ord i en sträng så skulle jag garanterat köra på out params:

<code>public void FindAnyWord (string[] words,string FindInText,out int Index,out string Word)</code>

man slipper massa returtyper som bara kommer användas till detta anropet , och man ser ganska lätt vad man kan göra med metoden...

//Roger

"men om jag skulle göra tex en metod som ska hitta ett valfritt ord i en sträng så skulle jag garanterat köra på out params"

Här förstod inte jag varför du skulle köra en out? Om du har en metod som skall hitta
ett valfritt ord, så är det väl snyggast att ha en return typ int som ev returnerar dess index eller en boolean om man bara vill veta om ordet finns eller ej. Att köra out här ger ju ingen vidare bra spårbarhet i ett sådant syfte. Känns inte rätt.
Du får gärna förklara mer hur du tänkt, då jag finner det hela intressant, och lärorikt att höra om andras lösningar och idéer.

//Johan N

Det han menar är att han vill hitta ett ord av ett antal som är inparamatrar. Förutom positionen vill han också returnera vilket ord det var. Finns ju 4 lösningar, men jag håller med Roggan om att detta är det bästa.

Jag skulle inte valt en sådan lösning, då skulle jag hellre valt att ha attribut som jag efter min sökning kunde läsa av. Men smaken är som baken.

<code>
WordFinder myWordFinder = new WordFinder();
myWordFinder.FindWords(wordList,text);

int result = myWordFinder.TotalMatches;
...


</code>

Men nu ville han hitta första instansen av ett ord ur en mängd av flera, menar du att du först skulle vilja sätta ett antal attribut också?

Typ

WordFinder myWordFinder = new WordFinder();
myWordFinder.SetFindInString(MyString);
myWordFinder.SetWordsToFind(MyWords);
myWordFinder.FindFirstWord();

int result = myWordFinder.Position;
string whichword=myWordFinder.FoundWord;
...

Verkar lite krångligare än

FindAnyWord (MyWords, MyString, result, whichword)

Sen tycker jag personligen att alla Finders och Doers är ganska fula. Har ett objekt ingen klar mening så känns det bara besvärligt. "Lösa" funktioner är inte meningslösa för att man använder oo, de har bara en annan mening.

Nej.
Tittar du på min kod ser du följande:
<code>
WordFinder myWordFinder = new WordFinder();
myWordFinder.FindWords(wordList,text);

int result = myWordFinder.TotalMatches;
...
</code>

där du har FindWords(string[] wordList,string text)
Går lika bra att lägga in text i konstruktorn om man vill.
... new WordFinder(text)

där metoden FindWords returnerar en boolean om man fått en träff eller ej, uti fall du vill anända något if statement för avgöra om du vill gå vidare.
När du sedan anropat FindWords(...) och fått en träff kan du fråga efter träffar via
attribut. Ev .Matches som ger hur många träffar du fick, MatchedWords som kanske ger en collection på ord som matchade etc...

<code>
<code>
string[] wordList = new String[3] {'John','Sist........
string text = "John Doe slog till sist ut alla system";

WordFinder myWordFinder = new WordFinder(text);
if(myWordFinder.FindWords(wordList))
int result = myWordFinder.TotalMatches;
MatchWordCollection wordsCollection = myWordFinder.MatchedWords;
...
</code>

Typ.

Men allt handlar ju om hur man vill använda sin metod, hur generell den skall vara, m.m. samt hur den vidare används i sitt system...

//Johan N

</code>

Får jag också vara med och leka?

Om så skulle jag valt detta alternativet framför allt annat:

<code>
public int FindAnyWord (string[] words,string FindInText, out string Word)
</code>

Där min FindAnyWord returner positionen där ett av orden hittades.

Varför skulle jag nu göra detta. Jo för att minimera koden och använda mig av if för att se att något ord hittades. Tex:

<code>
if(FindAnyWord(myWords, findInText, out word) > 0 )
{
Console.WriteLine(word);
}
</code>

Är jag intreserad av vilket ord som jag hittade först så har jag möjlighetet att få tag på det.

Om jag skulle valt det andra alternativet så får jag lite mer att skriva:

<code>
FindAnyWord(myWords, findInText, out pos, out word)

if( pos > 0 )
{
Console.WriteLine(word);
}
</code>

Funkar bra, men lite extra kod.

Men alla har olika smaker och tycker vissa saker är mer logiskt än andra saker.
För min del så vill jag få snygg kod och minimering av kod för att göra den mer finkornig.

/Fredrik N

Okej, om det var det det stod har jag tydligen läst fel.

Hur som helst håller jag fast vid att ett det i regel är mer krångel än nytta med att skapa två nya klasser + en metod om man bara är intresserad av första matchningen.

Hur snyggt och inutitivt är det sen att använda "MyWordFinder"?
Jag tycker det stämmer bättre med oo om en instans av en klass faktiskt representerar ett distinkt objekt.

Min åsikt är definitivt att det är kraftigt overkill med denna metod i det här fallet, och att det i många fall är fullständigt meningslöst, eftersom man vet att man aldrig kommer behöva använda mer (och det var ju just därför diskussionen började). Dessutom är det ju extremt ineffektivt att leta igenom hela strängen efter alla ord helt i onödan.

Naturligtvis har metoden sina användningsområden - ganska många - men i detta fallet är det onödigt.

Två klasser?
Snälla myWordFinder var bara ett exempel. Jag la inte speciellt mkt energi på korrekta namngivelser i mitt ex, kunde lika gärna skrivit Foo rakt genom om jag
så ville. Jag slängde bara in ett exempel på en återavnändbar klass. Som jag oxå påpekade handlar det ju lite hur man vill och vart en sådan hantering skall användas. Hur djupt eller högt i kedjan m.m.

"eftersom man vet att man aldrig kommer behöva använda mer"
Hur vet man det?

//Johan N

Nä, visst... det jag menar är att det aldrig blir speciellt snyggt om man gör på det sättet, det finns aldrig bra namn, osv. Men det spelar ju ingen roll, det var bara en notering.

Och visst, klassen är väl återanvändbar, men det är funktionen också, precis som alla funktioner i alla standardbibliotek.

>"eftersom man vet att man aldrig kommer behöva använda mer"
>Hur vet man det?
Nu var det dåligt formulerat, det jag menade var "aldrig kommer behöva använda på något annat sätt". Beror ju naturligtvis på situationen, men det var ju en av förutsättningarna som Roggan beskrev ovan.
Ett exempel som passar ganska väl in här skulle kunna vara något slags realtidsparser. Mycket onödigt att göra den slö, och den kommer aldrig användas på något annat sätt.

Den skulle även kunna passa in på "aldrig behöva användas mer".

ok.

Det är ju inte alltid lätt att veta hur sakerna skall användas när folk bara eneklt frågar efter en sak, där man inte ser helheten. Jag tog mitt ex med då syftet i grunden att man ev ville återavnända både classen och resultatet m.m. Av erfarenhet så vill man ju vid en sådan metod oftast bara veta om ordet/orden fanns, antingen genom en boolean eller ett retur index. Nu grävde man ju ner sig lite djupare än så.

Jag tycker dock det var intressant...

//Johan N

Jovisst, och det var definitivt inte meningen att angripa ditt sätt, det är ju naturligtvis i allmänhet en mycket bra metod, och återanvändbarhet är alltid önskvärt.

Menar bara att allt inte alltid måste göras helt och hållet återanvändbart, och att snyggheten (läs: läsbarheten) på kod ibland kan vara viktigare.

Sen tog ju jag mitt exempel ur luften, så svaret på hur frågeställaren egentligen bör göra kvarstår nog. Det är ju helt och hållet beroende på situationen.

Här är man borta från tråden i 10h, och vad händer? Hur många inlägg som helst! Vilket diskussion, va kul!

Jag tycker detta verkligen visar på att det finns många sätt att lösa uppgiften på, allt beroende på omständigheter samt tycke&smak. Hoppas att Henrik har fått lite input till sin fråga, svaret på den var inte så självklar som man kunde tro från början...

Detta är ett svar på MSL tidigare inlägg kl 10:27...

Du har självklart rätt i att versionerna kommer att fungera även i fortsättningen. Min tanke var att om funktionen nu skapar ett värde till så kanske det vore intressant för klienten att använda det, och det är svårt får klienten att få reda på detta eftersom det bara funkar...

OO är nog bra, men tyvärr är mina erfarenhet att viljan till återanvändbarhet är det oftast inte är så bra ställt med. När man startat att nytt projekt så återanvänder man inte gärna kod skapat i ett annat projekt, orsaker kan vara:
* koden gör inte exakt det man vill
* man har inte direkt access till källkod, bara binärer
* underhållsansvar, dvs vad händer när projekt2 hittar fel i projekt1s kod som projekt1 av någon orsak inte är intresserad av att fixa
* (och inte minst) "not invented here", dvs jag kan göra det bättre...

Jag tycker att denna diskussion har påminnt mig om vikten av att refresha de teoretiska tankarna runt OO, man fastnar ju lätt i att göra samma saker hela tiden. Jag har alltid gillat C++, men aldrig varit OO fanatiker (detta är inte ett påhopp mot någon!).

/Mattias

Jag håller helt och hållet med Mattias när det gäller de problem angående återanvändning av kod. Det största problemet jag har varit med om och som jag fortfarande ser i många organisationer är just att "Jag vill inte använda andras kod, jag gör egen för den blir bättre, då har jag kontroll över det jag har gjort.". Kontroll är något vi alla vill ha och självklart behöver för att saker och ting ska fungera. Ett sätt att få folk att återanvända kod är att införa granskning av kod, det ger möjligheten för andra utvecklare att tycka till och skapa en kod som alla förhoppnings vis gillar. Dock tar detta tid och pengar men ger ett resultat i det långsiktiga loppet.

Jag har länge suttit med Windows DNA som jag tycker hade många begränsningar och det var svårt att skapa snygg design av systemen och inte minst underhållningen kunde bli lidande. När .Net kom såg jag nya möjligheter, förstår fortfarande inte varför Microsoft levde kvar så länge i en funktionsorienterad modell?? SUN med Java var långt före. Men det var igår nu så har vi .Net och vi har möjligheten till att bygga bättre system efter verkliga objekt tack vara att .Net språken ger oss möjligheten att skapa OO system :)

Att gå från ett funktionsorienterat tänk till objekt orienterat är ett stort problem för många. Största problemet är kunskap och att man inte vet hur man ska gå till väga. En annan orsak är att man är så inne i sitt tidigare tanke sätt, många vill hålla sig kvar i det tanke sättet för det känner sig bekväma och slipper ta nya tag. Men förändring behövs och det är det som utvecklar oss människor. Vi människor är inte rädda för förändringar utan det är det okända vi är rädda för och det sätter stopp att försöka med något nytt.

Vår organisation bygger enbart OO system i .Net nu, både när det gäller ASP.Net lösningar eller andra lösningar. Måste bara säga att vi är nöjda med .Net och våra system jämför vad vi va tidigare när vi bygge system efter Windows DNA. Underhållning och design har blivit bättre och vi har reducerat får utvecklings tid och faktiskt börjat att återanvända kod :)

Jag blev besviken först när jag såg Microsoft motsvarning till Javas Petshop. Funktionsorientering och DataSets och Readers.. Ok, designen gav bra prestanda men jag håller med SUN att det är en dålig design. Nu när 2.0 kom så började det likna något och även Edward och co inom Microsoft patterns & practices har börjat skriva om design av system där man jobbar med entitetsobjekt etc. Petshop 2.0 visade en bättre prestanda än tidigare 1.0, där man gick ifrån DataSets och jobbar enbart med lös kopplade klasser. Tyvärr måste jag säga så har utvecklare som tidigare jobbat med Windows DNA velat se en Windows DNA liknande lösning av Petshop och 3.0 enligt mig blev sämre än 2.0, där man skapade 3.0 efter liknande uppbyggnad som Windows DNA applikationer. Men måste säga att vissa saker i 3.0 va mycket bra som tex det nya UI Process lagret. Men att lägga ner tid att skapa ett business lager som enbart hämtar data från datalagret och transportera det vidare till UI är enligt mig helt onödigt och slöseri på tid. Min åsikt är att enbart använda ett Business lager om det förekommer någon form av affärslogik annars kan man lägga den utvecklingstiden på andra delar av systemet.

Det jag ville säga i detta inlägg är att OO är mkt bättre än funktionsorientering i många avseenden (min åsikt), därför att man kan jobba utifrån verkliga objekt. Man pratar på med kod på ett sätt som är mer verkligt och logiskt. Tex om jag ska lägga till en användare så skriver jag Add(myUser) istället för Add(username, firstname, lastname etc). Jag har även möjligheter att skapa bas klasser som beskriver gemensamma saker för tex en användare och på så sätt ärva och skapa olika typer av användare. Detta skapar återanvändning av kod mm.
Men självklart förekommer det många funktioner med många in parametrar också, för det kommer man aldrig ifrån.

Till slut så tycker jag det är synd att MS SQL Server inte är en objekt orienterad databas. Nu kommer en variant av ner sparning av objekt i nya SQL server så det är en bit på väg :)

/Fredrik N

jag tycker att folk hypar OO , självklart är OO bra men många har en förmåga att överdriva det till helt sjuka implementeringar.

ett objekt bör motsvara en sak av något slag , en användare , en fil, en traktor etc etc

men om man behöver något som bara ska utföra en uppgift så är jag mer för att använda funktioner , och funktioner som är bra skrivna går precis lika bra att återanvända som något OO.

ta som exempel att vi vill beräkna en CRC på en dataström av något slag.
att beräkna en crc är ju något man UTFÖR , inte något man ÄR , så i det fallet så skulle jag rösta för att man använder vanliga funktioner.

typ:

long crc=CRCTool.CalcCRC(MYDataStream); //<- statisk funktion i en util klass

och INTE:

CRCCalculator crcc=new CRCCalculator(MyDataStream);
long crc=crcc.CalcCRC();


den nedre lösningen är mer OO , men helt meningslös , man tjänar inget på att göra så och det blir dessutom slöare och koden blir enligt min mening fulare.
ska man göra en klass som måste instansieras så bör man iaf kunna motivera VARFÖR den ska kunna instansieras.


det finns garanterat fall där man kanske måste göra en klass för något som ska utföras men jag försöker iaf koda enligt denna metoden om det går.
nu blev ju detta kanske lite offtrack från vad tråden handlar om men det är iaf kul att höra hur andra gör samma saker.

//Roger

Att progga med OO mönster säger ju inte nej till Statiska metoder :-)

I ditt fall kanske du har en grund klass som hanterar datastömmar, sedan underklasser som är special för just en data ström. Det tycker jag är en snyggare
lösning. Även om man kanske inte använder underklassen mer än en gång i sitt projekt så kanske man vill nyttja den i andra projekt. Om man nu bygger modulära lösningar. Men allt handlar ju om dess syfte. Jag personligen är förtjust i modulär arkitektur, där man har hjälpklasser (som är generella och återanvänds i samtliga projekt.) samt specifika klasser för just projektet eller modulen. Som även de kan användas av andra moduler. Ex Fakturamodul och artikelmodul, det gemensamma BUS classerna här blir att båda skall visa en till flera artiklar. Då återanvänds en artikel klass... Jag kan inte se varför man inte vill göra så. Jag satt mkt med enbart funktions programmering innan då ASP typ bara tillät sånt. Det gick ju jätte bra o man
tykte det var jätte bra. Tills jag började bygga mer modulärt och insåg att ASP inte håller måttet för mina arkitekturer. Det blev bökigt att underhålla, och asp sidorna kunde bli stora och klumpiga. Körde man DNA minimerades mkt av detta men det återfanns ändå problem. Då kom .Net :-)

Saken är ju den att en class ex bil innehåller ju metoder relaterat till bil. Det hindrar en inte från att ha en metod som räknar ut däckdjupet m.m. Vill man kan man ju gå djupare ner och skapa däck klass med en sådan hantering. När man bygger OO måste man inte gå ner till minsta lilla nämnare om inte ens projekt kräver det.

Funktionsprogrammering går oftast snabbare då man inte behöver någon kraftig analys och design fas. Rush to code utveckling är mer gynnat då. Att bygga ett OO system utan några förfaser ger OO många nackdelar. Så de utvecklare som oftast vill sätta sig o koda med en gång samt se resultat har svårt att greppa OO. Det blir svårare att strukturera sin arkitektur (designmönster m.m.) då.

Allt handlar ju om smak, krav och syften.

//Johan N

>ska man göra en klass som måste instansieras så bör man iaf kunna motivera VARFÖR den ska kunna instansieras.
Det var precis det som var min poäng ovan!

Detta är ju naturligtvis inte tillämpbart i alla fall. Ibland så kan man anta att man använder en funktion som kan bytas ut mot en annan, med andra krav och annat resultat. Exempelvis en hash-funktion.
Från början kanske man nöjer sig med en enkel, men sedan inser man att en speciell är mer effektiv, och att den dessutom kan behöva en parameter specificerad. Hashfunktionen skall troligtvis användas av en klass, och att då ha en specifik funktion är ju vansinne.

Där är ett tydligt exempel på en lämplig återanvändbar klass. Eftersom jag inte kodar i C#, så är jag osäker på terminologin, men i C++ kallar vi det oftast för protokoll-klasser, och i Java heter det ju Interfaces.

Dessa (många) exempel går ju inte att förneka nyttan av, men jag håller med; man skall inte överdriva. Det finns inga "hittare" i den värld jag lever. I OO pratar man om att ett program är olika objekt som skickar meddelanden till varandra. Att föra in ett nytt objekt och använda det som nåt slags halvdant mellansteg känns onaturligt.

Finns det ett uppenbart syfte är det inget att diskutera, annars bör man nog tänka efter.

Sen det där med återanvändbarheten av kod. Visst är det sant att man inte vill använda andras kod eftersom (man tror att) man kan göra det bättre själv. Men då bortser man från många viktiga detaljer. Dels är kod som andra skrivit mycket mer uttestad. Den är oftast också optimerad, har ett vanligt, känt gränssnitt och är någorlunda portabel.
Det gör att man inte behöver någon kontroll. En tillhandahållare av kod har en förpliktelse att göra den fungerande, bra och komplett. Detta funkar naturligtvis inte om man typ får koden gratis, men då är det antingen nåt inom ens företag som har skrivit det, och sådant borde man kunna lösa, eller så är det typ open source, och då kan man ändra det själv.

En programmerare överskattar alltid sig själv!

jo självklart , jag menar inte att man bara ska ha massa statiska metoder som ligger i flyter i allsköns util klasser.

om metoderna är relaterade till en entitet så ska den ju självklart ligga i entitetsklassen.

och jag är absolut inte mot OO , jag kodar och säljer winforms kontroller för .net och det är så mycket oo som det går.

men som sagt , många vill gärna skapa entitetsklasser för allt , även om det är helt meningslöst.

//Roger

Bara en liten grej.

När du bygger OO betyder inte det att alla metoder måste ta emot en klass som input.
Den kan lika gärna ta emot flera typer m.m. Som sagt syftet som avgör.
Om man har en class som skall spara adressuppgifter så är en entitetsklass genialsik att skicka in i en AdressHanterare.Spara metod eller vad man nu kan tänka sig.
Vill man ex leta upp ett namn i sin Adress Entitet samt ev veta dess placering kan man ex skriva Address.Find("John Doe") som ger ett index som retur. Eller vaför inte
Address.Find("Johan Doe",out index) eller vad man nu vill ha. Det är ju fortfarande OO programmering. Man måste alltså inte skriva:

<code>
Address address = new Address();
address.Name = "John Doe";
Address.Find(Address)
</code>

Men har man ett syfte att kunna söka utifrån alla adress attribut så är ovan allternativ ett bra sätt, iställer för att slippa he en Find metod som tar emot x antal sträng parametrar. Find(string name,string email,string street,string city...etc...)
Man kan oxå göra en Find(string[] words...) Och sedan i metoden se om något av dessa ord finns med i adress datakällan som man ev letar i. Dock tycker jag då att det är snyggare att kasta in en addressentitet och matcha den med andra adressentiteter som hämtas i metoden. (Troligen för att ev vill ha flera funktioner som återanvänder klasserna i sig m.m.) Det vet jag bara då jag börjar designa systemet.

//Johan N

"men som sagt , många vill gärna skapa entitetsklasser för allt , även om det är helt meningslöst."

Stämmer nog rätt bra. Det är då väldigt viktigt att ha en modell att följa för att identifiera om det verkligen behövs eller ej.

Vi kan nog hålla på prata OO samt funktion orienterad programmering i all evighet här :-)

Jag tycker dock det varit en intressant diskussion.
Tack alla.

//Johan N

Suveränt!
Nu verkar det som alla har samma åsikt här, och då är den uppenbarligen rätt... =)
OO är bra, klasser är bra, man bör i regel sträva efter modularitet och återanvändbarhet, men det finns fall när det inte är fördelaktigt med en strikt ood in i minsta detalj, där allt är klasser och kräver instanser av klasser. Allt beror på situationen.

Nu behöver vi nån som tycker annorlunda, så vi kan få igång en hetsig debatt ;)

vi kanske kan lura in Sven på någe sätt här , han tycker nog tvärt om av ren princip.

//Roger

Det är väl det här alla har försökt förklara på sitt sätt?

Vi alla tolkar fel, när en person skriver i detta forum så finns det bara text (Inga känslor, inga rörelser och tankar ect). Många tänker på en sak och försöker förklarar det på sitt egna speciella sätt. När man skriver så tänker man ofta på flera saker runt omkring det man skriver, i tankarna, ord som inte blir nerskrivna. Det finns stora möjligheter till feltolkning av dom som läser texten, och som själva försöker skapa en egen uppfattning om vad personen menar. Man utgår även ofta i från hur man uppfattade personen innan eller hur man förväntas uppfatta personen, eller utgår ifrån hur bra man själv tror att man är. Tex tycker man att någon skriver något dumt, så nästa gång man läser den personens inlägg, så utgår man ofta i från att han skriver något dumt. Då blir tolkningen helt fel jämfört vad personen igentligen menade. Vad en person tänker när han/hon skriver vet ingen annan. Den som skriver tänker ofta på fler saker runt omkring det han/hon skriver, som den tycker är uppenbart att andra ska förstå (Vilket inte är uppenbart), gör dom inte det så kan man uppfatta dom andra som trögfattade eller dumma.

Läser man alla dessa inlägg igen så märker man att alla verkar mena samma sak, men har sitt sätt att beskriva det på.

/Fredrik N

Jo, du har nog rätt.
Har man väl vant sig vid att arbeta på ett sätt så har man en uppfattning om vad som är det viktigaste, och hur de viktigaste undantagen ser ut. Då är det naturligt att man tänker i de banorna och ger de exemplen.
Hade vi stått i samma rum med en whiteboard hade det nog tagit 3 minuter innan vi hade förstått att vi i stort sett tycker samma sak...


Sen upptäckte jag en annan kul grej:

>Du kan inte returnera flera värden från en funktion m.h.a. return, finns det något språk som kan det??? Hur skulle syntaxen på anropande sida se ut?

MATLABs programmeringsspråk kan faktiskt göra det, så det finns nog fler också.
t.ex.

[X t]=ode45(f, [0 1], 0, 1);

(kommer inte ihåg den exakta syntaxen)

Men man förstår varför de flesta språken inte har det, eftersom det är ett rent helvete att skriva vettiga program om man inte rört språket i någon månad.

Har ni diskuterat klart så jag kan sätta detta inlägg som löst?
Tack för hjälpen grabbar.

Japp vi är klara... Nu pratar jag för alla och hoppas dom håller med mig.
Annars skapar vi bara upp ett nytt inlägg :)

/Fredrik N