Writing good C# code for good cloud applications

1. Writing good C# codefor good cloud applications
2014 Edition
Marco Parenzan

2. WARNING
This document is currently in draft and many aspects have to be refined!
Marco Parenzan

3. Marco Parenzan
Formazione & Divulgazione con 1nn0va
Microsoft MVP 2014 for Microsoft Azure
Formazione & Progettazione con ITS Kennedy
Ricerca e Innovazione con Servizi Cgn
www.slideshare.net/marco.parenzan
marco [dot] parenzan[at] libero/live [dot] it
www.innovazionefvg.net
Developer e Architect in .NET e Web
CloudDeveloper
Lovesfunctionalprogramming
Some videogames for fun

4. Code and Modeling
Modeling is the activity of translating some requirements, results of an analysis activity
Code is a way to model «intentions» with «responsibilities» through a programming language
Modeling is the activity of undestandingand specificating“the real world”
Coding is the activity of representing the modeling activity in a software with a language

5. Cloud code
Cloud Computing is not a specific environment
CC encourages writing good code to improve Application Lifetime Management
CC require agile approach to coding because of an evolving context

6. C# code
C# is a statically typed, strongly typed language
That guarantees benefits in a modern development environment like Visual Studio
C# is a great language to write Domain-oriented code
C#, alone, does not guarantee a writing a good application, without some other principles

7. C# code
The evolution of C#
•C# 1.x (.NET 1.0 –VS2002/3)
•C#2.0 (.NET 2.0 –VS2005)
•C#3.0 (.NET 3.5 –VS2008)
•C#4.0 (.NET 4.0 –VS2010)
•C#5.0 (.NET 4.5.1 –VS2012)
•Roslyn
•C#6.0 (.NET 4.5.2 –VS2014)
2.0
Modeling
1.x
Managed Code
3.0
Functional
4.0
Dynamic
5.0
Asyncronous& Parallel
6.0
Roslyn

8. The path through modeling
Domain
We speak about a business (domain) and we need to represent things in business as code
Imperative
Write what is in your mind (that will live in your mind forever!). No one will understand what you have written 
Intention and Responsibility
Why are you coding? Which is the intention inside every line you write?

9. The path through modeling [2]
Object Modeling
Classes are the way to describe model into a domain
Functional Modeling
Declare you intention first! not implement it!
Contract Modeling
Class is not just encapsulation. It’s also declaration of a contract

10. The path through modeling [3]
Interface Modeling
Class should be implementation only. Interfaces are a better way to describe a contract
Blueprints for objects: patterns
Feel free to express yourself…or not? Please refer to some work done by experts!

11. Domain Modeling

12. Principles
Domain Model DrivesDesign.
Focuson Model of the Domain, rather than Technology
Domain Model is a Backboneof a Domain Language
Speak a Ubiquitous Language within a boundedcontext
UbiquitousLanguageused in all project aspects
discipline
understanding

13. Domain (Driven Design)
Domain
A sphere of knowledge (ontology), influence, or activity. The subject area to which the user applies a program is the domain of the software.
Model
A system of abstractions that describes selected aspects of a domain and can be used to solve problems related to that domain.
Ubiquitous Language
A language structured around the domain model and used by all team members to connect all the activities of the team with the software.
Context
The setting in which a word or statement appears that determines its meaning.

14. Ubiquitous Language
Common Language given by domain experts for describing system entities.
Model based language.
Structured around the domain model and used by all team members to connect all the activities within a bounded context.
Universal vocabulary that can be used in every aspect of the project (diagrams, source code, documentation, discussions and correspondence).
May include concepts that are not currently computerized.
Consistent logical model and a shared glossary of terminology.
Starting point for more detailed analysis.
Validates I.T. understanding of the business domain and its concepts.
The vocabulary of that UBIQUITOUS LANGUAGE includes the names of classes and prominent operations
The LANGUAGE includes terms to discuss rules that have been made explicit in the model and model relationships.
The model-based language should be used among developers to describe not only artifacts in the system, but tasks and functionality. This same model should supply the language for the developers and domain experts to communicate with each other, and for the domain experts to communicate among themselves about requirements, development planning, and features. The more pervasively the language is used, the more smoothly understanding will flow
Vocabulary has to be continuously refined.
Domain experts use it in discussions with developers.
Areas of model inadequacy quickly discovered. (where model seems wrong to the domain expert).
Developers and domain experts walk through scenarios, using model objects to deepen each other's understanding and refine concepts as they go

15. Domain Types
Abstraction
A domain that models the real BUSINESS domain
Technology
A domain that models the technology specific parts of a domain
Common
A domain that models the common parts between many abstractions
Host
A domain that contains the deployment parts of an application, coordinating all the other domains

16. Domain Model
Extracts domain essential elements, relevant to a specific use.
Layer of abstractions representing selected aspects of a domain.
Contains concepts of importance and their relationships in a certain domain.
Not concerned with physical data storage or processing.
May include concepts that are not currently computerized.
Consistent logical model and a shared glossary of terminology.
Starting point for more detailed analysis.
Validates I.T. understanding of the business domain and its concepts

17. Avoid abig, unified, centralizedmodel
They have to freely evolve separately

18. Bounded Context
Multiple models are in play on any large project. ... It is often unclear in what context a model should not be applied.
…Explicitly set boundaries in terms of team organization, usage within specific parts of the application, and physical manifestations such as code bases and database schemas
Not distracted or confused by issues outside
Youhaveresponsibilityonlyinside yourBoundedContext, notoutside

19. Domain Bounded Context
Different models apply in different contexts.
Same entity appears in different contexts with different shapes.
Context boundaries are a set of conditions (business functionality -application layer –database).
Model shall be strictly consistent within a specific bound.
Bounded contexts are not modules.
A bounded context can enfold other bounded contexts.
Name of a bounded context is part of the Ubiquitous Language
Explicitly define the context within which a model applies. Explicitly set boundaries in terms of team organization, usage within specific parts of the application, and physical manifestations such as code bases and database schemas. Keep the model strictly consistent within these bounds, but don't be distracted or confused by issues outside.
A BOUNDED CONTEXT delimits the applicability of a particular model so that team members have a clear and shared understanding of what has to be consistent and how it relates to other CONTEXTS. Within that CONTEXT, work to keep the model logically unified, but do not worry about applicability outside those bounds. In other CONTEXTS, other models apply, with differences in terminology, in concepts and rules, and in dialects of the UBIQUITOUS LANGUAGE. By drawing an explicit boundary, you can keep the model pure, and therefore potent, where it is applicable. At the same time, you avoid confusion when shifting your attention to other CONTEXTS. Integration across the boundaries necessarily will involve some translation, which you can analyzeexplicitly.
The names of the BOUNDED CONTEXTS will themselves enter that LANGUAGE so that you can speak unambiguously about the model of any part of the design by making your CONTEXT clear

20. Seeing same thing differently
Different bounded contextsor use cases may have different perceptionsabout the same physical entity.
Different perceptions may be complementaryor contradictory.
Depending on their goals in interacting with the elephant, the various blind men may still be able to make progress, even if they don't fully agree on the nature of the elephant. If no integration is required, then it doesn't matter that the models are not unified. If they require some integration, they may not actually have to agree on what an elephant is, but they will get a lot of value from merely recognizing that they don't agree. This way, at least they don't unknowingly talk at cross-purposes

21. Seeing same thing differently
Complementary perceptions:
Common parts Shared kernel
Each context extends (inherits/aggregates) the core part and enrich it with his own perception.
Parts of a larger whole
Common parts Shared kernel
Contradictory perceptions:
Bounded contexts doesn’t accept each other’s model
Nothing to share in common Agree on not to agree (Separate Ways)
Something to share in common Adapt to each other (Context Map)

22. StronglyTyped, StaticallyTyped
Ifyoudecide EARLY whata classcan do, you:
Are explicitin yourintention
Allowtoolshelpingyouon yourwork
Stronglytyped
Typedeclarean intention, aboutdeclarationand usage
StaticallyTyped
Help compilerensureyourintention, basedon declarationand usage

23. Imperative Modeling

24. We start with a problem to solve…
…typically with a divide and conquer technics
In traditional programming, we figure out how to break the problem into smaller parts, then each part into smaller parts still…with an emphasis on doing.
In the object-oriented approach we then try to figure out what objects the system has, what their responsibility is, and how they interact
Alec Sharp, Sharp, “Smalltalk By Example”, page 10, McGraw-Hill, 1997

25. Imperative Programming
http://en.wikipedia.org/wiki/Programming_paradigm
imperative programming is a programming paradigm that describes computation in terms of statements that change a program state
No assumptions are done…
…where state is…
…who can change state…
…protect state…
Focus is on statements
Origin of algorithms
Evolution of Von Neumann model (not so different from Machine Language, Assembly model)
The notionof algorithm!
Express howto do…what?
Youexpress the single linesof code withoutexplainingthe intention

26. How do youorganizestatements?
Youorganizestatementsthroughgroupingblocksof statements
Creatingdistinctblocksof statementsmeansencapsulation
Encapsulationisrepresentedby givingthisblocka name
Namereflectsintentionof the blockto the state
Whatisa «good» encapsulation?
Isa state thatisusedonlyfrom a single, encapsulated, blockof code

27. ResponsibilityModeling

28. Intention
An intention is a piece of code with a role (in your entire code)
Less roles (best: one!) better is the intention
So you need many intentions!
“Why have you wrote that code?”
“Which was your intention?”

29. Tell, don’tAsk
Procedural code gets information then makes decisions.
Object-oriented code tells objects to do things.
Alec Sharp, Sharp, “Smalltalk By Example”, page 67, McGraw-Hill, 1997
Smalltalk, where objects born…

30. “Any intention has a consequence”
Are you responsible about your intention?

31. Encapsulation
Encapsulationisassigninga nameto an intention
A programin a (un)orderedset of intentions
More detailedisthe nameof the intentions, betteristhe result
Lessdetailedare intentions, more work isfor you

32. WhyEncapsulation
Givea Name(«definea message») to an ability
From the implementerPoint of View
Invokea Name(«senda message») to askfor an ability
From the consumer Point of View
Encapsulationhasan importantconsequence

33. Encapsulationin OOP
Encapsulation, inheritance, and polymorphism are the three pillars of object- oriented programming.
Encapsulation is the packing of dataand functionsinto a single component.
The features of encapsulation are supported using classes. It allows selective hidingof properties and methods in a class by building an impenetrable wall to protect the code from accidental corruption.
In programming languages, encapsulation is used to refer to one of two related but distinct notions, and sometimes to the combination thereof:
A language mechanism for restricting access to some of the object's components.
A language construct that facilitates the bundling of data with the methods (or other functions) operating on that data.

34. Give me some examples of encapsulated intentions!
Good
CreateAnOrderForCustomer
CalculateTotalAmountToPay
GenerateSummaryReport
Bad
CreateAnOrderWithTotalForCustomerAndGenerateSummaryReport

35. Responsibility
The intentionisa boundaryof responsibility
Responsibility has many definitions. For example:
A responsibility is an obligation to perform a task or know informationhttp://en.wikipedia.org/wiki/Responsibility-driven_design#objects

36. Responsibilityfor what?
Program «calculate» a result
A resultisa fact, butisnotalways«instantly» calculated
A resultisthe end of a «path» thatgoesthrougha «state» thatchangesasprogramgo on
In mathterms, sequenceof valuesmust «converge» to the result
Wrongmanipulationof state (values) createsside effectsand arrivalto a wrongresult
Responsibilityisthe guaranteeof the intentionof correctstate management to arriveto correctresult
How do youdescribethe responsibility? Throughcode

37. It’snotyourresponsibility!
The problem is that, as the caller, you should not be making decisions based on the state of the called object that result in you then changing the state of the object.
The logic you are implementing is probably the called object’s responsibility, not yours. For you to make decisions outside the object violates its encapsulation.
Telljust “what you want to do”
Don’t asksomething (state) so you can decide

38. It’s all about“Handling Complexity”

39. C# code
Assembly
•Assembly is unit of distribution in .NET
•It’s a boundary!!!!
•A project in Visual Studio generate an assembly
•An assembly is a good container for a Bounded Context
•Assembly name corresponds to root Namespace in the form of <companyname>.<domainname>
•Contained namespaces are good to organize code by usage

40. C# code
Namespace
•Qualificano un insieme di classi sotto un unico nome contenitore
Nome COMPLETO della classe: nome del namespace + nome della classe
Livelli>1
Si definiscono in namespace {}
•Permettono di disambiguare classi con lo stesso nome
•È possibile usare sempre i nomi qualificati
•È possibile importare un namespace con la parola chiave using
Permette di definire alias sul namespace: using <alias> = <namespace>
<alias>.<nome classe>
Permette di definire alias sulla classe: using <aliasclasse> = <namespace>.<classe>
<aliasclasse>
•È possibile usare la parola using sia dentro che fuori del namespace
La differenza diventa “importante” nel caso nello stesso file ci siano più definizioni di namespace
Spesso non succede
•Esiste un “global” namespace

41. C# code
Static Classes
•Contengono solo metodi statici
•Non membri di istanza
•Serviranno per gli Extension Methods

42. C# code
Tipi primitivi
•I tipi primitivisonostrutturedefinite nelnamespace System
•È possibileusareilloronomeo illoroalias C#
Int32 i= 4;
intj;
j = i;
structure name
C# alias
bool
Boolean
char
Char
sbyte
SByte
byte
Byte
short
Int16
ushort
UInt16
int
Int32
uint
UInt32
long
Int64
ulong
UInt64
float
Single
double
Double
decimal
Decimal
Boolean
character
integer
floating point
same type so
can interoperate

43. C# code
An example: Int vs. Enum
•StateId model a state (in a Finite State Machine manner)
•StateId is int
•StateId (from model) can assume values as 1,2,3
•Int says all numbers are valid, from -231231-1
•What ensures StateId having 1,2,3 only?
You
Guard code (imperative)
Type (declarative)

44. C# code
Enum
•La parola chiave enum è usata per definire il nuovo tipo
Contiene un insieme di costanti simboliche
•È possibile definire variabili di un tipo enum, usando I valori definiti in essa
•Di default usa (implicitamente) il tipo int
È possibile fare il cast (esplicito) da/verso il tipo implicito
È possibile specificare un altro tipo primitivo (a parte char)
•È possibile assegnare dei valori diretti
È possibile modificare la sequenza dei numeri

45. C# code
Eccezioni
•Un’eccezione è un evento sincrono
È prevedibile il punto in cui può avvenire, non il momento
•Un’eccezione è un pattern utilizzato per notificare errori
•Un’eccezione può essere gestita con un blocco try…catch…finally
Try: blocco che può generare eccezione
Catch: blocco eseguito subito dopo all’istruzione nel blocco try che ha generato l’eccezione
Finally: blocco eseguito comunque dopo il blocco try e l’eventuale blocco catch
•Un’eccezione, per essere gestita dal blocco try prende forma di un oggetto che deriva dalla classe exception
•La notifica di un’eccezione si basa sullo stack
Un blocco try…catch…finally viene registrato nello stack
•Non è detto che un metodo che chiama un altro metodo che genera una eccezione debba “trappare” una eccezione
Viene fatto uno “stack walk” per trovare il primo blocco disponibile
Eventualmente quello di default fornito dal framework
•È possibile definire una eccezione derivando una nuova classe dal tipo Exception
Si usa l’istruzione throw per sollevare una nuova eccezione
•Ci sono delle eccezioni di uso comune

46. C# code
Delegate
•La parola riservata delegate serve a definire un tipo in grado di puntare a un metodo e gestire indirettamente la sua invocazione.
Possiamo vedere un delegate come un "puntatore a funzione“
•Garantisce che il metodo abbia una specifica firma
Lista ordinata dei tipi dei parametri formali
Non include il tipo di ritorno (ma due funzioni non possono distinguersi per il solo tipo di ritorno)
•Offrono la possibilità di chiamare un metodo (anche) in modo asincrono tramite BeginInvoke e EndInvoke
Un delegato ha dei metodi (è una classe)
<delegate>() è la sintassi contratta di <delegate>.Invoke()
•I delegati sono multicast
È possibile assegnare ad un delegate più puntamenti a metodi diversi
Un invocazione sul delegato implica la chiamata a tutti i metodi referenziati
•Vengono utilizzati principalmente per:
la gestione degli eventi
L’uso come callback (passare un metodo come “valore” ad un altro metodo)

47. C# code
Anonymous Methods
•Permettono di definire direttamente il codice dove è necessario un delegato
•Il tipo dei delegati viene automaticamente inferenziato (non serve istanziare esplicitamente il delegato, ma scrivere solo il corpo)
•I blocchi di codice possono accedere alle variabili locali
Non possono però accedere a parametri (di un metodo in cui sono definiti) ref o out
Ovvio, in quanto la loro esecuzione non è legata all’invocazione del metodo di definizione
•La vita delle variabili locali è “estesa” fino a che il delegato che le referenzia non è eligibile di garbage collection
Tutto è dovuto a generazione nascosta di classi

48. C# code
Lambda expressions
•Permettono di definire delle funzioni “inline”, associando direttamente un blocco di codice
•Permettono di creare un metodo “stand-alone” all’interno del codice (utilizzando gli anonymous methods)
•Sono un’ulteriore semplificazione rispetto l’uso dei delegate
•Dal calcolo lambda
x . x + 1
•In C# 3.0
x => x + 1
•Dalla sintassi delle anonymous functions
delegate(int x) { return x + 1;}
•Possono usare variabili implicitamente tipizzate
•Possono avere più di una variabile
•Il corpo può contenere espressioni o istruzioni

49. C# code
Extension methods
•È possibile aggiungere metodi a classi già definite
È possibile aggiungere metodi a classi già compilate, in assembly diversi
Non sono mixin (dai dynamic languages)
Sono “syntactic sugar”
Readability
•Solo metodi
Non per properties, events, operators (almeno per adesso)
•Metodi statici in classi statiche
La chiamata esplicita al metodo statico avviene sempre (e rimuove ambiguità)
Nel caso di sovrapposizione con metodi locali
I metodi locali hanno la precedenza
•L’inserimento degli extension method avviene al momento dell’importazione del namespace

50. C# code
Enumeratori
•Un enumeratore è un cursore read-only forward only
Permette di visitare una collezione di elementi
•Si basa su due interfacce
IEnumerator: l’enumeratore vero e proprio
IEnumerable: permette di richiedere ad una collezione un enumeratore per visitare la stessa
•Usato dal costrutto foreach

51. Object Modeling

52. Objects and Classes
Objects isa structurethatencapsulatesstate and behaviorthatevolve thatstate
Class isa mechanismto declarethe encapsulationof state and andbehavior
Class-basedlanguagesimplementstheseprincipleswith manyoptionson principleenforcement(strong, wake)
Note. Thereare alsootherparadigmsto defineobjects(ex. Prototyping, asfor Javascript)

53. C# code
Classes vs. Components
•Class is made up of (is the expression of an implementation)
variables
functions
•Component is made up of (is the expression of a contract)
Methods
Properties
Events
•Methods are functions
Intention of an action (theory calls them «messages»)
•Properties are syntactic sugar for special functions (accessors) around variables
•Events are special Properties
Notify the happening of an action

54. C# code
Reference Types
•Una qualsiasi dichiarazione di tipo fatta con la parola class indica un Reference Type
•Il riferimento è a una istanza di quel tipo
L’istanza viene creata con l’operatore new
Allocazione nel managed heap
•L’assegnazione tra variabili di tipo Reference implica la copia del riferimento, non dell’oggetto riferito
•Una variabile di un reference type accetta null
Invalida il riferimento
Valore di default per una variabile
Non distrugge l’oggetto (Garbage Collection)
Far riferimento ad una variabile null solleva una NullReferenceException
•Gli array e le stringhe sono reference types

55. C# code
Properties
•Le proprietà combinano la sintassi delle variabili membro con il controllo delle funzioni membro
Permettono di associare ad un nome (con un tipo) le due funzioni accessorie
•Syntactic Sugar
•Permettono di definire
Readonly properties
Guarded properties
Calculated properties

56. C# code
Eventi
•Un evento caratterizza un componente
Qualcosa che succede all’interno del componente e che lo stesso notifica
Un oggetto esterno può sottoscrivere l’evento per essere notificato quando succede
Un evento è una specializzazione di un delegato
•event è una parola chiave da associare ad una proprietà di un tipo delegato
•event impedisce l’uso dell’assegnazione (“=“) ma solo la sottoscrizione (“+=“) o la cancellazione (“- =“)
Il mancato uso dell’assegnazione impedisce ad un consumatore generico di rimuovere la sottoscrizione a qualche altro componente
•Qualsiasi delegato può essere usato per un evento
È convenzione usare un delegato del tipodelegate void <event handler>(object sender, <event args> e) dove <event args> è una classe che deriva da EventArgs
•È possibile creare una variabile membro di tipo evento
•È possibile creare una proprietà di tipo evento
Rispetto alle proprietà le funzioni accessorie sono add e remove

57. C# code
Generics
•Polimorfismo Parametrico
•Funziona sia con reference and value types
•Controllo dei tipi in fase di dichiarazione
No boxing (value types)
No downcasts (no object)
•Supporto completo a runtime
•Reduced code bloat
Non bisogna scrivere classi wrapper tipizzate

58. FunctionalCodingand Modeling

59. Imperative vs. Declarative
Imperative==(you) ASK to DO (yourself)
And youDON’T SAY whatyouneed
Declarative=(you) TELL to MAKE it DONE (by someone else)
You SAY what you need
You don’t know how it is done

60. DeclarativeCode
Describewhatyouwantto obtain(the result)
Thenthereisthe topicabout(howto obtain)
Itcan be thattool(the language, the compiler) can do thatwork or you
The mostcommon exampleof thisisSQL
FunctionalCode: a declarativeapproachsolvedusingfunctions

61. Functional
Youexpress the intentionon howstate change(relation before- after)
Youenforcethiswith invariants(valuesthatdoesn’tchange)

62. C# code
Some examples in C#
•If
Alternative (Option)
Guard
Constraints
•While
Loop
Aggregate
Map/Reduce
Recursion

63. C# code
Some examples [2]
•Int
Integer
Option
State
•Decimal
Fixed point
Currency
•Double
Scientific
Temperature
Conversion

64. C# code
Value Types
•Nel caso di local variables, parameters, loop counters, un programma ne può fare un uso intensivo
•Problemi
Allocazione
Accesso
Rilascio
•Uso dello stack
Allocazione e rilascio automatico
Accesso alla memoria efficiente
•I value types contengono i valori direttamente, non i riferimenti
•Int, char, byte, TimeSpan sono value types primitivi
•Se ne possono definire di custom tramite struct

65. C# code
struct
•Possono avere proprietà, metodi, costruttori, membri, implementare interfacce
•Non possono:
Ereditarietà per classe
Valori inizializzati alla definizione
Non possono avere un custom default constructor (senza parametri)
Un costruttore deve esplicitamente inizializzare tutte le variabili

66. C# code
Anonymous Types
•È una “tupla” le cui proprietà specifiche sono inferenziate tramite Object Initializer
•Viene fatto a compile time, quindi è sempre comunque statically/strongly typed
Internamente viene creata una classe nascosta
•var x = new {p1 = 10, p2 = “name”};
Il tipo di x è anonimo
Non è possibile referenziarlo “per nome” da codice
•structural type equivalence
Due tipi anonimi possono essere compatibili
Viene ricostruita la “compatibilità” a compile time
•Viene definito un solo nuovo tipo (anonimo)
La classe verrà generata automaticamente in fase di compilazione, e deriverà da System.Object
•implicitly typed arrays
var a = new[] { 1, 10, 100, 1000 };
Devono avere tipi compatibili
O conversioni implicite

67. C# code
Implicitly typed variables
•E’ possibile dichiarare le variabili in modo implicito, utilizzando la parola chiave “var”
var i = 5; var s = "Hello"; var d = 1.0; var orders = new Dictionary<int,Order>();
•Il tipo delle variabili è indotto dalla espressione che lo inizializza
DEVE INCLUDERE L’INIZIALIZZAZIONE
“var” non è variant o object
È comunque statically typed
•Non può essere null
•Var può essere usata SOLO nei metodi
Non può essere usata a livello di classe
Attenzione all’abuso
Bisogna capire il contesto dell’esecuzione per capire cosa c’è dentro
E’ possibile utilizzare la keywork “var” anche all’interno di cicli for e foreach

68. C# code
Object Initializers
•È possibileinizializzarevariabilimembroe proprietà, senza richiamare il costruttore in modo esplicito
new C(1, 2, name=“my class”);
Valgonole regoledi visibilità
È possibilefare annidamento
Initializzaregrafi
•Collection initializers
List<int> digits = new List<int> { 0, 1};
DeveimplementareSystem.Generic.ICollection<T>
•Object initializers
vara = new Point { X = 0, Y = 1 };

69. C# code
Autoimplemented Properties
•Permettono di specificare una proprietà senza doverne specificare il field privato
•Velocizza il processo di creazione di proprietà all’interno delle classi
•Il membro privato viene generato a compile-time
•Per vedere il nome del field privato generato, è necessario utilizzare ildasm.exe o Reflector.exe
•Non è possibile utilizzarle per specificare proprietà in read-only o write- only
E’ possibile limitare l’accesso al get o al set di una proprietà, specificandone la visibilità
•Non è possibile specificare un valore di default a causa del membro privato che non è presente
Nel costruttore della classe si può intervenire impostando il valore di default

70. C# code
Tipi parziali (Partial Types)
•È possibile spezzare una dichiarazione in più files
Utile quando c’è un designer/generatore di codice
Ottimo anche per organizzare il codice
Una partial class per ogni interfaccia implementata
•Tipi supportati
Classes (Partial Classes)
Struct
Interface
•Divisi a design time, “fusi insieme” a compile time

71. C# code
Partial Methods
•E’ stata aggiunta la possibilità di definire un metodo come “partial”
•Permette di definire un metodo in una parte della classe, e poterlo implementare in un’altra parte della classe
Utile in caso di uso dei generatori di codice
Non necessità di ereditarietà di metodi virtuali
•I metodi dichiarati come “partial” hanno delle limitazioni:
Devono essere definiti all’interno di una partial class
Devono sempre ritornare void
Possono avere argomenti, ma non con clausula “out”
Sono sempre implicitamente privati
•Se un metodo partial non viene implementato, questo non compare nel codice compilato (nemmeno la chiamata del metodo)

72. Contract Modeling

73. Typeasa Contract
Class Declarationisusefulto compilerduringcodingactivity
Compiler ensureclassesrespectingContractimplementation
Contractisexpressedin termsof Interface and Class members

74. Class Model=Contract
Everyclassexpresscompletlya contract
Whatisnotexpressedcannotbe in the contract
Everyclassimplementsa contract. Possibilities:
completly
partially
extendibly
nothing

75. Polymorphysm
Contractimplementationisnotlimitedto ONE IMPLEMENETATION
Contractcan havemultiple implementations(or POLY MORPHS)
Manyimplementantionsare differentto givedifferentperformances to the samecontract
Polymorphismisimplementedvia inheritance

76. C# code
Decorating contracts
•Statically typing and strong typing is a way to enforce intentions
•Methods can be decorated to better describe intentions
•Abstract: partial implementation
•Virtual: extendible implementation
•Sealed: complete implementation
•Public: contract
•Private: implementation
•Side effects
Protected: contract for inheritance implementation
Internal: contract for boundary implementation

77. Public and private
Public meanscontract
Private meansimplementation

78. Public and private definitions
Public classisa sharedcontract
Private classisan reservedimplementation
A private implementationassolve atthe end to a public contract
A contractcannotbe private!
Notshared
It’sunusefulan objectthatdoesn’thavea public function
A public implementationisa looseof encapsulationand responsibility

79. Completelyimplementa contract
A classthatcompletlyimplementsitscontractcan be instantiated
Side effect:
Languagesallowsa completlydefinedclassnotbeininstantiated
No factoryMethodsBah!
FactoryMethodsOK!

80. Partially implement a contract
Class must be inherited
Some implementationdetails are missing
Contractdetail are not missing
…to complete its implementation
Many “combination” of details can generate many implementations
Opportunity!
Side effect
Inheritance can extendcontract, not change!

81. Extendiblyimplement a contract
(partial) implementation of the contract can be extended
Extension is done through override
Side effect
Implementation can changethe behavior, not extend
Is a responsibility of the implementer
Language cannot ensure that
You are building a taxonomy

82. Polymorphysmimplementedvia Inheritance
Inheritanceisnotfunctionalto code reuse
Thereare manyotherways to reusecode
Inheritanceisfunctionalto Polymorphysm
Single inheritance, not multiple (only C++ has)
“..is a…” relation
Being
No ambiguities

83. Inheritanceisimplementationhiding
«Less(youknow) isbetter»
X isa classthatinheritsfrom A
Inheritancesays:
X «derivesfrom» A
X «is» A
X isableto do everythingA isableto do
X can do the work in placewhereA isrequested

84. Inheritanceisreuse
«Inheritanceisnotfunctionalto code reuse«
X and Y are twoclassesthatinheritsfrom A
X and Y can(notHAVE TO) extendcontract
X and Y HAVE TO do work in placewhereA isrequested, but…
…ifX and Y are use independentlyyoudon’tneedinheritance!

85. …writing a good contract…

86. Anemic Objects
Objects that contains just data, not behavior
This kind of objects have increased because of OR/M adoption
Business logic is just Entities manipulation, without any specification
Definition of object is not well defined if objects define the database or viceversa
Theseobjectsare typicallyserializable
ypicallythisobjecthaveno particulardependencies
Manyconsiderthisan anti-pattern!
http://www.martinfowler.com/bliki/AnemicDomainModel.html

87. Fluent Interfaces
Fluent interface become visible in objects that are made up of public “empty”-returning methods
Each method is an action that change/evolve object state
Consequent invocations of that method become an awful, unreadable code
The sequence of invocations is a sequence of states in which object evolve
Better expressed with a chain of invocations

88. Interface Modeling

89. Law of Demeter
The Law of Demeter tries to restrict class interaction in order to minimize coupling among classes.
What that means is that the more objects you talk to, the more you run the risk of getting broken when one of them changes
In fact, according to the Law of Demeter for Methods, any method of an object should only call methods belonging to:
itself.
any parameters that were passed in to the method.
any objects it created.
any composite objects.

90. CyclomaticComplexity
Cyclomaticcomplexity is a software metric (measurement). It was developed by Thomas J. McCabe, Sr. in 1976 and is used to indicate the complexity of a program. It is a quantitative measure of the complexity of programming instructions. It directly measures the number of linearly independent paths through a program's source code(http://en.wikipedia.org/wiki/Cyclomatic_complexity)
In allof ourtopics, «responsibility» isoneof ourstrategiesto lowercyclomaticcomplexity, closingdecisionsin lowerleversof the applicationtree
A lowCC:
Lower numberof defects, because…
…allowbettertestabilityof software

91. «SOLID» apps
An app is«SOLID» whenhandles«well» changesduringitslifetime
Maintainabilityhaveto be ourfirst focus
Appschangeand havenotto be rewritteneverytime thereisa new specification

92. SOLID Principles
S
SRP
Single responsibility principle “aclassshould have only a single responsibility (i.e. only one potential change in the software's specification should be able to affect the specification of the class)
O
OCP
Open/closed principle “software entities … should be open for extension, but closed for modification.”
L
LSP
Liskovsubstitution principle “objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.”
I
ISP
Interface segregation principle “many client-specific interfaces are better than one general-purpose interface.”
D
DIP
Dependency inversion principle one should “Depend upon Abstractions. Do not depend upon concretions.” Dependency injectionis one method of following this principle.

93. Coupling
Youhavetwoobjects, a and b, of typeA and B respectively
a «consume» b
Responsibilityimplieshowmucha knowsaboutb
Whatdoes«knows» mean?
Contract
Instantiation
Lifetime
Contract… isgood
Instantiationand Lifetime…are bad
Always?

94. Twodifferentsituations
A and B are classesfrom the sameDomain
Notso muchan issue
Probablyyouhavecontrol of the entireDomain
A and B comesfrom differentDomains!
THAT’S AN ISSUE!!!!!!

95. Class not implement a contract
Extreme condition for a class
Allmembersare abstract
Code-based inheritance for classes with all abstract members is wrong
At least, not so useful or a lost of opportunity
Use interfaces
Is an encapsulation of some method in a responsibility
Interface is declaration of some kind of responsibility
Interface implementationcan be implicitor explicit
Side effect
Multiple interfaces can violate SOLIDprinciples

96. C# code
Interface based inheritance
•Multiple inheritanceimplementation
•“…has a…” relation
•Having
No doubt

97. Inheritance, Interaces, Reflection and language
Inheritance is done via reflection
Is the invariant part of the state of an object
Implemented through v-tables
In C#, isoperator have to be used
Isoperator is statically typed, strongly typed
Reflection is runtime object introspection
Reflection “engine” is loosely typed, dynamically typed
Flexible…
…but not maintainable…

98. n-Tierlayeredarchitecture
A tierisa responsibilitycontainer
Tiers are «stacked»
A tiercommunicatewith twolayers, atmost!
Tier-2
Tier-1
Tier-n
…

99. n-Tier
A tierisa responsibilitycontainer
Tiers are «stacked»
A tiercommunicatewith twolayers, atmost!
Ok, notalwaystrue
Tier-2
Tier-1
Tier-n
…

100. n-Tierlayeredarchitecture
Concentrate domain code in one layer, isolated from user interface, application, and infrastructure code.
Clean separation of concerns keeps the design of each layer easy to understand, maintain and extend.
Domain objects (models and services) becomes focused on expressing the business domain.

101. Three Tier
Three isthe mostfamousstandardn-Tierconfiguration
How do tierscommunicateeachother?
Defineresponsibilitybetweenlayers
Haveresponsibilityfor «lower» layer
Consumeresponsibilityby «top» layer
Business Logic
Data Access
PresentationData

102. Contractsand Development Teams
«Three» teams can developindependently, iftheyagreeon Contracts
ContractDA/BL
ContractBL/P

103. Interfacesand Layers
Layerscommunicateeachothervia contracts/interfaces
Business Logic
Data Access
Presentation
ContractDA/BL
ContractBL/P

104. Instantiation
An objectiscreatedfrom classthroughinstantiation
Instantiationismemorymanagement…
Reservation(in stack)
Allocation(in heap)
Thatmemoryisorganizedasclassesdescribe

105. C# code
Factory Methods
•Classes are instantiated via new operator
•New has two problems
Highly coupling
Not delegable in case of non-default constructor with parameters
Impossible delegating new operator
•Patterns comes in help
Creational Patterns
A function/method that create an object
Physically separate (hide) new operator from outside

106. Lifetime
b isan objectand must be created
Whatcreatesb? Whenb iscreated?
a
a createsb internally
a hasa referenceto b
a hasto «destroy» b
Context(a)
Context(a) createsb
ahasreferenceto Context(a)
Context(a) hasto «destroy» b
a hasnotto «destroy» b

107. C# code
Singletons
•Singletons are single instances for single apps
•It’s a way to decouple global scope from language/technology specific contexts

108. C# code
Inversion of Control (IoC)
•What is «inverted»?
•Imperative: «I instantiate B to have b» (because I need b)
•Declarative: «I need b of type B»
Who can answer me?
If I need B and I receive BB, that derives from B, is the same, because BB is compatible with B
•So inversion is another aspect of declarative (and responsibility):
Declare your needs
Then
Find (actively declare)locator service
Ask (passively declare)autowiring

109. Decorating Contracts
Declareyourneed«outside» member
Around
Wecan say«notby code»
This is Aspect Oriented Programming
Program, atruntime, can inspectcode ifsome member(s) are decoratedwith an «aspect»

110. C# code
Attributi
•Permettono di associare metadati agli elementi di definizione di una classe (classe, metodo, variabile, proprietà, …)
•Sono informazioni disponibili a runtimetramite reflection
<object>.GetType().GetMember()
•Permettododi implementare algoritmi basati sulla struttura stessa della classe, decidendo in base agli attributi
Un esempio su tutti: serializzazione
•AtttributiStandard (dalla BCL)
•Attributi Custom
Classi derivate da System.Attribute
•Accessibili tramite Attribute.GetCustomAttribute(<memberinfo>)
•Sintassi:
[<attribute>Attribute(positionalparameters, namedparameters….)]

111. Blueprints for objects: patterns

112. Blueprints for objects: patterns
How do you use all these things?
How do you build up a class?
I’m the first that ever build an object?

113. Experience from many, notjust one
Manyhavecollectedexperiences
Experiencesare collectedaspatterns
Patternsgroupedby usage
Design Patterns
(Gandof our, Gamma et al)
http://en.wikipedia.org/wiki/Design_Patterns
Patternsof Enterprise Application Architecture
(Martin Fowler)
http://martinfowler.com/eaaCatalog/index.html
Object OrientedDesign
http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
Cloud Computing Patterns
http://www.cloudcomputingpatterns.org/
Domain DrivenDesign
http://en.wikipedia.org/wiki/Domain-driven_design

114. Experience from manydogmas from no one
All patterns are effective experience…
…for most of the “standard” situations!
Every situation have to be verified because many parameters can influence how to choose
Performances
Correctness

115. Inside a domain and a process

116. inside a domain and in a process
When we speak about objects for a biz, we refer tipicallyto a domain object
When we speak about objects, we talk about “in-memory” objects

117. You need to “name” some data. You need…
…an entity object
An Entity map all properties to columns into a table
An Entity has some columns that means “business key”
If an “int” or “long” key is used, we speak about “surrogate key”
An entity is an object that is recognized by an identity key
Two entity objects are equals if identity keys are equal
If two entity objects, with the same identity, but different values, are concurrent
Distinguished by its identity attributes.
Equal attribute values doesn’t indicate Identical objects.
Non equal attribute values doesn’t indicate Non Identical objects
Same real-world thing might / might not be represented as an entity in a domain model
Identity might / might not be of interest to the application user

118. You need to handle some data. You need…
…a value object
All single pieces are needed to identify data
A value object is an object that is identified by values tuple of its properties
Two objects are the same objects if of the same type and all values, by properties, are equal
Value object has no identity
Value object is identified by all its specific values
Value object cannot live outside another object
Describes the characteristics of a thing.
Represents a descriptive aspect of the domain with no conceptual identity.
Value objects can reference Entity objects
Value objects are interchangeable.
Value objects are immutable (name shouldn’t change in every person)
Usually found by traversal from some entity.
Finding a Value with specific properties = Creating a new instance with the same properties.

119. You need to track changes to entities. You need…
…a Unit of Work
A Unit of Work keeps track of everything you do during a business transaction that can affect the database. When you're done, it figures out everything that needs to be done to alter the database as a result of your work.
Contains original values copies of objects just after loaded
Undestandvalue changes and performs operations back to the db

120. You have to do prepare an Entity for the presentation. You need…
…a ViewModel
Is a model of an entity optimized for UI
No Database-like references
An entity object is not suitable for universal usage
No localization
Data already decoded
Data already loaded (if good to)
A ViewModelis typically an “pure” “language” object
Minimize(down to zero) needsof gettingotherdata from othersources

121. You have to consune a View Model in presentation. You need…
…a View
An object that get data from VieModeland put in the UI
How to put data in UI?
Explicit Copy values
Data Binding
A View is typically a “technology” object
It depends from a UI framework

122. You need to do some actions on a graph of entities. You need…
…an aggregate root
An object that excapsulatesall entities inside without exposing them outside (no ref for entities)
Aggregate Root is an entity object (called “root”) that guarantee consistency of the entity in the system
Exposes an API for acttionsto be perfomedon entities
No mixing between actions and queries
The aggregate root guarantees the consistency of changes being made within the aggregate by forbidding external objects from holding references to its members.
A cluster of associated objects treated as a unit for the purpose of data change
Has a root (Entity) and a boundary (defines what is inside)
Root entity has a global identity
Non-Root entities have local identity
Nothing outside the aggregate boundary can hold a reference to anything inside, except to the root entity
Only aggregate roots can be obtained directly with database queries.(other objects must be found by traversal of associations)
Root entity can expose references to the internal entities. Usage is only transient, and references shouldn’t be held
Objects within an aggregate can hold references to other aggregate roots
A delete operation removes everything within the aggregate boundary at once. (cascade delete)

123. You need to persist an aggregate. You need a…
…Repository Object
isolates domain objects from details of the database access code
A Repository mediates between the domain and data mapping layers, acting like an in-memory domain object collection
providing a more object-oriented view of the persistence layer

124. Outside process

125. Outside process or domain
Inside objects
When we speak about objects for a biz, we refer tipicallyto a domain object
When we speak about objects, we talk about “in-memory” objects
When we get out a domain, we can get out layers also…
…and we get many “non functional” aspect to handle
Serialization
Communication
Performances

126. You need to perform a “call” on a remote aggregate root, through boundaries
You need a command
Command object is a object that assert an intention to an action
All values assigned to properties specify parameters of the intention of the command
Typically, this kind of objects are flat (not complex)
Typicallythisobjecthaveno particulardependencies
If you have
<someobject>.DoSomething(args)
Model as
Class DoSomethingCommand{ public <args> }
Default constructor
Simple types

127. You need to handle requests from outside a domain. You need…
…a Service object
It avoids many details (implementation, lifetime, instantiation)
It’s just “contract”
Refer to an activity (verb) rather than an entity (noun).
Services are stateless.

128. You need to handle a request from outside process
A service objects have to be encapsulated inside a boundary that can handle a request
An objects that maps a request into an usable object
That objects is a Controller
The type of request shapes the type of object request is mapped on

129. You need some data to decide. You need…
…a Data Transfer Object
An object that carries data between processes in order to reduce the number of method calls (http://martinfowler.com/eaaCatalog/dataTransferObject.html)
An aggregate of information
A mono-directional object optimized for data presentation
Typically is a result of mapping of a generic query from a datasource

130. How can you obtain a DTO? You can use…
…a Data Source object
An object that prepare DTO for you
All different requests are already defined

131. You need to notify externally from an aggregate root that something has happened. You need…
…an event object
Event object is an object that notify execution of an action
All values assigned to properties define the keys to reach the context where action was executed
Typically, this kind of object is flat (not complex)

132. Writing good C# codefor good cloud applications
2014 Edition
Marco Parenzan