Regole e princìpi e tecniche di programmazione

download Regole e princìpi e tecniche di programmazione

If you can't read please download the document

description

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

Transcript of Regole e princìpi e tecniche di programmazione

  • 1. Regole, princpi e tecniche di programmazioneRegole e princpi applicabili programmazione Orientata agli Oggetticon esempi in C#Andrea Colleoni - 2011

2. Princpi (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: Dont Repeat Yourself / Duplication Is Evil (Single Source OfTruth) YAGNI: "You aint gonna need it se una funzionalit non serve, inutileaggiungerla Le entit progettate devono essere APERTE per lestensione e CHIUSEper la modifica 3. Princpi (2) Rasoio di Occam (correlato anche al KISS principle): la soluzionepi semplice solitamente la migliore Principio di Pareto: spesso l80% dei fenomeni dovuto al 20%delle cause Legge di Demetra (disaccoppiamento): ogni oggetto devecomunicare SOLO con: Se stesso I propri parametri Gli oggetti che ha creato Gli oggetti figli Principio della minore conoscenza: A component should take onno more knowledge about another than is absolutely necessary toperform an inherent concern. Principio del minor privilegio: classi e metodi devono essere il piSTATICI e il pi PRIVATI possibile Principio di sostituzione di Liskov: una sottoclasse deve esserecompletamente e trasparentemente sostituibile alla suasuperclasse Complessit ciclomatica: la profondit del branching (nesting) 4. Princpi: 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. Princpi: esempi (2)public struct CoOrds Struct: crea un Value Type{ Quando passato a d un metodopublic int x, y;viene copiato Non ha costruttore di defaultpublic CoOrds(int p1, int p2) {x = p1; y = p2;}} Ereditariet Abstract: consente di non fornirepublic class Alimplementazione{ Virtual: dichiara la possibilit di fare public A()loverride {} Sealed: dichiara la volont di arrestare }la catena dellereditariet (non pu public class B : Aquindi essere abstract){ public B() { } New: pu servire per nascondere un }membro di una super classe Lestensione riguarda UNA SOLA classeconcreta 6. Override e New: esempio// Define the base classCar 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. Princpi: 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. Princpi: 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. Princpi: esempi (5) Principio di sostituzione di Liskovpublic class ElectricDuck : IDuckpublic interface IDuck{{ public void Swim()void Swim();{} if (!IsTurnedOn)return;//swim logicpublic class Duck : IDuck}{} Client Codepublic 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 implementazioniCambio Swim() indi Duck si comportano ElectricDuck perdiversamente Ha un problema rispettareOpen/Closed: tutti i client linterfaccia devono cambiare 10. Memento: design di classiSingle responsibility principleS SRPthe 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 principlethe notion that objects in a program should be replaceable withL LSPinstances of their subtypes without altering the correctness of thatprogram. See also design by contract.Interface segregation principleI ISP the notion that many client specific interfaces are better than onegeneral purpose interface.Dependency inversion principlethe notion that one should Depend upon Abstractions. Do notD DIPdepend upon concretions.Dependency injection is one method of following this principle. 11. Refactoring Quando i princpi precedentemente esposti sono violati il codicesorgente va rifattorizzato Obiettivi generali sono il perseguimento dei princpi; in sintesi sidevono perseguire i princpi dellOOP 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 unprogetto 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 ReuseThe granule of reuse is the granuleREPEquivalency Principleof release.The Common Closure Classes that change together areCCPPrinciplepackaged 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 DependenciesThe dependency graph of packagesADPPrinciple must have no cycles.The Stable DependenciesSDP Depend in the direction of stability.PrincipleThe Stable AbstractionsSAP Abstractness increases with stability.Principle 13. References [McConnell]: Steven McCollen - Code Complete2 edition - http://www.cc2e.com/ [GoF]: Gamma, Erich; Richard Helm, RalphJohnson, and John Vlissides (1995). DesignPatterns: Elements of Reusable Object-OrientedSoftware. Addison-Wesley [Fowler] Fowler, Martin (2002). Patterns ofEnterprise Application Architecture. Addison-Wesley