Java >> Java tutorial >  >> Tag >> Netty

Nettys struktur

Nettys pakkestruktur er fantastisk.

Enhver programmør bør studere det; hvert system bør efterligne det; enhver projektleder bør printe det ud, smække på en væg og sige til udviklerne:"Det."

Netty er en "... en asynkron begivenhedsdrevet netværksapplikationsramme til hurtig udvikling af vedligeholdelige højtydende protokolservere og -klienter", men det betyder ikke noget her, da vi ikke analyserer dets adfærd. Se i stedet figur 1.

Figur 1:Nettys pakkestruktur, der udvikler sig over 7 år.

Figur 1 viser et spoiklin-diagram (cirkler er pakker; lige linjer er afhængigheder nedad på siden; buede linjer er afhængigheder opad på siden) af Nettys udviklende pakkestruktur, og hvis du ikke umiddelbart kan se, hvor velstruktureret den er. er, så tag et kig på Junit, Struts eller Ant.

Det er heller ikke blot tilfældet, at "God struktur er i beskuerens øje." Strukturel lidelse tilbyder en objektiv måling af, hvor dårligt et program er struktureret:Jo lavere strukturel lidelse, jo bedre struktur. Nettys lidelse ligger langt under næsten alle andre, se tabel 1.

Program Pakkestrukturel lidelse
Myre 81 %
Junit 76 %
Struts 74 %
Lucene 73 %
FitNesse 61 %
Forår 35 %
Netty 26 %

Tabel 1:Strukturel forstyrrelse af alle programmer gennemgået i denne serie.

Figur 2 viser, hvad mere er, hvordan denne endelige strukturelle lidelse ikke er tilfældig. Nettys strukturelle lidelse har været lav i hele sin syvårige levetid.

Figur 2:Nettys strukturelle lidelse gennem 11 udgivelser (med andre til sammenligning).

Så:hvorfor er denne pakkestruktur så god?

Givet et diagram som figur 1, kan vi stille to hurtige spørgsmål for at vurdere - løst - den afbildede strukturs fortjeneste.

I kommerciel softwareudvikling betyder "God struktur" blot "Billigt at opdatere." Ydermere tyder beviser på, hvad enhver programmør med et greb om ringvirkninger ved:at jo flere ting X afhænger af, jo mere sandsynligt vil det blive påvirket af ringvirkninger, og desto dyrere kan X være.

Vælg derfor en pakke, der i høj grad afhænger af andre, og spørg (A) kan vi nemt identificere de afhængige pakker og (B) hvor lille en delmængde af helheden er disse afhængige pakker?

Dårligt strukturerede programmer slører disse afhængigheder, og granskning afslører ofte afhængigheder på næsten hele systemet. Velstrukturerede programmer præsenterer dog klart de afhængige pakker, og de er få.

Lad os først stille disse to spørgsmål i et dårligt struktureret program.

Figur 3 viser den mareridtsagtige 90 % strukturelle lidelse hos Jenkins, og viser derefter de fremhævede transitive afhængigheder fra de fem pakker (værktøjstip), der afhænger mest af andre.

Figur 3:Jenkins, åh Jenkins.

At spore afhængigheder i Jenkins er klart … en udfordring, med mange pakker afhængige af over 75 % af resten af ​​systemet.

Figur 4 gentager eksperimentet, men viser de transitive afhængigheder fra de fem Netty-pakker, der afhænger mest af andre:epoll, spdy, websocketx, http og nio .

Figur 4:Fremhæv (i blåt) de værste transitive afhængigheder i Netty.

I slående kontrast til Jenkins kan vi se Netty-pakkerne, der er afhængige af, og hvor få der er. Netty har 55 pakker, men det maksimale afhængigt af enhver anden er kun 12, det er kun 22% af systemet.

Er Nettys pakkestruktur perfekt? Selvfølgelig ikke. Især den cirkulære afhængighed mellem interne og samtidig skaber desværre en stærk kobling i den kerne intern/samtidig/kanal/buffer/util pakke klynge.

Ser man under overfladen, er Nettys klassestruktur faktisk dårlig. Nettys designere opgav tilsyneladende nogle af deres fremragende strukturelle principper, da de byggede deres klasseniveau. En skam.

Men ser man på den pakkestruktur … wow.

Til sidst, i stedet for at analysere Nettys afgørende udgivelser, præsenterer sig en arkitektonisk observation. Nettys arkitekter ser ud til at have besluttet sig for en ret genial implementeringsstrategi. Ved at downloade Netty får du både en alt-i-en jar-fil, men også 13 jar-filer, som indeholder de separate dele af systemet. Formodentlig kan du indlæse hele Netty eller bare de dele af den, du ønsker.

Én jar-fil, den "fælles" jar, rummer den interne/samtidige/kanal/buffer/util pakkeklynge, hvorimod andre har f.eks. "codec", "tcnactive", "transport" osv., hvilket tyder på, at disse sidstnævnte jars er klienter af den fælles jar, men ikke er klienter af hinanden og derfor ikke er afhængige af en en anden. Nettys designere kan således i selve deres udrulning have nedfældet den adskillelse og indkapsling af deres undersystemer, der har ført til denne brancheslående pakkestruktur.

Det eneste tilbageværende spørgsmål er:hvorfor følger flere projekter ikke Nettys føring? Hvorfor har Jenkins en 90% strukturel lidelse? Hvorfor opdelte Jenkins' designere ikke deres system korrekt for at reducere kobling mellem pakker? Hvorfor accepterer softwareudviklingsområdet så villigt de omkostninger, som disse dårlige strukturer genererer?

Er vi ikke bedre end dette?

Oversigt

Hvis der var en årlig pris for den bedste Java-pakkestruktur i brug i dag, ville Netty have vundet den syv år i træk.

Java tag