MSO Lecture 9. Wouter Swierstra (adapted by HP, AL) October 12, 2017

Transcription

1 1 MSO Lecture 9 Wouter Swierstra (adapted by HP, AL) October 12, 2017

2 2 BEFORE WE START... Some notes on Kahoot! nicknames: Normaal: Anneke, Bastiaan, Pieter, Sjaak, Ruud,... Funny: Jeroen Fokker, Sergey Sosnovsky, Mark Rutte, Angela Merkel, Edsger Dijkstra, NL naar WK, smiley faces,... Maybe funny: Bier, Flammenwerfer, Himmler, Panzerkampfwagen, Reichsführer SS,... Not funny: sexist, racist, offensive and other sorts of inappropriate stuff that I am not going to repeat

3 3 LAST LECTURE Design by contract How can we ensure our code is correct?

4 4 THIS LECTURE What is refactoring? What are unit tests?

5 5 APPLYING DESIGN PATTERNS So far, we have often considered the situation where we can start designing new software from scratch. In practice, this is uncommon you usually have to develop with existing systems. Does that mean that design patterns are not useful in practice?

6 6 ITERATIVELY IMPROVING DESIGNS You can still apply design patterns to existing software: to improve the internal structure; to facilitate testing; to pave the way for new features.

7 Refactoring (noun): a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behaviour. 7

8 8 CASE STUDY: REFACTORING A MOVIE RENTAL SYSTEM I want to cover a refactoring case study taken from the first chapter of Fowler s book. Starting with some poorly designed code, we will refactor this step by step.

9 9 STARTING SITUATION Customer statement() 1 * Rental daysrented:int * 1 Movie pricecode : int title : string

10 10 INITIAL CLASSES The Movie class defines three price codes as integer constants: CHILDREN = 0 STANDARD = 1 NEW = 2 The Rental class tracks the number of days a particular movie has been rented. Finally, the Customer class records a list of Rentals.

11 Question: What is wrong with 11 this code? STATEMENT COMPUTATION foreach (Rental v in rentals) { v_price = 0; switch (v.getmovie().getpricecode()) { case Movie.STANDARD : v_price = 3 euro * v.daysrented; break; case Movie.NEW : v_price = 5 euro * v.daysrented; break; case Movie.CHILDREN : v_price = 2 euro * v.daysrented; break; } totprice += v_price; pts++; if (v.getmovie().getpricecode()==movie.new); pts++; }

12 12 WEAK COHESION This fragment is computing the price of the rental and the customer points earned let s extract this into two separate methods.

13 13 EXTRACT METHOD foreach (Rental v in rentals) { v_price = calculateprice (v); totprice += v_price; pts++; if (v.getmovie().getpricecode()==movie.new) { pts++ }...

14 14 EXTRACT METHOD foreach (Rental v in rentals) { v_price = calculateprice(v); totprice += v_price pts = calculateearnedpoints(v,pts)... Note that we have to pass along enough information to compute the new running total of earned points in this example, we pass both the video v and current total points pts. But we can do even better...

15 15 GETTING RID OF TEMPORARY VARIABLES foreach (Rental v in rentals) { totprice += calculateprice(v); pts += calculateearnedpoints(v);... But should both these computations really be in the same loop? Wouldn t it be better to define separate getcharge() and getrenterpoints() methods?

16 16 GETTING RID OF SWITCHES switch (v.getmovie().getpricecode()) { case Movie.STANDARD : v_price = 3 euro * v.daysrented; break; case Movie.NEW : v_price = 5 euro * v.daysrented; break; case Movie.CHILDREN : v_price = 2 euro * v.daysrented; break; } Switches may cause maintenance headaches!

17 17 INHERITANCE We could define an abstract Movie class, with three subclasses but it would be even better to apply the Strategy pattern. Client Context Strategy computation(...) ConcreteStrategyA computation(..) ConcreteStrategyB computation(..) ConcreteStrategyC computation(..)

18 18 REFACTORING SAFELY It is all to easy to make mistakes or introduce bugs during refactoring. Big refactorings can be really complex. Question: What best practices can help refactor effectively?

19 19 REFACTORING Do not start refactoring complex code unless you have a good test suite how else will you know that refactoring hasn t changed a program s behaviour? Refactor in the smallest possible steps. Test after every step catching bugs earlier will make your life a lot easier.

20 20 WHY REFACTOR? Refactoring may be necessary to improve the software s design eliminating duplicate code, for example. Refactoring makes software easier to understand. Refactoring helps spotting bugs. Refactoring helps program faster.

21 21 WHEN SHOULD YOU REFACTOR? Rule of three. The first time you write something, just write it. The second time, wince at duplicate code. The third time, refactor. Refactor when you add a new feature. Refactor when you fix a bug. Refactor when you do a code review. There s no golden rule.

22 22 BAD CODE SMELLS Fowler identifies a list of bad code smells. These are not bugs, but symptoms in the source code that may indicate bad design, or the need for refactoring. Whenever you are programming, or doing a code review, knowing about bad code smells can help identify problems, before they become hard to fix. I ll try to cover a few here and give some examples.

23 23 BAD SMELL? temp_c1 = (5/9)*(temp_f1-32); temp_c2 = (5/9)*(temp_f2-32); temp_c3 = (5/9)*(temp_f3-32); avg_temp_c = (temp_c1 + temp_c2 + temp_c3) / 3;

24 24 DUPLICATED CODE temp_c1 = (5/9)*(temp_f1-32); temp_c2 = (5/9)*(temp_f2-32); temp_c3 = (5/9)*(temp_f3-32); avg_temp_c = (temp_c1 + temp_c2 + temp_c3) / 3; Remedy: introduce a method.

25 25 LONG METHOD int doit() {... // 500 lines of weakly cohesive gibberish... } This usually indicates on method is doing too much making it weakly cohesive (and hard to understand). Remedy: split into smaller, more cohesive methods.

26 26 LARGE CLASS public class TheSystem... // 1000 weakly cohesive methods... This indicates a class is doing too much making it weakly cohesive (and hard to understand). Remedy: split into smaller, more cohesive, loosely coupled classes. Besides code length, unspecific name choices for classes and methods may indicate bad smells.

27 27 TOO MANY PARAMETERS Result computeresult(databaseconnection db, UserQuery uq, ReceiptPrinter r, UserName name, CustomerReceiptHandler crh, SalesRegister register, CurrencyConverter cc, MovieDatabase mdb, CustomerIdNumber cin,...) This usually indicates that a method is trying to do too much weak cohesion!

28 28 ANTI-PATTERN: SHOTGUN SURGERY Suppose you want to make a change, for example, introduce a new kind of movie to the video store case study. But to do this, you need to update the existing software in many different places this is called shotgun surgery. If this is not an unusual modification, the software is poorly designed.

29 29 DIVERGENT CHANGE Suppose we have our Shapes in the CAD/CAM software again. Over time, we add colours to our Shapes, methods for modifying colours (increasing transparency, brightness, etc.). But we also add information about borders maybe sometimes the border should be dashed or dotted. As time goes on, each individual Shape object is less and less cohesive. Remedy: Introduce separate classes to handle colours and borders.

30 30 BAD SMELL? switch (v.getmovie().getpricecode()) { case Movie.STANDARD : v_price = 3 euro * v.daysrented; break; case Movie.NEW : v_price = 5 euro * v.daysrented; break; case Movie.CHILDREN : v_price = 2 euro * v.daysrented; break; }

31 31 SWITCH STATEMENTS switch (v.getmovie().getpricecode()) { case Movie.STANDARD : v_price = 3 euro * v.daysrented; break case Movie.NEW : v_price = 5 euro * v.daysrented; break case Movie.CHILDREN : v_price = 2 euro * v.daysrented } The responsibility for this computation is in the wrong place. Remedy: Add a method to the superclass (or introduce a Strategy).

32 32 COMMENTS Comments are a Good Thing, right? This should be a sweet smell, not a bad smell...

33 33 COMMENTS But if a method or objects needs lots of comments, maybe these comments are masking bad design. public void compute() { \\ This is a really complicated method \\ that shouldn't be changed. \\ It took me a long time to get right, \\ so DO NOT TOUCH IT!!!!!

34 34 BAD NAMES Excessively long identifiers: in particular, the use of naming conventions to provide disambiguation that should be implicit in the software architecture. SystemControllerHandlerFactoryComponent Excessively short identifiers: the name of a variable should reflect its function unless the function is obvious. z = h.getx() * i.gety() + k.getq(); Excessive use of literals: x = 3.14 * / 256;

35 35 FOWLER S REFACTORING CATALOGUE Every refactoring is described in a uniform format: The refactoring s name; A summary of what the refactoring does; The motivation explaining when to apply the refactoring (and when not to apply it). The mechanics giving a recipe of how to apply a refactoring. Finally, examples illustrating a refactoring.

36 36 EXAMPLE: INLINE TEMP Summary: You have a temporary variable that is assigned to once with a simple expression, and the temp is getting in the way of other refactorings. Replace all references to that temp with the expression. double baseprice = anorder.baseprice(); return (baseprice > 1000) Becomes: return (anorder.baseprice() > 1000);

37 37 EXAMPLE: INLINE TEMP Mechanics 1. Declare the temp as a constant and compile. This tests that it is really only assigned once. 2. Find all references to the temp and replace them with the right-hand side of the assignment. 3. Compile and test after each change. 4. Remove the declaration of the assignment of the temp. 5. Compile and test.

38 38 EXAMPLE: INLINE TEMP Motivation: (fragment from Fowler) The only time Inline Temp is used on its own is if you find a temp that is assigned the value of a method call. Often the temp isn t doing any harm and you can leave it there. If the temp is getting in the way of other refactorings, such as Extract Method, it s time to inline it.

39 39 INVERSES Many refactorings have a reverse refactoring as well. For example, Introduce explaining variable is the opposite of Inline temp. // base price - quantity discount + shipping return quantity * itemprice - Math.max(0, quantity - 500) * itemprice * Math.min(quantity * itemprice * 0.1, 100); Becomes: double baseprice = quantity * itemprice; double discount =... double shippingfee =... return baseprice - discount + shippingfee;

40 REFACTORING WITH VISUAL STUDIO 40

41 41 Finally, I want to give a quick overview of some other refactorings that Fowler identifies: Introduce parameter object Moving methods, fields, or attributes. Splitting classes Hiding delegates You might argue that these refactorings are on the level of design rather than code.

42 42 INTRODUCE PARAMETER OBJECT Methods with too many parameters are hard to call: processcustomerondate(date, isopen, age, hasdiscountcard, customerid) Perhaps it is better to reorganize this into: processcustomerondat(dateprofile, customerprofile) and introduce new objects dateprofile and customerprofile storing the associated data.

43 43 MOVING CODE Person name age street zipcode city housenumber... printaddress() Perhaps this class is becoming too weakly cohesive...

44 This is an example of the Extract class refactoring. 44 MOVING CODE Person name age address Address street zipcode city housenumber... printaddress()

45 45 Product name : String Coffee discount() Apple discount() If all subclasses support the discount method, shouldn t this be defined in the superclass?

46 46 Product name : String discount() Coffee Apple This is the Pull-up refactoring.

47 47 Product name : String drink() Coffee Apple Why should you define a dummy implementation for the drink method of the Apple class?

48 48 Product name : String Coffee drink() Apple It s better to apply the Pull-down refactoring.

49 49 REFACTORINGS IN ALL SHAPES AND SIZES There are lots of other kinds of refactorings: Extract a common superclass when several classes share the same attributes and methods; Introduce a new subclass of X, to distinguish a specific kind of X. Replace inheritance with delegation and visa versa....

50 50 REFACTORING LESSONS Refactoring helps keep code clean. Aim for self-documenting code: choose meaningful names; lift complex computations into separate methods; keep control flow simple;... When refactoring, take small steps and test all the time.

51 Software testing 51

52 Why test software? 52

53 53 WHY TEST SOFTWARE? Test software to try and break things to find bugs. Test that your software has been installed correctly. Test that code changes (new features or bug fixes) do not introduce new bugs. Test performance, security, usability, accessibility, or any non-functional requirements....

54 54 WHAT TO TEST? Acceptance testing test that the user accepts the final product; System testing test an entire system, before handing it over to end users; Integration testing test that different software components (that may have been tested individually) work together; Regression testing tests that run nightly to check for new bugs; Unit testing testing individual software units.

55 55 UNIT TESTING Unit testing is a method by which individual units of source code, sets of one or more computer program modules together with associated control data, usage procedures, and operating procedures, are tested to determine if they are fit for use.

56 56 UNIT TESTING Test one unit at a time; Don t test code that will not break, like getters and setters focus on the difficult parts. Tests are code too. Choose meaningful names (testsuccessfultransfer rather than test3); Avoid repetition; Organize tests, just as you would organize other code.

57 57 EXAMPLE: TESTING BANK ACCOUNT SOFTWARE BankAccount - customername : string - balance : double - isfrozen : bool + Debit(amount) + Credit(amount) + FreezeAccount() + UnfreezeAccount()

58 58 DEBIT IMPLEMENTATION public void Debit(double amount) { if (isfrozen) { throw new Exception("Account frozen"); } if (amount > balance amount < 0) { throw new ArgumentOutOfRangeException("amount"); } balance -= amount; }

59 59 CREDIT IMPLEMENTATION public void Credit(double amount) { if (isfrozen) { throw new Exception("Account frozen"); } if (amount < 0) { throw new ArgumentOutOfRangeException("amount"); } } balance += amount;

60 60 TESTING... Test that tricky functions compute the right thing but also test that exceptional cases get triggered! Tests are typically written using assertions. An assertion is passed a boolean expression; If the expression evaluates to True, nothing happens and the test passes; otherwise the assertion throws an error, and possibly reports debugging information.

61 A FIRST UNIT TEST public void DebitWithValidAmount() { double beginningbalance = 11.99; double debitamount = 4.55; double expected = 7.44; BankAccount account = new BankAccount("Mr. Walter White", beginningbalance); // act account.debit(debitamount); } // assert double actual = account.balance; Assert.AreEqual(expected, actual, 0.001); 61

62 public void DebitTriggerException { double beginningbalance = 11.99; double debitamount = 20.0; BankAccount account = new BankAccount("Mr. Walter White", beginningbalance); try { account.debit(debitamount); } catch (ArgumentOutOfRangeException e) { StringAssert.Contains(e.Message, "amount"); return; } Assert.Fail("No exception was thrown.") } 62

63 63 WHAT S MISSING? How would you check that no transactions can be done on frozen accounts? What other cases are missing? Is it good to have a the String Amount in both the test code and the original class? What about having duplicate setup code in every test?

64 HOW TO TEST? The Assert class has a long list of basic assertions: compare two primitive types for equality; assert that a boolean must be true; check that an object is not null; fail; inconclusive. The CollectionAssert class provides various assertions about generic collections. The StringAssert class provides assertions related to strings: Contains(String,String) StartsWith(String,String) EndsWith(String,String) Matches(String,Regex) Various exception classes for when an assertion fails, when a test fails, when a test expects an exception to be thrown, etc. 64

65 65 TESTING IN VISUAL STUDIO There is pretty good unit test support in Visual Studio. You can generate a unit test framework for a class with a few clicks; Automated tools for running tests and showing code coverage; Help in writing stubs/mock classes; And lots more...

66 66 UNIT TESTING COMPLEX SYSTEMS Suppose you need to test a complex system that interacts with a database. Querying the database takes a long time and is complex to set up. Besides, I don t want my tests to corrupt my data. How do I write unit tests?

67 67 STUBS, FAKES, AND MOCKS Stub objects always return the same response; Every database query returns the same result. Fake objects behave correctly, but have a simplistic implementation; A fake database object has a list of data base entries stored as a C# list. Mock objects also test that its calls satisfy constraints. The mock database knows about the database schema and also tests that queries are valid.

68 68 UNIT TESTING: BEST PRACTICES 1. Make sure your tests test one thing and one thing only. 2. Write unit tests as you go. Preferably before you write the code you are testing against. 3. Do not unit test the GUI. 4. Separate your concerns. 5. Minimise the dependencies of your tests. 6. Mock behaviour with mocks.

69 69 TEST-DRIVEN DEVELOPMENT With the rise of Agile methodologies, Test-driven development has gained a lot of traction in the past years. 1. Start the iteration by writing tests. 2. Add code that makes the tests pass. 3. Refactor your solution. Sometimes summarized as red-green-refactor. Question: What might the benefits of this approach be?

70 70 BENEFITS OF TDD It forces developers to think about specifications first. Strongly coupled or weakly cohesive code is hard to test. Writing tests first encourages better design. Tests are not an afterthought. The end of the iteration may encourage developers to skimp on writing tests. Machine-checked documentation for free Code is more robust against refactoring later.

71 71 MATERIAL COVERED Refactoring. Martin Fowler. Verifying Code by Using Unit Tests. MSDN. Available online.