Inlägg

@martin12344:

Ok, det är en bra start!

Källa: https://www.spelinspektionen.se/fragor--svar/

Det där talar ju också i din fördel.

Jag är verkligen ingen expert på detta men av att döma texten, specifikt den sista meningen, så låter det som att prestationsbaserade spel (tävlingar) inte kräver tillstånd.

Regleringen är ju till för att reglera hasardspel inte att begränsa människors prestation.

Jag tror även man måste kolla upp lite om skatter. Har för mig att tävlingsanordnare måste rapportera in kontrolluppgifter om detta i minsta fall.

I desktopmiljö blev det en märkbar skillnad. Skrolla, flytta fönster och jobba eller plugga i allmänhet ser mjukare ut. I praktiken så är det ju ingen skillnad kanske då jobbet ändå blir gjort men det är en väldigt behaglig känsla.

I FPS så kan jag säga att jag höjde min accuracy med kanske 5-8 procentenheter. Detta kunde jag se för att jag kunde se statistiken före, under och efter bytet. I detta fall var det inget jag kände utan det var så att "jobbet blev gjort" bättre.

Rent allmänt ger högre hz en behagligare mjuk vy att titta på men risken finns ju att man kanske offrar andra egenskaper som svärta, färger, etc.

@MartinSannel:

Om det där är ditt svar på alla frågor så kan du köpa vad som helst över 500kr och bli nöjd.

@anon203363:

Vad är Postman?

Om du kör utan en apikey så ska du inte kunna hämta någon data.
Om du kör med en apikey så ska du kunna hämta en CompanyData baserat på denna apikey förutsatt att den existerar.

Att du stoppar med en apinyckel i adressfältet gör ingenting. Request.Headers innehåller headers och customheaders.

Det låter som att du borde göra den basala funktionen först, för att få ett proof-of-concept. Sen kan du bygga vidare.

@anon203363:

Som det ser ut just nu så returnerar ApiKeyToCheck() "null" eller ett "CompanyData".
Om du får null så finns det ingen CompanyData baserat på inmatad apikey.
Om du får ett CompanyData så finns det en CompanyData baserat på inmatad apikey.

"Jämförelsen" har alltså redan gjorts här.

@anon203363:

Det ser ut som att du använder dina egna metoder lite knasigt.

Borde väl användas på detta sätt?

if (checkApiKeyExists)
{
        var cd = ApiKeyToCheck(context.Request.Headers["APIKey"]);
        if (cd != null)
        {
                 //Profit
        }
}

Jag förstår. Det du säger ger starkare indikationer på att det inte borde vara ditt fel eftersom det låter som att det sker sporadiskt?
Finns det ingen reddit-tråd, facebookgrupp eller annat för Tink API-utvecklare?
Jag har själv inte hört talas om Tink tidigare men om det är något som används i mellanstor skala borde det ju finnas flera som har samma problem.

Gäller GDPR myndigheter? Nu är det visserligen inte en myndighet men det är beställt av en myndighet och borde då inte denna "täckmantel" även gälla i detta fall?

Stämmer det verkligen?

@Sanguiness:
Jag kollade dokumentationen men det antar jag att du redan har gjort.
Jag tolkar det som att det inte är ditt fel eller något man kan göra åt det.

Källa: https://docs.tink.com/enterprise/api/#credentials

@Valentin1:
Skriv mer specifikt vad du vill göra.

Mitt enda svar är, för att det är ett design pattern. Design patterns kan inte överskrida grundläggande krav för att språket ska fungera. Syntaktisk socker kan hjälpa vilket kan göras genom att skriva plugins till ens utvecklingsmiljö, eller så finns det redan, eller så implementeras det som standard i utvecklingsmiljön. Eventuellt kan Java i sig implementera något som skulle underlätta det men det skulle jag personligen inte vilja att utvecklarna av Java fokuserade på då språket redan dras med otroligt långa utvecklingssprint och ligger långt bakom andra språk.

Rent teoretiskt så behöver en abstrakt klass inte implementera några metoder som kommer från ett interface. Det är upp till klassen som ärver av den abstrakta klassen att göra då.

Ok, utan att se koden så vet jag nog vad du har gjort.
Mitt förslag är att bryta upp alla steg och se vad som borde göras i varje steg och i vilken ordning.

Nu känns det som att du har:
1. Tagit användarens input
2. Stoppat in den i listan
3. Kontrollerat om värdet är ok
4a. Om värdet är ok, öka räknaren
4b. Om värdet är dåligt, minska räknaren och ta bort värdet ur listan

Om du byter plats på 2 och 3 så blir det mer logiskt och du behöver inte heller göra 4b då du kan hoppa vidare till nästa varv. Alltså ökas räknaren enbart om det är så att ett korrekt värde har matats in.

Men men, om du känner dig klar och nöjd så får det duga.

Ha en bra dag!

public class MyArrayList<T> extends ArrayList<T> {
    @Override
    public boolean add(T t) {
        System.out.println("Adding " + t);
        return super.add(t);
    }
}

List<String> myNewList = new MyArrayList<>();
myNewList.add("Hello");

Det där bryter finessen med decorator pattern eftersom du nu tvingar användaren att använda MyArrayList-klassen som alltid är en ArrayList. En del i decorator pattern är att lägga till funktionalitet i run time på ett objekt vilket inte går att göra om man gör på det där sättet. Genom att göra detta på interfacet List så kan man utöka funktionalitet (i detta fall att logga) i alla klasser som ärver av List genom att skicka in instansen till Decorator-objektet.

ublic class Elevator {
	private int floors;
	private int currentFloor = 0;
	private static final int MAX_FLOORS = 100;
	private static final int MIN_FLOORS = 2;
	

public Elevator(int floors) {
	this.floors = floors;
	if(floors < MIN_FLOORS)
		floors = MIN_FLOORS;
	else if(floors > MAX_FLOORS)
		floors = MAX_FLOORS;
	
}

public class Elevator {
	private int floors;
	private int currentFloor = 0;


public Elevator(int floors) {
	this.floors = floors;
	if(floors < 2)
		floors = 2;
	else if(floors > 100)
		floors = 100;
	
}

Jag tycker det är bra att du rent spontant tänker att förutsättningarna ska vara specifierade som statiska variabler. Det är mycket enklare att förändra värdena för en variabel än alla ställen i koden. I just detta fall är det bara totalt 4st ställen så det är inte supermånga men som standard bör man ha det som statiska variabler så som du har. Det är en mycket god vana.

Det skadar inte att vara övertydlig. Dessutom är det en dålig vana att utgå från att värden kommer ha defaultvärden. Det hade exempelvis inte fungerat att göra så med en lokal variabel i en metod.
Fokusera på att skriva kod som är enkel att förstå och enkel att underhålla istället för att skriva exempelvis underförstådd kod eller komplicerad kod för att spara rader exempelvis. Det lönar sig i längden och underlättar för dig och andra som tittar på koden.

public Elevator(int floors) {
	this.floors = floors;
	if(floors < MIN_FLOORS)
		return MIN_FLOORS;
	else if(floors > MAX_FLOORS)
		return MAX_FLOORS;
	
}

Du kan inte använda "return" av ett värde i en konstruktor för en konstruktor skapar alltid objektet man instansierar, inget annat. Det enda som ska vara klart när konstruktorn har kört klart är att alla värden ska vara korrekta. Du sätter fortfarande this.floors till floors vilket betyder att man kan sätta våning 2000 om man vill.
Undantaget med "return" är att man kan skriva "return;" vilket avbryter konstruktorn på den raden, det använder man om man inte vill köra vidare kod men det behöver du inte göra för denna uppgift.

public int getFloors() {
	return floors;

Syftet är att den är publikt åtkomstbar vilket betyder att du kan kalla "elevator.getFloors()" för att få antalet våningar. Om du inte hade haft denna metod så kan man inte få reda på denna information.

 public boolean moveElevator(int destinationFloor) {
	if (destinationFloor < 0 || destinationFloor > floors)
		return false;
	else 
		currentFloor = destinationFloor;
		return true;
	
}

Det räcker gott och väl med det där.
"this.floors = floors" betyder att instansvariabeln "this.floors" (variabeln du har deklarerat i "roten" till klassen) tilldelas värdet från den lokala variabeln "floors". Varför man måste använda "this.floors" är för att variablerna har samma namn men existerar i olika scopes. Hade du skrivit "floors = floors" hade du bara satt om den lokala variabeln till värdet från den lokala variabeln.

	@Override 
	public String toString() {
		return "The elevator is on floor" + currentFloor;
	
}

Ok, fint!

@sallyfowlr:

Enligt uppgift får du inte ha någon utskrift så din toString() är meningslös eftersom den inte hör till uppgiften. Men jag rekommenderar att ha kvar den för debugsyfte när du kör programmet.

1. Jag skulle säga att variabeln "destinationFloor" inte ska vara en instansvariabel utan en lokal variabel för moveElevator().

2. Det går inte att ta reda på destinationFloor eftersom hissen rör sig i omedelbar hastighet.

public int getDestinationFloor() {
    return destinationFloor;
}

3. Du kan inte bara skriva "int" du måste namnge det också.
Rimligtvis så skickar man med våningen som man ska till.

public boolean moveElevator(int) {
    if (destinationFloor < 0 || destinationFloor > floors)
        return false;
    else
        currentFloor = destinationFloor;
    return true;
}

4. Denna metod kommer alltid returnera "floors". All annan kod är såkallad "unreachable code" eftersom du har ett return-uttryck som avslutar metoden. Dessutom så stod det i uppgiften att antalet våningar ska sättas vid skapande av objektet, alltså konstruktorn.

public int getFloors() {
    return floors;
    if (floors < MIN_FLOORS)
        return MIN_FLOORS;
    else if (floors > MAX_FLOORS)
        return MAX_FLOORS;
}

@burton666:

Jag är ingen expert på Java men interface och andra OOP-relaterade saker fungerar snarlikt över alla språk.

Man ärver inte ett interface, man implementerar det.
Ett interface säger enbart vilka metoder som ska finnas. Alla som vet att en klass implementerar interfacet vet att alla dessa metoder existerar. Ett interface kan man se som ett avtal. "Om du implementerar interfacet så måste du uppfylla det avtalet genom att implementera alla metoderna".

Detta betyder att du inte kan skippa att implementera metoderna för vad skulle hända om du inte gjorde det? Avtalet skulle inte vara uppfyllt och programmeraren som använder klassen hade fått tillgång till metoder som inte existerar.

Det finns däremot vissa undantag. Implementation måste alltid göras men det är inte alltid man kan skriva faktiskt kod i implementationen som gör det semantiska som krävs för att uppfylla metodens önskade resultat. I dessa fall implementerar man metoden men kastar ett UnsupportedOperationException.
Om du tittar på dokumentationen för List.add så ser du att den kan kasta detta exception om det är så att denna lista inte har stöd för detta.

När du skriver "resten hanteras som vanligt av java.util.List" så går det inte för att ett interface har ingen kod som exekveras, endast klasserna som implementerar interfacet har koden som exekveras. Det bästa du kan göra är att skicka vidare exekveringen till respektive klass.

Den koden du har just nu skulle jag tolka som "hanteras som vanligt av java.util.List". Du skickar ju bara vidare exekveringen av koden till "list"-variabeln utan att göra något annat med det. När alla metoder är implementerade så kommer din ListLogger inte kräva att en enda metod som ska implementeras från List eller ListDecorator då dessa redan ska vara implementerade i ListDecorator.