1 / 23

Course information

Get information about the course, old exams, exam results with walkthrough, resit details, and report progress. Also, find details about the First Lego League event for student judges.

Download Presentation

Course information

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Course information • Old exam • Result and walkthrough • Resit • 30 november, 8.15-10.00 • Report • Should be under way‏

  2. 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

  3. TDD, Pair Programming, Stand-ups SRP, OCP, LSP, DIP, ISP W7 – Processes and Principles

  4. TDD – Uncle Bob’s 3 laws

  5. TDD - FIRST

  6. TDD – Red-Green-Refactor

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

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

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

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

  11. 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

  12. 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.

  13. OCP - example

  14. 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...)”

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

  16. 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 SetWidth(int width)‏ { _width = width; } public virtual void SetHeight(int height)‏ { _height = height; } } public class Square: Rectangle { public override void SetWidth(int width)‏ { _width = width; _height = width; } public override void SetHeight(int height)‏ { _height = height; _width = _height; } }

  17. LSP – example (cont'd)‏ [TestFixture] public class RectangleTests { [Test] public void AreaOfRectangle()‏ { 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.IsEqual(r.Width * r.Height,10); } }

  18. 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 low-level modules. Both should depend on abstractions. • Abstractions should not depend on details. Details should depend on abstractions.

  19. DIP - Good, bad, ugly

  20. 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

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

  22. 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

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

More Related