Aquesta setmana ja ens enfilem cap a mitjans de desembre, i amb aquesta publicació ja són 27 setmanes seguides i gairebé 6 mesos des que vaig començar amb aquesta afició. Fa temps havia tingut diversos blogs i escrivia en alguns portals, però el format newsletter el trobo més pròxim i directe. Si tens alguna suggerència, no dubtis a escriure’m a hola@vermutech.com o al nostre canal de Telegram.
Aquesta setmana hem fet el dinar de Nadal, un moment molt esperat per tothom; hem gaudit d’un bon menjar, bona companyia i tot tipus de converses divertides.
Començo amb algunes recomanacions,
💾 Programari
Markitdown, una eina amb Python que et permet convertir documents Office a Markdown. Perfecte per automatitzar conversions i fer la vida més fàcil a les persones que treballen amb documentació tècnica.
🤔 Curiositats
El meu color favorit és “Chuck Norris”! En aquest article pots descobrir què passa si com a estil CSS escrius “chucknorris”. M’encanten aquestes mandangues de l’HTML. És innecessari però divertit! 🤩
📦 Recursos
Un article fascinant que explica el framework de documentació Diátaxis. No és cap eina ni llibreria, sinó un conjunt de bases per estructurar una documentació de qualitat. Molt recomanable per a qualsevol projecte!
🌟 El concepte
Continuant amb els principis de disseny SOLID, aquesta setmana ens enfoquem en la Segregació d'Interfícies. Si en el número anterior vam parlar del principi de Substitució de Liskov, avui veurem com la segregació d’interfícies ens ajuda a evitar interfícies massa grans i complexes que poden dificultar el manteniment i l’escalabilitat del codi.
La Segregació d'Interfícies
Aquest principi estableix que cap classe no hauria d'estar obligada a implementar mètodes que no fa servir. Això implica que és millor tenir moltes interfícies petites i específiques en lloc d’una única interfície gran que cobreixi múltiples funcionalitats.
Exemple pràctic
Imagina que tenim una interfície Vehicle que defineix mètodes com arrencarMotor(), aturarMotor() i volar(). Ara bé, què passa si implementem un cotxe? No té sentit que un cotxe implementi el mètode volar(), ja que no li correspon. Això genera codi innecessari i poc clar.
Seguint aquest principi, seria més adequat dividir Vehicle en interfícies més petites, com ara MotorVehicle i FlyingVehicle, assegurant-nos que cada classe només implementi el que realment necessita.
Què vindrà al següent número?
En el pròxim número tancarem la sèrie SOLID amb la Inversió de Dependències, un principi clau per desacoblar mòduls d’alt i baix nivell mitjançant abstraccions. Si vols saber com assegurar que el codi sigui flexible i adaptable als canvis, no t’ho perdis
💖 Feedback
Si t’ha agradat i em vols ajudar, fes arribar aquest contingut a qui creguis que li pot interessar, i entra al canal de Telegram per comentar la publicació.