SOLID,Code Smell, Problem Solving Flashcards
Quali sono i principi del Pattern SOLID?
S Single responsability Principle
Una classe dovrebbe avere un unico motivo per cambiare e quindi una sola responsabilità
O Open Close Principle
Una qualsiasi entità software(classe, modulo, funzione) dovrebbero avere meccanismi che permettono di estendere il comportamento senza apportare modifiche al codice preesistente
APERTO alle estensioni CHIUSO alle modifiche
L Liskov Substitution Principle
Le classi derivate devono sempre poter essere sostituite dalle classi da cui queste derivano (Superclassi)
I Interface Segregation Principle
Una classe client non dovrebbe dipendere da metodi che non usa e che pertanto è preferibile che le interfacce siano molte.
Interfacce MOLTE con pochi metodi.
NON poche con molti metodi
D Dependency Inversion Principle
una classe dovrebbe dipendere da atrazioni e non da implementazioni
Quali sono gli 8 più comuni Code Smell?
1. Poor Names
- NON troppo corti, NON troppo lunghi
- Significativo
- Si deve capire l’intenzione
- Scelto dal problema del dominio
2. Parametri dei metodi
- Meno di 3 parametri, o meno possibili.
3. Variabili
- Chiamarle con un nome che richiami specificatamente il motivo del loro utilizzo.
4. Evitare numeri magici
- Se un numero si ripete o è costante dichiararlo in una variabile
- Se sono pochi dichiarare degli Enum
5. Istruzioni condizionali troppo annidate
- if,else, if, if, if
6. Duplicazione di codice
- don’t repeat your self ,se il codice si ripete è opportuno creare una funzione.
7. Commenti
- Non scrivere commenti, riscrivi il tuo codice che sia intuitivo e leggibile
- NON scrivere nei commenti COSA fà.
- Spiega PERCHE’ e COME
8. NON Metodi lunghi
- Vogliamo che i metodi siano specializzati IN UN UNICA COSA.
- Principio di coesione: Queste cose sono corelate? allora devono stare assieme altrimenti non dovrebbero
- Single responsability principles: Una classe o un metodo devono saper fare una cosa soltanto e la deve fare fatta bene.
- Devono essere corti, non più di 10 linee di codiceù
- Devono fare un unica cosa!
Come dovrebbe essere un modello di pianificazione per risolvere un problema?
Creare una pianificazione esempio:
- Problema: Descrizione del problema
- Descrizione della funzione:
- Input: che dati entrano
- Vincoli (deve essere maggiore di ma minori di ecc..)
- Output: cosa deve uscire
- Esempio di come deve uscire output
- Cosa abbiamo fatto.
Cosa DEVE fare uno sviluppatore per risolvere un problema in modo efficente durante il lavoro?
Capire
- Capire bene cosa ti viene chiesto.
- Fondamentale è la raccolta di informazioni, più informazioni importanti abbiamo, più facile sarà capire il problema che abbiamo.
- Analizzare e estrarre informazioni concrete che abbiamo facendoci delle domande
- Cercare di spiegarlo, cosi facendo vedi i buchi nella logica che magari prima non avevi visto
- Lascia tempo al tuo cervello di elaborare le informazioni
Pianificare
- Raccolte le informazioni, elencare e scrivere le ipotesi
- Se il problema non è complesso o piccolo. organizza la tua soluzione, creando un MODELLO DI PIANIFICAZIONE
- Se la logica è complessa, organizzare i passaggi e le procedure in modo coerente in un Diagramma di attività (vedi immagine).
- Siate sempre consapevoli se state in pilota automatico o se state veramente risolvendo il problema.
- Con le informazioni raccolte, scrivere una soluzione logica,in pseudo codice.
Dividi
- Suddividi il problema in sottoproblemi DIVIDI e CONQUISTA
- Usa una TODO LIST
Bloccato
- Debug: vai passo passo nella tua soluizione cercando di capire cosa è andato storto.
- Rivalutare: L’ arte del debug è “capire cosa hai veramente detto al tuo programma piuttosto che ciò che pensavi di aver detto di fare”.
- Ricerca: trova chi ha gia risolto quel problema.