I principi S.O.L.I.D. – OSP

Il secondo principio S.O.L.I.D. è OSP che riporta “A software module/class is open for extension and closed for modification“.

Questo principio, afferma che nuove funzionalità possono essere aggiunte alla nostra classe/funzione, solo al momento che ce ne sia la reale necessità. Una volta terminati gli unit test sulla classe, non sarà più possibile modificarla (se non per fixare eventuali bug). La modifica può avvenire solo utilizzando l’ereditarietà.

Continua a leggere I principi S.O.L.I.D. – OSP

I principi S.O.L.I.D.

Nell’ambito di un progetto di refactoring, mi sono imbattuto in codice mal organizzato e messo insieme tanto per funzionare: un bell’esempio di spaghetti code. Per poter riportare il codice ad un livello “umanamente” comprenbile e gestibile nel tempo, non si può che ricorrere ai 5 principi S.O.L.I.D.

Trattati per la prima volta da Robert Martin, intorno agli anni 90, sono diventati un vero e proprio must per la programmazione e per il riutilizzo del codice.

S.O.L.I.D. è l’acronimo di :

  • S: Single Responsibility Principle (SRP)
  • O: Open closed Principle (OSP)
  • L: Liskov substitution Principle (LSP)
  • I: Interface Segregation Principle (ISP)
  • D: Dependency Inversion Principle (DIP)

SRP – “Every software module should have only one reason to change”

Il primo principio sostanzialmente può essere così riassunto: “ogni parte di codice (classe, funzione, ecc…) dovrebbe avere solo un compito da soddisfare”. Ovviamente non vuol dire che una classe debba contenere al suo interno un unico metodo o un unica proprietà, ma che le compentenze devono essere separate. Per poter soddisfare questo principio è sufficiente analizzare in fase di design tutti i metodi che coinvolgono la classe e quelli che possono essere estrapolati (non essendo parti necessarie), spostandole in altre classi o helper.

 

 

Linguaggi di programmazione: quante notazioni!

Utilizzando diversi diversi linguaggi di programmazione, sono differenti le notazioni che vengono utilizzate per assegnare nomi alle variabili, classi, costruttori ecc…

Ho provato a sintetizzare quelle più note.

Camel case: numberOfPeople
“La gobba del cammello”! Chiamata così perchè ogni parola intermedia inizia con la lettera maiuscola.

Kebab case: number-of-people
“come uno spiedino” ! Le parole sono separate dal carattere . Può essere utilizzata solo nei linguaggi di programmazione dove il carattere – non viene interpretato come sottrazione.

Snake case: number_of_people
come un serpente“! Le parole sono separate dal carattere _ .

Hungarian (Systems) notation: iNumberOfPeople
Si precede il nome della variabile con un carattere che indica il tipo della variabile (nell’esempio i indicata un intero)

Hungarian (Apps)) notation: cntNumberOfPeople
Si precede il nome della variabile con uno o più caratteri ad indicarne l’uso. Nell’esempio cnt rappresenta un contatore.

PascalCase notation: NumberOfPeople
Ogni nome e ciascuna parola all’interno inizia con una lettera maiuscola.

Ciascun linguaggio di programmazione utilizza la propria convenzione:

 

Di Javascript e amenità varie

Ho iniziato a programmare agli arbori del web e la connessione 56Kb era l’unico modo per accedere alla rete Internet. Netscape Navigator era il brower più diffuso al mondo e l’html non era certo quello di oggi. In questo scenario ecco comparire Javascript (o meglio ECMAscript) un linguaggio di scripting orientato al web. Continua a leggere Di Javascript e amenità varie