Your SlideShare is downloading. ×
Regole e princìpi e tecniche di programmazione
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Regole e princìpi e tecniche di programmazione

1,376
views

Published on

Regole e princìpi applicabili programmazione Orientata agli Oggetti con esempi in C#

Regole e princìpi applicabili programmazione Orientata agli Oggetti con esempi in C#

Published in: Technology

1 Comment
0 Likes
Statistics
Notes
  • Be the first to like this

No Downloads
Views
Total Views
1,376
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
19
Comments
1
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Regole, princìpi e tecniche di programmazione Regole e princìpi applicabili programmazione Orientata agli Oggetti con esempi in C# Andrea Colleoni - 2011
  • 2. Princìpi (1) Classi/Oggetti Information Hiding (incapsulamento) Ereditarietà e Composition over inheritance Design by contract: interfacce e polimorfismo  Identificazione di precondizioni, postcondizioni e invarianti  Asserzioni Defensive programming  Può essere perseguita tramite il Design By Contract Separation of concerns  Ogni classe deve avere UNA SOLA responsabilità  Ogni frammento di codice DEVE AVERE UNA SOLA GIUSTA POSIZIONE dove può essere collocato DRY / DIE: Don’t Repeat Yourself / Duplication Is Evil (Single Source Of Truth) YAGNI: "You aint gonna need it“ se una funzionalità non serve, è inutile aggiungerla Le entità progettate devono essere APERTE per l’estensione e CHIUSE per la modifica
  • 3. Princìpi (2) Rasoio di Occam (correlato anche al KISS principle): la soluzione più semplice solitamente è la migliore Principio di Pareto: spesso l’80% dei fenomeni è dovuto al 20% delle cause Legge di Demetra (disaccoppiamento): ogni oggetto deve comunicare SOLO con:  Se stesso  I propri parametri  Gli oggetti che ha creato  Gli oggetti figli  Principio della minore conoscenza: A component should take on no more knowledge about another than is absolutely necessary to perform an inherent concern. Principio del minor privilegio: classi e metodi devono essere il più STATICI e il più PRIVATI possibile Principio di sostituzione di Liskov: una sottoclasse deve essere completamente e trasparentemente sostituibile alla sua superclasse Complessità ciclomatica: la profondità del branching (nesting)
  • 4. Princìpi: esempi (1) Incapsulamento Auto properties (NB: campo privato inaccessibile)public string Name { get; set; } Properties (rimane accessibile il campo)private string _name;public void setName(string value) {}public string getName() {}
  • 5. Princìpi: esempi (2) public struct CoOrds Struct: crea un Value Type {  Quando è passato a d un metodo public int x, y; viene copiato  Non ha costruttore di default public CoOrds(int p1, int p2) { x = p1; y = p2; } } Ereditarietà  Abstract: consente di non fornire public class A l’implementazione {  Virtual: dichiara la possibilità di fare public A() l’override {}  Sealed: dichiara la volontà di arrestare } la catena dell’ereditarietà (non può public class B : A quindi essere abstract) { public B() { }  New: può servire per nascondere un } membro di una super classe  L’estensione riguarda UNA SOLA classe concreta
  • 6. Override e New: esempio// Define the base class Car car1 = new Car();class Car car1.DescribeCar();{ System.Console.WriteLine("----------"); public virtual void DescribeCar() ConvertibleCar car2 = new ConvertibleCar(); { car2.DescribeCar(); System.Console.WriteLine("Four wheels and an engine."); System.Console.WriteLine("----------"); } Minivan car3 = new Minivan();} car3.DescribeCar();// Define the derived classes System.Console.WriteLine("----------");class ConvertibleCar : Car{ public new virtual void DescribeCar() { Car[] cars = new Car[3]; base.DescribeCar(); cars[0] = new Car(); System.Console.WriteLine("A roof that opens up."); cars[1] = new ConvertibleCar(); } cars[2] = new Minivan();}class Minivan : Car foreach (Car vehicle in cars){ { public override void DescribeCar() System.Console.WriteLine("Car object: " + vehicle.GetType()); { vehicle.DescribeCar(); base.DescribeCar(); System.Console.WriteLine("----------"); System.Console.WriteLine("Carries seven people."); } }}
  • 7. Princìpi: esempi (3) public class A Plimorfismo { public virtual void DoWork() { }  Consente di trattare usare un oggetto } public class B : A come se fosse del tipo della sua { public override void DoWork() { } superclasse/interfaccia } public class C : A { public override void DoWork() { } } A x = new A(); A y = new B(); A z = new C();
  • 8. Princìpi: esempi (4) Legge di Demetra : Principle of Least Knowledge public class Paperboy public class Customer public class Wallet { { { decimal fundsCollected; public Customer() : this(null) { } public Wallet(decimal money) public Paperboy() public Customer(Wallet wallet) { { { Money = money; Customers = new List(); Wallet = wallet; } } } public decimal Money { get; set; } public List Customers { get; set; } public Wallet Wallet { get; set; } } // ... } } public decimal MakePayment(decimal amount)public void CollectPayments() {{ if (Wallet.Money >= amount) // Paper costs $2.00 { decimal payment = 2m; Wallet.Money -= amount; foreach (Customer customer in Customers) return amount; { } if (customer.Wallet.Money >= payment) return 0m; { } customer.Wallet.Money -= payment; decimal payment = customer.MakePayment(charge); fundsCollected += payment; if (payment != 0m) } { } fundsCollected += payment;} }
  • 9. Princìpi: esempi (5)  Principio di sostituzione di Liskov public class ElectricDuck : IDuckpublic interface IDuck {{ public void Swim() void Swim(); {} if (!IsTurnedOn) return; //swim logicpublic class Duck : IDuck }{ } Client Code public void Swim() { void MakeDuckSwim(IDuck duck) //do something to swim { } if (duck is ElectricDuck)} ((ElectricDuck)duck).TurnOn(); void MakeDuckSwim(IDuck duck) duck.Swim(); { } duck.Swim(); } Diverse implementazioni Cambio Swim() in di Duck si comportano ElectricDuck per diversamente Ha un problema rispettare Open/Closed: tutti i client l’interfaccia devono cambiare
  • 10. Memento: design di classi Single responsibility principleS SRP the notion that an object should have only a single responsibility. Open/closed principleO OCP the notion that “software entities … should be open for extension, but closed for modification”. Liskov substitution principle the notion that “objects in a program should be replaceable withL LSP instances of their subtypes without altering the correctness of that program”. See also design by contract. Interface segregation principleI ISP the notion that “many client specific interfaces are better than one general purpose interface.” Dependency inversion principle the notion that one should “Depend upon Abstractions. Do notD DIP depend upon concretions.” Dependency injection is one method of following this principle.
  • 11. Refactoring Quando i princìpi precedentemente esposti sono violati il codice sorgente va rifattorizzato Obiettivi generali sono il perseguimento dei princìpi; in sintesi si devono perseguire i princìpi dell’OOP  Aumento di astrazione  Incapsulamento, Generalizzazione di Tipo, Uso di Strategy, Sostituzione di branching con plimorfismo  Suddivisione in frammenti piccoli  Estrazione di metodi, Estrazione di classi  Collocazione e denominazione  Spostamento e/o Rinomina di campi, proprietà metodi, PullUp e PushDown Code review: è la disamina sistematica del codice sorgente di un progetto  Non deve essere fatto da chi ha scritto il codice originario  Può essere aiutato da sistemi automatici di analisi statica del codice (e.g. StyleCop, SourceMonitor, etc.)  Va fatta periodicamente e la presenza di questa attività deve essere prevista nel processo di sviluppo
  • 12. Memento: namespacesI primi tre principi riguardano la cohesion del namespace, ci dicono cosa inserire(e per contro, cosa non inserire) in un namespace: The Release Reuse The granule of reuse is the granuleREP Equivalency Principle of release. The Common Closure Classes that change together areCCP Principle packaged together. Classes that are used together areCRP The Common Reuse Principle packaged together.Gli altri tre riguardano i couplings tra namespaces, e metriche che valutano lanaming structure del sistema. The Acyclic Dependencies The dependency graph of packagesADP Principle must have no cycles. The Stable DependenciesSDP Depend in the direction of stability. Principle The Stable AbstractionsSAP Abstractness increases with stability. Principle
  • 13. References [McConnell]: Steven McCollen - Code Complete 2° edition - http://www.cc2e.com/ [GoF]: Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides (1995). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley [Fowler] Fowler, Martin (2002). Patterns of Enterprise Application Architecture. Addison- Wesley