Csináltatok már másoknak libraryt?

Posted by OgreAki47@reddit | programmingHungary | View on Reddit | 26 comments

Én még életemben nem írtam olyan kódot, amit valaki más hívna, de ha ilyet csinálnék, pusztán józan paraszti ész alapján tutira nem a konkrét munkát végző osztályokat exponálnám a hívónak, hanem lenne egy absztrakciós réteg és az hívná a konkrét munkát végző osztályokat. Egyrészt azért, hogy azokat breaking change nélkül refaktorálhassam, másrészt azért, mert a konkrét munkát végző osztályokba nem illik CsinájjáMindentIs metódust tenni, az absztrakciós rétegbe viszont nyugodtan lehet, hadd legyen a másiknak könnyű dolga. Ez nem tudom, hogy design pattern meg practice-e, mert az olyanokhoz én nem értek, csak próbálok logikusan gondolkodni (azok meg főleg azoknak valók, akik receptből szoktak főzni :) ) de érdekelne, hogy aki vágja az ilyen pattern-témákat, az mit gondol róla? Azért mondom ezt, mert úgy tűnik, hogy a PyDifact libraryban lett pár breaking change refaktorálással, mert nincs absztrakciós réteg és hát ez így nekem nem túl profi dolog.

Reply to Post

26 Comments

[-]

DadBodPerish@reddit

Erre való a semver

[-]

Lajos-A-Hegyrol@reddit

Tied lenne az awardom, ha lenne.

[-]

Dangerous-Stable-298@reddit

Igen, erre vannak patternek meg szabályok. Pythonban nem vagyok annyira mélyen jártas, OOP-ban viszont alap, hogy ilyesmi szinten állunk neki a dolgoknak: \- design patterns: érdemes ezt nézegetni, főleg a creational patterneket - [https://refactoring.guru/design-patterns/structural-patterns](https://refactoring.guru/design-patterns/structural-patterns) \- SOLID principles: érdemes erre törekedni amikor lib szintű kódot írsz - [https://www.digitalocean.com/community/conceptual-articles/s-o-l-i-d-the-first-five-principles-of-object-oriented-design](https://www.digitalocean.com/community/conceptual-articles/s-o-l-i-d-the-first-five-principles-of-object-oriented-design) \- loose coupling: amikor spagettire kezd hasonlítani a kód akkor ezt is érdemes figyelembe venni - [https://stackoverflow.com/questions/226977/what-is-loose-coupling-please-provide-examples](https://stackoverflow.com/questions/226977/what-is-loose-coupling-please-provide-examples) \- unit/feature tesztek: egy unit teszt akkor jó ha a működést rendesen tudod anélkül tesztelni hogy konkrét függősége lenne, ez tud segiteni abban, hogy minél jobban törekedj a loose coupling-re, absztrakciókra, interface-ekre és a DI-ra Mivel már van AI, a helyedben először megírnám a kódot legjobb tudásom szerint, majd szépen fokozatosan kérném meg az AI-t tanulás szempontjából, hogy refaktorálja a valamelyik design pattern alapján, vagy írjon hozzá tesztet, loose coupling / solid szerint módosítsa stb... Nézz meg néhány lib-et ami hasonlóan működeik, pl. payment gatewayeknél jellemző, hogy több provider van de maga az implementáció egy absztrakciós bázison alapszik

[-]

OgreAki47@reddit (OP)

úgy nézem, hogy ezek jó részét már feltaláltam magamtól, vagy láttam mástól, ez itt pl. a facade, ez mind csak alkalmazott logika és józan ész

[-]

Dangerous-Stable-298@reddit

igen, ezért hívják pattern-nek, nagy részük ismétlődő praktikákon alapszik. Nem értem amúgy a lepontozásokat, valszeg akik downvote-olnak azok még nem jutottak el egy komolyabb technikai állásinterjúig és nem dolgoztak olyan szintű vállalati rendszeren ahol a többi fejlesztő kódját egységes módon kellene szabályozni. Mondjuk ehhez elég egy open source frameworkben (pl. Laravel) kontributorként részt venni, ott is ezek a szabályok. Egyébként gyakorlásnak/tanulásnak ezt tudom még javasolni, open source lib-eken kontributorként ha csatlakozol akkor a maintainerek abba az irányba terelnek a reviewk során hogy ezeket a szabályokat próbáld követni

[-]

Pleasant_Resolve5678@reddit

Igen, mi nem jutottunk el. :) És véletlenül sem azért van sok downvote, mert ilyen full alap dolgokat hangsúlyoztok ki nagy dolognak, tudásnak :) legközelebb azt írjátok ki, meg magyarázgassátok egymásnak, hogy mire jó az if/else.

[-]

Dangerous-Stable-298@reddit

Bocs de nem ellenetek szólt, valszeg op-nak nem alap dolog de szeretne ebben fejlődni, nem tudom miért van értelme köpködni

[-]

sgtGiggsy@reddit

>valszeg akik downvote-olnak azok még nem jutottak el egy komolyabb technikai állásinterjúig és nem dolgoztak olyan szintű vállalati rendszeren ahol a többi fejlesztő kódját egységes módon kellene szabályozni. Nem, a downvote-ok a fogalmak keverése miatt vannak, illetve azért, mert az általa felvetett "megoldás" az semmit sem oldana meg.

[-]

sgtGiggsy@reddit

Az exponálás itt az "expose" akart lenni? Soha az életben nem hallottam ezt exponálásnak nevezni. Ezt félretéve is, miért kellene ide absztrakciós réteg? Ha az osztály refaktorálása elcseszi a régi rendszerű metódushívásokat, akkor az absztrakciós réteget is refaktorálni kell, hogy a régi hívások működjenek. Abban egyetértünk, hogy CsináljMindentIs metódust nem illik készíteni.

[-]

Abakol@reddit

Nem tudom miért tesz mindenki úgy, mintha OP hülyeséget írna. Igen, egy jól megírt librarynek legyen egy egyszerűsített interfésze, ami elrejti a belső method hívásoknak az összeláncolását egy-egy use case specifikus method mögé, hogy az apróbb belső részletek megváltozása ne feltétlenül jelentsen breaking change-t az interfészre nézve, illetve hogy ne a consumer kódnak kelljen foglalkoznia a library belső implementációs részleteinek a logisztikájával. Ez kb a facade pattern.

[-]

sgtGiggsy@reddit

OP hülyeséget írt. Elsőnek ott van, hogy keveri az osztályt a metódussal. Aztán ott van az is, hogy egy osztály interface-ét szerintem nem szokás absztrakciós rétegnek nevezni. Arról már nem is beszélve, hogy ha valami olyan változik metódusok belsejében, ami szétcseszi a külső hívásokat, akkor azon önmagában egy interface, vagy "absztrakció" nem segít. Azt is alakítani kell, és ha a programozó arra nem figyelt, hogy a refaktor ne nyírja ki a külső hívásokat, akkor elég sanszos, hogy az interface kiigazítására sem figyelt volna. Persze, abban igazad van, hogy a library felhasználója elől el kell rejteni a belső implementációs részeket, mert a részére az nem releváns, viszont az itt felvetett kérdést az önmagában még nem oldotta volna meg.

[-]

csirkelab@reddit

Mi az api facade ez?

[-]

OgreAki47@reddit (OP)

Hehe. Annak kell patterneket tanulnia, aki nem tudja magától feltalálni őket :)

[-]

Matyas_K@reddit

Válts szakmát kérlek! De akármennyi abstraction layert csinálsz egy idő után akkor is lesz braking change.

[-]

OgreAki47@reddit (OP)

Ugyan miért váltsak, ha értelmesebben állok hozzá, mint egy fontos library maintainere?

[-]

Original_Chocolate65@reddit

20+ éve Delphi (object pascal) -ban párat. Utána API-t csináltam párat.

[-]

tonyxforce2@reddit

Ettol en sztrokot kaptam

[-]

_Nyswynn_@reddit

örülök hogy nem csak én éreztem a stroke jeleit olvasás közben...

[-]

Able-Bag4178@reddit

tl;rd: sz\*r

[-]

IConsumeThereforeIAm@reddit

Jó hát lehet op 12 éves

[-]

harylmu@reddit

Szerintem total erthetoen irta le mondjuk.

[-]

multiseven@reddit

godzilla is sztrokot kapott ettol

[-]

MoonLandingActor@reddit

Ajjaj

[-]

Pleasant_Resolve5678@reddit

![gif](giphy|jfE4SoAmsKppuPxTia)

[-]

nalevi1797@reddit

Időnként azt a bizonyos absztrakciós rèteget is refaktoralni kell általában. Jól gondolod, hogy törekedni kell ennek az elkerülésére, de idővel mindenhol megtörténik az ilyen, amit széleskörűen, éveken at használnak és fejlesztenek.

[-]

IConsumeThereforeIAm@reddit

Igen, egy normálisan megírt library az egy black box, publikusan dokumentált interfésszel. Ha jól van felépítve és az interfészhez készült specifikáció is jó, akkor nem csak refaktorálni lehet, de akár komolyabb architekturális változásokat is el lehet rejteni az interfész mögött, anélkül hogy a user ebből bármit érzékelne.