Course information Old exam Resit Result and walkthrough

Course information Old exam Resit Result and walkthrough 30 november, 8. 15 -10. 00 Report Should be under way

Helt irrelevant för kursen First Lego League 5 studenter sökes som domare Programmering av legorobotar 10 -15 -åringar 7 november 09. 00 -15. 00 Molkoms högstadium (Nyed) 100: -/h www. hjernekraft. org

W 7 – Processes and Principles TDD, Pair Programming, Stand-ups SRP, OCP, LSP, DIP, ISP

TDD – Uncle Bob’s 3 laws

TDD - FIRST

TDD – Red-Green-Refactor

Pair Programming Always code in pairs Switch driver/co-driver Switch pairs Knowledge spread

Stand-up meetings Short and time-boxed What have I done What will I do Problems

SRP (Single Responsibility Principle) A class should only have one reason to change Cohesion How focused a class is

Example - RBS Who should know the price of a room/catering item/piece of equipment? Domain vs storage

OCP (Open-Closed Principle) Software entities (classes, modules, functions, etc. ) should be open for extension, but closed for modification Existing clients should not have to care about future improvements Future improvements should be possible Abstration is the key Refactoring

OCP (cont'd) "Open For Extension" - It is possible to extend the behavior of the module as the requirements of the application change (i. e. change the behavior of the module). "Closed For Modification" - Extending the behavior of the module does not result in the changing of the source code or binary code of the module itself.

OCP - example

OCP - Bertrand Meyer “A module will be said to be open if is still available for extension For example, it should be possible to add fields to the data structures it contains, or new elements to the set of functions it performs” “A module will be said to be closed if is available for use by other modules This assumes that the module has been given a well-defined, stable description (the interface. . . )”

LSP (Liskov Substitution Principle) “What is wanted is something like the following substitution property: If for each object o 1 of type S there is an object o 2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o 1 is substituted for o 2, then S is a subtype of T. [Liskov 88]“ Subtypes must be substitutable for their base types [Uncle Bob]

LSP - example public class Rectangle { protected int _width; protected int _height; public int Width { get { return _width; } } public int Height { get { return _height; } } public virtual void Set. Width(int width) { _width = width; } public virtual void Set. Height(int height) { _height = height; } } public class Square: Rectangle { public override void Set. Width(int width) { _width = width; _height = width; } public override void Set. Height(int height) { _height = height; _width = _height; } }

LSP – example (cont'd) [Test. Fixture] public class Rectangle. Tests { [Test] public void Area. Of. Rectangle() { Rectangle r = new Square(); r. Width = 5; r. Height = 2; // Will Fail - r is a square and sets // width and height equal to each other. Assert. Is. Equal(r. Width * r. Height, 10); } }

DIP (Dependency-Inversion Principle) Making your applications loosely coupled by not depending on concrete classes when appropriate, but abstractions High-level modules should not depend on lowlevel modules. Both should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions.

DIP - Good, bad, ugly

DIP – good for reuse Low-level modules are already being reused Buttons and other graphical objects Lists and other containers High-level modules are harder to reuse DIP helps reusing higher modules Decoupling from details

ISP (Interface Segregation Principle) Clients should not be forced to depend on methods that they do not use Related to cohesion

ISP - Example ATM Deposit Withdraw Transfer 3 different uses of the system 3 different interfaces You don't want to see stuff with no relevance

ISP – Example 2 IRS Kau Artist Name Personal number Income Name Pnr Grades