The University of Sydney Page 1 SOFT3202 Presented by Josh Burridge Lecture content in this unit has been developed by: Professor Bernhard Scholz Dr Basem Suleiman Josh Burridge Software Construction & Design 2 The University of Sydney Page 2 What are we doing today – Revising old design principles – Introducing new design principles – Discussing the analysis of code – Task 4 intro – Major Project discussion The University of Sydney Page 3 SOFT3202 Design Principles The University of Sydney Page 4 SOFT3202 – Design Principles SOLID – Single Responsibility Principle. – Open/Closed Principle. – Liskov Substitution Principle. – Interface Segregation Principle. – Dependency Inversion Principle. – Robert Martin’s “Agile Software Development, Principles, Patterns, and Practices” The University of Sydney Page 5 SOFT3202 – Design Principles GRASP – General Responsibility Assignment Software Patterns/Principles – Information Expert – Creator – Controller – Low Coupling (evaluative) – High Cohesion (evaluative) – Polymorphism – Pure Fabrication – Indirection – Protected Variations – Craig Larman’s “Applying UML and Patterns – An Introduction to Object-Oriented Analysis and Design and Iterative Development” The University of Sydney Page 6 SOFT3202 Design Principles – Let’s talk about some more The University of Sydney Page 7 SOFT3202 – Design Principles KISS – Keep It Simple Stupid, or Keep It Stupidly Simple – Make things as simple as possible, and no simpler The University of Sydney Page 8 SOFT3202 – Design Principles YAGNI – You Aren’t Gonna Need It – See https://martinfowler.com/bliki/Yagni.html – Refers not to design quality (you are gonna need that) – it refers to features The University of Sydney Page 9 SOFT3202 – Design Principles DRY – Don’t Repeat Yourself – Refers to more than just lines of code! The University of Sydney Page 10 SOFT3202 – Design Principles Single authoritative representation of data / Single Source Of Truth (SSOT) – DRY principle applied to knowledge/data – You should be able to change a single item of knowledge in one spot only, not have to repeat that change – http://wiki.c2.com/ DontRepeatYourself The University of Sydney Page 11 SOFT3202 – Design Principles Coupling, Cohesion, Connascence – Coupling –What ‘bits’ of your software depend on what other bits What talks to what What requires changing if you change something else The University of Sydney Page 12 SOFT3202 – Design Principles Coupling, Cohesion, Connascence – Cohesion – Are your bundles of ‘stuff’ coherent Are the methods in a class all acting on a common set of data in that class Does a class need to gather a bunch of info from outside itself to work Are the classes in a package working together to solve some broader common purpose The University of Sydney Page 13 SOFT3202 – Design Principles Coupling, Cohesion, Connascence – Connascence – A qualifier for ‘how coupled is coupled’ – Describes a hierarchy of coupling such that ‘how many lines between boxes’ on a UML diagram is broken down to actually how rigid this makes the system. – https://codesai.com/posts/2017/07/two- examples-of-connascence-of-position – https://dl.acm.org/doi/10.1145/130994.131 004 The University of Sydney Page 14 SOFT3202 – Design Principles Coupling, Cohesion, Connascence – Connascence The University of Sydney Page 15 SOFT3202 – Design Principles Law of Demeter – “Only talk to your friends” – How deep do your dependencies ‘dig’ – If A depends on B and B depends on C, then A depends on C – but how much – A calls B.getC().haveCdoSomething(); – A calls B.doSomething(); B calls C.doSomething(); – What is the connascence difference here The University of Sydney Page 16 SOFT3202 – Design Principles Prefer Composition Over Inheritance – http://wiki.c2.com/ CompositionInsteadOfInher itance – If a choice exists, inject dependencies to modify behaviour polymorphically rather than create a complex hierarchy – Make use of interfaces to specific behaviour The University of Sydney Page 17 SOFT3202 – Design Principles Program to Interfaces, not Implementations – Easier to mock – Easier to swap out – Better for interface segregation The University of Sydney Page 18 SOFT3202 – Design Principles Hollywood Principle – “Don’t call us, we’ll call you“ – Is at the core of OO rather than procedural design – Inversion Of Control – http://wiki.c2.com/ HollywoodPrinciple – https://www.youtube.com/watch v=zHiWqnT Wsn4 |if you watch any video this semester, make it this one) The University of Sydney Page 19 SOFT3202 – Design Principles – Consider this code: if (employee.employeeDepartment == “sales” && employee.employeeTenureInYears > thresholds.commissionRequiredTenure && employeeType == EmployeeTypes.SALARY) { The University of Sydney Page 20 SOFT3202 – Design Principles – Compare with: boolean employeeQualifiesForTenure = employee.employeeDepartment == “sales” && employee.employeeTenureInYears > thresholds.commissionRequiredTenure && employeeType == EmployeeTypes.SALARY; if (employeeQualifiesForTenure) { The University of Sydney Page 21 SOFT3202 – Design Principles Other simple things – Use descriptive variable names. The wider the scope, the more detailed the name – Keep functions SMALL – decompose them if they are big. – Keep classes SMALL – same here – Good design doesn’t live in the package level – it lives in the lines of code. It doesn’t matter how good your class structure is if your code inside is awful The University of Sydney Page 22 SOFT3202 Analysing Code The University of Sydney Page 23 SOFT3202 – Analysing Code – “You need to be twice as smart to read code as you are to write it” – Consequence: if you write code as cleverly as you can you will be half as smart as you need to be to read it afterwards – Clever code is bad code – it is hard to read. It is therefore hard to maintain and extend – Your job as a developer is to write the dumbest possible code that works (see KISS) The University of Sydney Page 24 SOFT3202 – Analysing Code – Dumb code can still be – Elegant – Idiomatic – Performant (to a point) – Dumb code that is well written is best. – Your job as a software developer is to write that dumb working code, and to do your best to keep it dumb even where there is pressure to make it ‘clever’ The University of Sydney Page 25 SOFT3202 – Analysing Code – Your job when analysing code for design is largely detecting cleverness where it shouldn’t exist – “Could it be simpler ” (common) – “Is it too simple ” (very rare) – “Does it work” (best question to ask first) The University of Sydney Page 26 SOFT3202 – Analysing Code – The part that makes this difficult is that very often a little cleverness in one spot is necessary to avoid a lot of cleverness somewhere else – Design patterns are mostly this little bit of cleverness – The trick lies in identifying whether they actually are avoiding cleverness, or just adding it The University of Sydney Page 27 SOFT3202 – Analysing Code Excerpt from your actual exam specification (more info in Week 13 lecture) – Feature Modifications Made: Describe the visible changes to your application from the perspective of a user running it, from the perspective of features which have changed/added/been removed, and any changes to the method the user accesses them. – Base Code Discussion: Describe the way your base code influenced your implementation of your extension. In particular highlight which aspects of your base code made your implementation easier or more difficult than it could have been. You should ensure you reference design patterns in this discussion, whether ones you used, or ones you did not. – Resulting code discussion: Describe the way your code has ended up after implementing your extension. In particular highlight what positive or negative impacts your extension has had on the maintainability, extensibility, and modularity of your code. The University of Sydney Page 28 SOFT3202 – Analysing Code – Exam: dynamic, your code has just changed – Task 4: static, you will be analysing code in-place – Key Criteria (for us – see https://en.wikipedia.org/wiki/List_of_system_qual ity_attributes): – Maintainability – Extensibility – Modularity – These contain every principle discussed today (and more) The University of Sydney Page 29 SOFT3202 – Analysing Code – Maintainability – Maintenance is a computer-aided process, but a human-driven one – Includes all forms of testing – Includes code readability, clarity, idiom, style, documentation – Includes how likely bugs are to develop, hide, recur through regression. The University of Sydney Page 30 SOFT3202 – Analysing Code – Extensibility – Deals with the addition of new features – How simple to add a new feature right now – How simple to add many new features over time – What potential for bugs in new code exists when adding new features Old code The University of Sydney Page 31 SOFT3202 – Analysing Code – Modularity – How decoupled and cohesive is the code – How reusable are the components – Is SRP and interface segregation being followed The University of Sydney Page 32 SOFT3202 – Analysing Code – Key: ‘analysing the software design’ is a massive undertaking and probably not very useful – Analysing an aspect of the software, or analysing a specific pull request (see: code reviews), or analysing the software in the context of a proposed change is far more useful The University of Sydney Page 33 SOFT3202 Task 4 The University of Sydney Page 34 SOFT3202 – Task 4 – Intended to help you with your exam report – Not to pull significant amounts of time away from your major project – Your task: to analyse the design of an existing piece of software and consider the impact of this design on a proposed new feature The University of Sydney Page 35 SOFT3202 – Task 4 – Overall steps: – Look at the code and understand it – Think about a potential change –Write about how the code design supports or inhibits this change – Handicap mode if required: – Actually make the change – Spend time you don’t really need to with the benefit of knowing more about the effects of the design The University of Sydney Page 36 SOFT3202 – Task 4 – The code: Glank/Java-Games/Tetris – Nothing special, not plucked out to show an example of great or terrible code, just something a) Written in Java b) Suitably complex without being overwhelming c) Not dependent on a bunch of obscure libraries – Seems likely to have been written while the author was a student or recently afterwards (developing a public code presence like this as a student is a great idea – we will talk about using your major project as a “look at what I can do” portfolio piece in the last lecture) The University of Sydney Page 37 SOFT3202 Major Project The University of Sydney Page 38 SOFT3202 – Major Project – Most of you will have had marks released – A small number are still waiting on marking – I will be sorting those out tonight – There are some good observations and some poor observations The University of Sydney Page 39 SOFT3202 – Major Project – There were some very impressive submissions in terms of UI/usability – I am anticipating some very nice pieces of software by the end of Week 13 – Consider the following for inspiration: The University of Sydney Page 40 SOFT3202 – Major Project The University of Sydney Page 41 SOFT3202 – Major Project – It usually looks like it takes a lot more work than it actually does to achieve something like this – JavaFX does most of the work for you – learn the tools of your trade, and use them properly – Many submissions were the flat grey default (not unexpected for Milestone 1, but please work on this for Milestone 2) The University of Sydney Page 42 SOFT3202 – Major Project – Design-wise there were some common issues: – Model logic in the view – Testing consequences – Lack of testing, or poor testing – Forgetting the most basic Java knowledge – Don’t ignore warnings –Generics: unsafe/unchecked = you are doing something wrong, FIX IT! – Basic code readability The University of Sydney Page 43 SOFT3202 – Major Project – Check Ed for more details about your API: filter to your API categories and read every post. Missing out on these discussions could cost you a lot. They are considered part of the specification. The University of Sydney Page 44 SOFT3202 – Major Project – Implementation & Design discussion
