Om man ändå ska passa på att lära ut objektorientering, kan det vara värt att låta bli att använda internal om det inte verkligen finns ett syfte för det. Min uppfattning är att i nio fall av tio som folk använder det, har de ingen aning om varför de gör det.
Tvärtom, bättre att lära sig att använda private och internal. Min uppfattning är snarare att de som inte använder sig av dessa inte vet varför man ska använda sig av det. Om det är svårt, http://stackoverflow.com/questions/4...lic-in-c-sharp
Tvärtom, bättre att lära sig att använda private och internal. Min uppfattning är snarare att de som inte använder sig av dessa inte vet varför man ska använda sig av det. Om det är svårt, http://stackoverflow.com/questions/4...lic-in-c-sharp
Jag vet vad skillnaden är...
Du använder det utan syfte, vilket är min poäng. Vad händer när du vill enhetstesta din kod med ett enhetstestprojekt utanför implementationsprojektet?
Hmm, hur gör jag för att värdet på backen ska öka varje gång en dricka läggs till? Kan man inte lägga till något i stil med sum+7 (eller vad drickan nu ska kosta) för respektive alternativ.
Kod:
for (int i = 0; i < läskback.Length; i++)
{
läskback[i] = dryck;
}
dryck = Console.ReadLine();
switch (dryck)
{
case "1":
Console.WriteLine("Coca-Cola");
break;
case "2":
Console.WriteLine("Fanta");
break;
case "3":
Console.WriteLine("Sprite");
break;
case "4":
Console.WriteLine("Hallonsoda");
break;
case "5":
Console.WriteLine("Cider");
break;
default:
Console.WriteLine("Fel! Välj mellan alternativ 1 till 5.");
break;
}
Hmm, hur gör jag för att värdet på backen ska öka varje gång en dricka läggs till? Kan man inte lägga till något i stil med sum+7 (eller vad drickan nu ska kosta) för respektive alternativ.
Kod:
for (int i = 0; i < läskback.Length; i++)
{
läskback[i] = dryck;
}
dryck = Console.ReadLine();
switch (dryck)
{
case "1":
Console.WriteLine("Coca-Cola");
break;
case "2":
Console.WriteLine("Fanta");
break;
case "3":
Console.WriteLine("Sprite");
break;
case "4":
Console.WriteLine("Hallonsoda");
break;
case "5":
Console.WriteLine("Cider");
break;
default:
Console.WriteLine("Fel! Välj mellan alternativ 1 till 5.");
break;
}
Är väl bara att lägga till läskback[i] = dryck; efter du har låtit användaren mata in en dryck? Eller vad frågar du efter egentligen?
__________________
Senast redigerad av tj. 2016-04-19 kl. 18:21.
Du använder det utan syfte, vilket är min poäng. Vad händer när du vill enhetstesta din kod med ett enhetstestprojekt utanför implementationsprojektet?
Ja, vad är grundregel nummer 1, 2 samt tre inom tdd:
1. Programmera inte mot en klass, utan mot ett interface.
2. Se 1
3. Se 1
Man får snabbare en bättre förståelse för koden om man använder private, internal samt public. Vid en refactoring dessutom, så är det ju betydligt lättare att gå från private till public än tvärtom, eller hur?
Ja, vad är grundregel nummer 1, 2 samt tre inom tdd:
1. Programmera inte mot en klass, utan mot ett interface.
2. Se 1
3. Se 1
Man får snabbare en bättre förståelse för koden om man använder private, internal samt public. Vid en refactoring dessutom, så är det ju betydligt lättare att gå från private till public än tvärtom, eller hur?
Det är sällan det finns behov för att kapsla in data inom assemblies. Private (och protected, vid arv) och public är alltid relevant att ta hänsyn till. Internal? Not so much. Det är sällan det behovet uppstår, framför allt nu för tiden när solutions inte längre består av 100 CS/VB-projekt med hårda beroenden. Public är mer intuitivt och skulle det nu vara så att du grötar ner din kod till den grad att du nu måste använda internal, så fine, gör en mindre refactoring. Men det finns ingen vits att försöka pracka på alla andra att använda det bara för att du, högst personligen, tycker att det är ett häftigt keyword.
Det är sällan det finns behov för att kapsla in data inom assemblies. Private (och protected, vid arv) och public är alltid relevant att ta hänsyn till. Internal? Not so much. Det är sällan det behovet uppstår, framför allt nu för tiden när solutions inte längre består av 100 CS/VB-projekt med hårda beroenden. Public är mer intuitivt och skulle det nu vara så att du grötar ner din kod till den grad att du nu måste använda internal, så fine, gör en mindre refactoring. Men det finns ingen vits att försöka pracka på alla andra att använda det bara för att du, högst personligen, tycker att det är ett häftigt keyword.
Häftigt? Vad är det som är häftigt? Finns nästan inget häftigt inom programmeringen. Du har ett synsätt, jag har ett annat synsätt. Uppenbarligen hade jag ordentligt med kött på benen till skillnad från vad du trodde, och det verkar reta dig. Men det är din ensak. Jag ger min bild av det hela. Önskar du ge en annan bild, varsågod.
Är väl bara att lägga till läskback[i] = dryck; efter du har låtit användaren mata in en dryck? Eller vad frågar du efter egentligen?
Det jag vill är att drickorna ska kosta olika och att varje gång en dricka läggs till så ska backens "värde" öka. Gör jag det svårare än vad det är
Här är koden i sin helhet:
Kod:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
namespace ConsoleApplication35
{
public class Läskbacken
{
private string[] läskback = new string[24];
public int antaldrycker = 0;
public int värde = 0;
public string dryck;
private bool huvudMeny = true;
public void Run()
{
while (huvudMeny)
{
Console.WriteLine("Välj något av följande alternativ:");
Console.WriteLine("1. Lägg till dryck.");
Console.WriteLine("2. Visa backens innehåll.");
Console.WriteLine("3. Visa backens värde.");
Console.WriteLine("4. Avsluta programmet.");
Console.WriteLine();
switch (Console.ReadLine())
{
case "1":
läggtilldryck();
break;
case "2":
visaback();
break;
case "3":
visavärde();
break;
case "4":
huvudMeny = false;
break;
}
}
}
public void läggtilldryck()
{
Console.WriteLine("Välj en dryck:");
Console.WriteLine("1. Coca Cola");
Console.WriteLine("2. Fanta");
Console.WriteLine("3. Julmust");
Console.WriteLine("4. Lättöl");
Console.WriteLine("5. Ramlösa");
for (int i = 0; i < läskback.Length; i++)
{
läskback[i] = dryck;
}
dryck = Console.ReadLine();
switch (dryck)
{
case "1":
Console.WriteLine("Coca Cola");
Console.WriteLine();
break;
case "2":
Console.WriteLine("Fanta");
Console.WriteLine();
break;
case "3":
Console.WriteLine("Julmust");
Console.WriteLine();
break;
case "4":
Console.WriteLine("Lättöl");
Console.WriteLine();
break;
case "5":
Console.WriteLine("Ramlösa");
Console.WriteLine();
break;
default:
Console.WriteLine("Fel! Välj mellan alternativ 1 till 5.");
Console.WriteLine();
break;
}
for (int j = 0; j < läskback.Length; j++)
{
if (antaldrycker == 24)
{
Console.WriteLine("Din back är full.");
Console.WriteLine();
}
else
{
antaldrycker++;
break;
}
}
}
public void visaback()
{
Console.WriteLine("Antalet drycker i din back är " + antaldrycker, läskback.Length);
Console.WriteLine();
}
public void visavärde()
{
for (int k = 0; k < läskback.Length; k++)
värde = antaldrycker * 10;
{
Console.WriteLine("Din back är värd " + värde + " kronor");
Console.WriteLine();
}
}
class Program
{
static void Main(string[] args)
{
Läskbacken l = new Läskbacken();
l.Run();
}
}
}
}
__________________
Senast redigerad av svampplockarn 2016-04-21 kl. 12:18.
Antingen så lägger du till lite if-satser i din visavärdet-funktion som multiplicera olika beroende på vad det är för dricka i drickabacken, eller så får du börja spara drickorna som Dricka-objekt som håller koll på dess namn och pris, istället för bara namn.
Antingen så lägger du till lite if-satser i din visavärdet-funktion som multiplicera olika beroende på vad det är för dricka i drickabacken, eller så får du börja spara drickorna som Dricka-objekt som håller koll på dess namn och pris, istället för bara namn.
Ok, tack för svaret. Det löste sig efter lite om och men
Flashback finansieras genom donationer från våra medlemmar och besökare. Det är med hjälp av dig vi kan fortsätta erbjuda en fri samhällsdebatt. Tack för ditt stöd!
Stöd Flashback
Swish: 123 536 99 96Bankgiro: 211-4106
Stöd Flashback
Flashback finansieras genom donationer från våra medlemmar och besökare. Det är med hjälp av dig vi kan fortsätta erbjuda en fri samhällsdebatt. Tack för ditt stöd!