SOLID,Code Smell, Problem Solving

Question 1

Quali sono i principi del Pattern SOLID?

Answer 1

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

Question 2

Quali sono gli 8 più comuni Code Smell?

Answer 2

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!

Question 3

Come dovrebbe essere un modello di pianificazione per risolvere un problema?

Answer 3

Creare una pianificazione esempio:

1. Problema: Descrizione del problema
2. Descrizione della funzione:
3. Input: che dati entrano
4. Vincoli (deve essere maggiore di ma minori di ecc..)
5. Output: cosa deve uscire
6. Esempio di come deve uscire output
7. Cosa abbiamo fatto.

Question 4

Cosa DEVE fare uno sviluppatore per risolvere un problema in modo efficente durante il lavoro?

Answer 4

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.