Varför är dessa Java projekt så avancerat skrivet?

Kan ta ett exempel. Halvvägs in i ett projekt blev vi tvungen att byta ut hela datalagret i en applikation från en ORM till en annan. Hade vi inte kodat hela datalagret abstrakt bakom interfaces så hade det varit ett rent helvete att byta ut, då applikationslagret arbetade mot datalagret. Men eftersom applikationslagret inte hade en aning om vad datalagret gjorde då ända kopplingen mellan dessa var ett interface med några metoder som kontrakt, så blev det att vi successivt kunde byta ut delar av det tills att allt var klart. Detta helt utan påverkan i affärs eller presentationslagret av applikationen.

Tänk även på att då du arbetar med skarpa projekt kan krav ändras rätt frekvent, kanske släpper en konkurrent på marknaden en ny feature som du behöver lägga till också. Då kan du inte ha massa tightly coupled kod som kräver att du skriver om 1000 rader kod för att byta ut en feature.

Handlar ju också om skalning. Kanske räcker det med att betala för mer memory för din cachingservice, istället för att behöva höja planen för hela applikationen? Det är mer lönsamt i längden att dela upp det i microservices. Sen är det också som jag sa tidigare, enklare att släppa kontinuerligt med features, gör man releases flera gånger i veckan så kan man inte sitta på en monolit.

Nu vet jag inte vad metoden har för syfte, men låter som du vill använda generics och då ha en implemenation där du sätter datatypen vid anropet. Sen kan du sätta upp repositoryt via constructor injection. Nu är detta i C#.

    public abstract class LogBase { }
    public class DataLog : LogBase { }
    public class UserLog : LogBase { }

    public interface ILoggingProvider<in T> where T : LogBase
    {
        void AddSelect();
    }

    public class LoggingProvider<T> : ILoggingProvider<T> where T : LogBase
    {
        private readonly IRepository<T> repository;
        public LoggingProvider(IRepository<T> repository)
        {
            this.repository = repository;
        }

        public void AddSelect()
        {
            IEnumerable<T> logs = repository.FindAll();
            // Do something...
        }
    }

Så kan du i din dependency injection service sätta upp det som exempelvis:

// Abstraction / Implementation
services.AddTransient(typeof(IRepository<,>), typeof(Repository<,>));
services.AddTransient(typeof(ILoggingProvider<,>), typeof(LoggingProvider<,>));

Då låter det snarare som om du saknar erfarenhet av att arbeta i mer komplexa affärsapplikationer. Vilket då även gör det svårare att relatera till varför man gör på vissa sätt. Objekt används för att kapsla in relaterad logik i små komponenter och för att få starktypad data.

Inom webb använder du ju komponenter hela tiden. Du vill inte repetera kod och logik på flera ställen.

Finns ju en orsak till varför TS är att föredra framför JavaScript vid större projekt.

Hela den här diskussionen känns extremt diffus och ospecifik. Jag kan nog hålla med generellt om att OOP för OOP:s skull är något man gärna undviker så långt om möjligt, men jag tror att vi skulle kunna få en mer produktiv diskussion om vi istället tittade på någon specifik kodsnutt, eller någon specifik klass, och började prata lite om hur denna skulle se ut olika beroende på programmeringsparadigm.

Men för att dra något ur luften bara, säg att du ska göra en simpel bankapplikation där du har olika slags kundtyper, och kunderna har olika slags konton. Gör man det där i Java utan OOP så blir det riktigt äckligt skulle jag säga men jag blir gärna motbevisad.

Enligt OOP så hade man skapat nån abstrakt klass eller interface att modellera specifika kundtyper ifrån och olika kontotyper likaså. Annars måste man ju ha en miljon olika datastrukturer för att hålla alla olika variationer?

Blir gärna motbevisad i hur man skulle göra det här simpla exemplet i Java utan att det blev rikigt äckligt. Jag kanske är för djupt inne i OOP för att se något annat sätt.

Nu är det ganska många år sedan jag senaste knackade Java-kod professionellt och har skrivit minimalt med Java frivilligt, så min bild av "bra Java" kanske inte är helt aktuellt.

Kikade lite på Pi4J. Tror att från ett rent Java-perspektiv gör man saker ungefär som förväntat. Problemet är att huvudmålet med all kod är i slutändan att den ska lösa en uppgift och sättet Pi4J "löser" uppgiften är allt annat än optimal givet att vad man normalt vill få ut av den här typen av bibliotek.

Några axplock på problem

• I botten använder man wiringPi, ett C bibliotek som primärt är tänkt för att ge folk från Arduino-världen något som ser ungefär lika ut på en RPi. Problemet här är: Arduino är tänkt för mikrokontrollers som sitter i en tight loop och gör något extremt specifikt, RPi snurrar på en multi-user OS där man inte vill köra busy-wait. Pi4J "löser" detta med att skapa trådpooler. Rätt sätt: låt Linux-kärnan polla HW m.h.a. interrupt (vilket med rätt val av GPIO-bibliotek är fullt möjligt då Linux-kärnan stödjer detta)

• Man har så många abstraktionslager som jag har lite svårt att se vad de tillför just då man bygger allt på ett abstraktionslager (wiringPi) som hanterar de mesta av skillnaderna i HW. Enda som egentligen skiljer är smådetaljer i pinout (och även det lär skilja rätt lite då de flesta kort man stödjer är RPi kompatibla).

• Ignorerar man ovan så är ändå en av huvudfunktionerna i ett GPIO bibliotek att ge effektiv och låglatens access till HW-pinnarna, att då blanda in flera OS-trådar i ett icke realtids-OS är en rejäl anti-pattern (och att ovanpå det köra en miljö med tracing-GC gör inte saken bättre, men det är ett litet problem i detta fall)

Sedan är vissa abstraktioner lite märkliga, ser inte riktigt vad GpioPinPwm tillför när man också har GpioPinPwmOutput. Inte så att PWM på något sätt är vettigt för input och även GpioPinPwmOutput är inte interface (man skiljer på HW PWM och software PWM, vilket är vettigt).

Interface GpioPinDigitalOutput har allt för mycket. Varför finns det blink() och pulse() metoder? De är väl ändå en service som kan utföras på en digital utgående pinne, inte en del av vad en digital pinne är?

Pi4J är mer ett ramverk än ett bibliotek, vilket för vad man försöker lösa känns rätt onödigt. Känns också som det mer är ett projekt för författaren av koden för att denne ska få testa på så många olika Java och RPi finesser som möjligt än ett vettig bibliotek för andra att använda... Exempel på en bra abstraktion av GPIO är t.ex. denna (långt mindre API jämfört med Pi4J även om tittar enbart på GPIO, ändå får det in långt fler användbara koncept som HW-interrupt utan trådar och läsa/skiva grupper av pinnar atomärt).

Angående OOP. Finns absolut användningsområden för OOP, men det är bara en teknik bland många och få saker inom programmering lär användas på fel ställe som OOP... Om man inte har nytta av tillstånd så är OOP fel val, så är extremt osannolikt att t.ex. affärslogik passar bra till OOP då själva logiken brukar vara helt tillståndslös. Samma sak gäller moderna "mikroservices" med REST APIer. Finns självklart undantag, det finns alltid.

OOP är ofta en väldigt dålig idé i multitrådade program. Detta då effektiv och korrekt synkronisering av data kräver att man explicit ser hur data representeras, vilket en av hörnsterna i OOP förhindrar (Rust är en av få språk som fått detta riktigt rätt, data och beteende är helt separerat där och språket garanterar att data endera är read-only eller bara kan nås från en enda tråd).
https://miro.medium.com/max/2114/1*8BSPw3u9qBdqJxrEfrN9JA.png
Ofta är det bara två av ovan man vill ha, polymorfism och abstraktion. Men dessa har i sig inget med OOP att göra, går hur bra som helst att använda båda de koncepten helt fristående från OOP.

Att allt måste finnas i kontext av en klass är en kraftig designmiss i Java. Hindrar inte att man använder icke-OOP teknik, men det ser lite yxigt ut ibland. Sedan finns ju andra språk som fungerar ihop med Java-plattformen, som Kotlin, vilket visar att problemet inte alls är fundamentalt i Java (i alla fall inte i plattformen Java).

Du kan säkert skriva en egen java-wrapper av WiringPi om du vill som ser ut som du vill ha den. Jag tror man ska lägga mindre tid på att försöka förstå hur personen tänkte än hur koden ser ut om om den är användbar. Kanske personen som skrev koden hade något annat liknande redan färdigt som råkade vara från ett större projekt med massa oop? Jag försöker bara förklara att det finns lika många åsikter som det finns programmerare och dessutom har alla skrivit kod de är nöjda med som efter ett halvår känns som ren katastrof. Allting ändras hela tiden och åsikter skiftar, vissa älskar nog upplägget. För mig löser OOP bara vissa specifika problem, men att separera kod i moduler med tydliga ’interface’/funktionalitets-specifikationer är det bästa som finns, då går det enkelt att testa, fixa en sak i taget utan att behöva ändra allt etc.

Skriva klart din klass A till 100% låter som en bra fortsättning. Finns ingen anledning att låta alla sista tio procenten vänta, du har ju ett "kontrakt" på vad B ska tillhandahålla.

Dina enhetstester bör ju ändå inte använda den konkreta implementationen av klass B, så det finns i regel mycket du kan göra för att skriva klart klass A och vara trygg med att den gör vad den ska.

Det där är lite halvkonstigt argumenterat. Om man inte skriver vettig kod, utan bara kod "som löser problemet" så kan du potentiellt skapa mycket teknisk skuld och mycket svårförvaltad programvara = blir i slutändan dyrare för kunden.
Skriv vettig kod, strukturera din kod, skriv och förvalta tester så blir det enklare att förvalta koden i framtiden, och säkerligen billigare också. Får man skräpkod i knät som någon skrivit och denne har struntat i tester så kommer det resultera i stora, troligen dyra, omskrivningar av koden. Det tycker nog uppdragsgivaren är mindre roligt.

Lättförståelig är helt olika för alla utvecklare beroende på bakgrund och vilka projekt man är insatt i. Han man skrivit mycket OOP kan man kanske förstå mer varför något är som det är. Till exempel behöver man inte sätta sig in i hela koden för att implementera ett interface, eller så kanske koden använder standardiserade interface som används på många andra ställen? Jag säger inte att jag personligen tycker det exemplet är fantastiskt, men jag har sett många andra exempel i min karriär som är långt värre. De som utvecklade denna har säkert en bakgrund där dessa typer av hierarki redan fanns. Sen kan det finnas andra saker som skalbarhet och prestanda som kan skilja mellan olika typer av implementationer... eller kanske koden ska gå att återanvända i många olika scenarion och sånt