En samling viktiga begrepp inom mjukvaruutveckling — från OOP och designmönster till arkitektur och databaser.
Att dölja komplex implementering bakom en enkel gränssnitt. Inom OOP innebär abstraktion att man fokuserar på vad ett objekt gör snarare än hur det gör det. Abstrakta klasser och interface är verktyg för att uppnå abstraktion.
En svag form av association där ett objekt innehåller referenser till andra objekt, men de ingående objekten kan existera oberoende. Till exempel en skola som har elever — eleverna finns kvar även om skolan läggs ner.
En mekanism inom OOP där en klass (subklass) ärver egenskaper och metoder från en annan klass (superklass). Möjliggör återanvändning av kod och skapande av hierarkier. Föredra komposition framför arv.
En stark form av association där ett objekt består av andra objekt och de ingående objekten inte kan existera utan det sammansatta objektet. Till exempel ett hus som består av rum — om huset rivs försvinner rummen.
Ett problem som uppstår vid multipelt arv där en klass ärver från två klasser som båda ärver från samma basklass. Det blir otydligt vilken implementation som ska användas. Löses i flera språk med virtuellt arv eller interface.
Inkapsling — principen att ett objekts interna tillstånd ska skyddas från extern åtkomst. Data nås endast via publika metoder (getters/setters), vilket säkerställer kontrollerad och konsekvent användning.
Ett kontrakt inom OOP som definierar vilka metoder en klass måste implementera, utan att specificera hur de ska implementeras. Möjliggör polymorfism och lös koppling mellan komponenter.
Flera metoder med samma namn men olika parametrar inom samma klass. Kompilatorn väljer rätt metod baserat på antalet och typerna av argument. Möjliggör flexibla API:er med samma konceptuella operation.
En subklass tillhandahåller en specifik implementation av en metod som redan definierats i dess superklass. Möjliggör polymorfism där rätt metod anropas baserat på objektets faktiska typ vid körning.
Ett av de fyra grundläggande koncepten inom OOP som innebär att objekt av olika typer kan behandlas enhetligt genom ett gemensamt gränssnitt. Samma metodanrop kan bete sig olika beroende på objektets faktiska typ.
Ett koncept inom dynamiskt typade språk där ett objekts lämplighet bestäms av närvaron av vissa metoder och egenskaper, inte av dess faktiska typ. "If it walks like a duck and quacks like a duck, it's a duck."
En funktion i statiskt typade språk som gör att klasser, interface och metoder kan arbeta med olika datatyper på ett typsäkert sätt. Möjliggör återanvändning av kod med typen som parameter.
Oföränderlighet — ett objekts tillstånd kan inte ändras efter att det skapats. Oföränderliga objekt är trådsäkra, enklare att resonera kring och undviker en hel klass av buggar. Centralt inom funktionell programmering.
En anonym funktion som kan definieras inline och behandlas som ett värde. Lambdas är centrala inom funktionell programmering och används ofta för korta operationer som att transformera eller filtrera data.
Ett designmönster från funktionell programmering som representerar en beräkning som en sekvens av steg. Monader hanterar bieffekter som null-värden (Maybe/Option), asynkronitet (Promise) eller felhantering (Either) på ett rent sätt.
Ett objekt som representerar ett framtida värde eller resultat av en asynkron operation. Kan vara i tillstånden pending (väntar), fulfilled (uppfylld) eller rejected (avvisad). En central del av modern asynkron programmering.
Ett programs förmåga att inspektera och modifiera sin egen struktur och beteende vid körning. Möjliggör dynamisk typidentifiering, metodanrop och skapande av objekt utan statisk kunskap om typerna.
Ett mått på hur väl ansvarsområdena inom en modul eller klass hänger ihop. Hög cohesion innebär att alla delar av en klass arbetar mot ett gemensamt mål, medan låg cohesion tyder på att klassen gör för många olika saker.
Ett mått på hur beroende olika moduler eller klasser är av varandra. Lös koppling (loose coupling) är eftersträvansvärt eftersom det gör systemet mer flexibelt och lättare att underhålla.
Ett mönster där ett objekt vidarebefordrar en uppgift till ett annat objekt istället för att utföra den själv. Möjliggör återanvändning av beteende utan arv.
En metod för programvarudesign där komponenter definierar formella kontrakt genom förvillkor, eftervillkor och invariant. Ursprungligen utvecklat av Bertrand Meyer för språket Eiffel.
Don't Repeat Yourself — en princip som säger att varje kunskapsdel ska ha en entydig representation inom ett system. Upprepning av kod leder till mer underhåll och ökad risk för fel.
Keep It Simple, Stupid — en designprincip som betonar att enkelhet bör vara ett nyckelmål i design. Onödig komplexitet bör undvikas eftersom den gör systemet svårare att förstå, underhålla och vidareutveckla.
Processen att förbättra befintlig kod genom att ändra dess interna struktur utan att påverka dess externa beteende. Syftar till att göra koden mer lättläst, underhållbar och effektiv utan att lägga till ny funktionalitet.
Teknisk skuld — en metafor för den extra kostnad som uppstår när man tar genvägar i programvaruutveckling. Precis som finansiell skuld ackumulerar teknisk skuld "ränta" i form av ökad komplexitet och minskad produktivitet.
You Aren't Gonna Need It — en princip från extrem programmering (XP) som säger att man inte ska lägga till funktionalitet förrän den faktiskt behövs. Många gissningar om framtida behov visar sig vara felaktiga.
DIP — den sista principen i SOLID. Betyder att högnivåmoduler inte ska bero på lågnivåmoduler, utan båda ska bero på abstraktioner. Abstraktioner ska inte bero på detaljer, detaljer ska bero på abstraktioner.
ISP — den fjärde principen i SOLID. Innebär att inget klient ska tvingas bero på metoder det inte använder. Stora, feta interface bör delas upp i mindre, mer specifika interface.
LSP — den tredje principen i SOLID. Om S är en subtyp av T, då ska objekt av typen T kunna ersättas med objekt av typen S utan att programmets korrekthet påverkas. Subklasser ska vara utbytbara mot sina basklasser.
OCP — den andra principen i SOLID. Programvaruenheter (klasser, moduler, funktioner) ska vara öppna för utökning men stängda för modifiering. Beteende ska kunna utökas utan att ändra befintlig kod.
SRP — den första principen i SOLID. En klass ska ha endast en anledning att ändras, vilket innebär att den ska ha ett enda, väldefinierat ansvarsområde. Den mest grundläggande principen inom objektorienterad design.
Ett akronym för fem designprinciper inom objektorienterad programmering: Single Responsibility Principle, Open/Closed Principle, Liskov Substitution Principle, Interface Segregation Principle och Dependency Inversion Principle.
Ett strukturellt designmönster som låter objekt med inkompatibla gränssnitt samarbeta. Adaptern fungerar som ett mellanlager som översätter ett gränssnitt till ett annat.
Ett strukturellt designmönster som dynamiskt lägger till beteenden till ett objekt genom att "linda in" det i dekoratörer. Ett flexibelt alternativ till arv för att utöka funktionalitet.
En teknik där ett objekts beroenden tillhandahålls utifrån istället för att objektet själv skapar dem. Ökar flexibilitet, testbarhet och följer principen om inversion av kontroll (IoC).
Ett skapandemönster som definierar ett gränssnitt för att skapa objekt, men låter subklasser bestämma vilken klass som instansieras. Förskjuter objektsskapandet till subklasser.
Ett designmönster som använder ett objekt som representerar "inget" istället för att använda null-referenser. Eliminerar null-checkar och förenklar kodflödet genom att tillhandahålla ett standardbeteende.
Ett beteendemönster där ett objekt (subject) underhåller en lista av beroende objekt (observers) och automatiskt meddelar dem när tillståndet ändras. Används ofta i händelsestyrda system.
Ett skapandemönster som säkerställer att en klass endast har en instans och tillhandahåller en global åtkomstpunkt till denna. Används ofta för konfiguration, loggning eller anslutningspooler.
Ett beteendemönster som låter dig definiera en familj av algoritmer, placera var och en i en egen klass och göra dem utbytbara. Algoritmen kan väljas vid körning utan att ändra klientkoden som använder den.
Application Programming Interface — ett gränssnitt som definierar hur olika programvarukomponenter ska kommunicera med varandra. Ett API specificerar vilka anrop som kan göras, vilka parametrar som förväntas och vilken data som returneras.
En teknik där data lagras temporärt för att snabba upp framtida förfrågningar istället för att räkna ut eller hämta samma data upprepade gånger. Används på alla nivåer från processor till webbläsare.
En arkitekturfilosofi av Robert C. Martin som betonar separation av concerns genom koncentriska lager. Affärslogik och domänmodell placeras i centrum, medan externa detaljer som databaser, UI och ramverk hålls i yttre lager.
Command Query Responsibility Segregation — ett mönster som separerar operationer som ändrar data (commands) från operationer som läser data (queries). Möjliggör optimering av läs- och skrivoperationer oberoende av varandra.
DDD — en mjukvaruutvecklingsmetodologi som fokuserar på att modellera domänen (verksamhetslogiken) i samarbete med domänexperter. Centrala koncept inkluderar Entity, Value Object, Aggregate och Bounded Context.
Inom DDD: ett domänobjekt som har en unik identitet som är bestående över tid, även om dess attribut ändras. Till skillnad från Value Object som definieras av sina attribut.
Ett mönster där alla ändringar av applikationstillstånd lagras som en sekvens av händelser (events), snarare än att bara spara det aktuella tillståndet. Möjliggör full revisionshistorik och tidsresning.
En arkitekturstil där en applikation byggs som en samling små, självständiga tjänster som var och en körs i sin egen process och kommunicerar via lätta mekanismer som HTTP eller meddelandeköer.
Model-View-Controller — ett arkitekturmönster som delar upp en applikation i tre sammankopplade delar: Model (data och affärslogik), View (presentation) och Controller (input och flöde). Används flitigt inom webb- och GUI-utveckling.
Ett mönster som fungerar som ett mellanlager mellan domän- och datalagret. Ger en samlingsliknande bild av data med standardoperationer som CRUD, och döljer den underliggande databaskommunikationen.
Representational State Transfer — en arkitekturstil för distribuerade system som använder HTTP-protokollets metoder (GET, POST, PUT, DELETE) för att manipulera resurser som identifieras av URL:er. Stateless och cacheable.
Inom DDD: ett objekt som definieras av sina attribut snarare än en unik identitet. Två Value Objects är lika om alla deras attribut är lika. Oföränderliga (immutable) och används för att modellera begrepp som pengar, datum eller adresser.
Create, Read, Update, Delete — de fyra grundläggande operationerna för persistent lagring. Används ofta som bas för RESTful API:er och databasinteraktion.
Not Only SQL — en kategori av databaser som inte använder den traditionella relationella modellen med tabeller, rader och SQL. Inkluderar dokumentdatabaser (MongoDB), grafdatabaser (Neo4j) och nyckel-värde-databaser (Redis).
En process i relationsdatabasdesign som organiserar data för att minska redundans och beroenden. Indelas i normalformer (1NF, 2NF, 3NF, BCNF) där varje form har striktare krav på tabellstrukturen.
Object-Relational Mapping — en teknik som mappar objekt i en objektorienterad applikation till tabeller i en relationsdatabas. Minskar mängden SQL-kod som utvecklaren måste skriva men kan medföra prestandaproblem.
Structured Query Language — standardspråket för att hantera data i relationsdatabaser. Inkluderar operationer för att skapa tabeller, infoga, läsa, uppdatera och ta bort data, samt avancerade frågor med joins och aggregationer.
Ett matematiskt notation som beskriver hur effektiv en algoritm är i termer av tid och minne. Vanliga exempel är O(1) för konstant tid, O(n) för linjär tid, O(n²) för kvadratisk tid och O(log n) för logaritmisk tid.
En teknik där en funktion anropar sig själv för att lösa ett problem genom att dela upp det i mindre delproblem. Kräver ett basfall för att avsluta och en rekursiv härledning. Vanligt vid trädstrukturer och algoritmer.
Ett tillstånd i flertrådade system där två eller flera trådar väntar på resurser som den andra tråden håller, vilket gör att alla trådar blockeras permanent. Kan undvikas genom tydlig resursallokeringsstrategi.
Ett oförutsägbart beteende i flertrådade system där resultatet beror på i vilken ordning trådar exekveras. Uppstår när flera trådar samtidigt läser och skriver till delad data utan synkronisering.