Plan for the week

1. Plan for the week • Working in groups/teams, horrible bosses? • How do you get to be better at this? • Programming Principles, e.g., Open/Closed • Android and Beyond • Design pattern examples and explanations • Android and beyond • Fragments and Android specific concepts • All Android

3. Working as part of a group see McCarthy, Dynamics of Software Development • establish a shared vision • what is quizmaster? what can we add? • harmonious sense of purpose • develop a creative environment • the more ideas the better, ideas are infectious • Don't flip the BOZO bit, everyone contributes • scout the future • What's coming, what’s the next project • What new technologies will affect this project

4. Scheduling/Slipping (McCarthy p 50) • anything you need to know about a team can be discovered by examining the software and vice versa (ola: do I believe this?) • leadership is interpersonal choreography • greatness results from ministrations to group psyche which is an “abstract average of individual psyches” • mediocrity results from neglect of group psyche

5. Scheduling/Slipping (pp 124-145) • Slipping a schedule: no moral dimension • No failure, no blame, inevitable consequence of complexity • Don't hide from problems • Build from the slip, don't destroy • Hit the next milestone, even if redefined (“vegetate”) • Does this have a place in 290/308? • What does it mean to be late? How should we and you deal with this?

6. Quizmaster Code Walkthrough • Let's look at some places in code that perhaps could be re-factored, re-designed • In light of stage one • In light of what might be stage two • Should you design/build for stage two? • Open/Closed, Loose Coupling, High Cohesion • See new principles: tell, don't ask

7. Code review

8. Tell, Don't Ask • Tell objects what you want them to do, do not ask questions about state, make a decision, then tell them what to do (Pragmatic Programmers, LLC) • Think declaratively, not procedurally • Don't ask for a map, then walk through the map • Instead of iteration, apply to all • Breaks when we don't want to apply to all • Rules are made to be broken • Reduce coupling, better code

9. Law of Demeter • Don't talk to objects, don't call methods. The more you talk, the more you rely on something that will break later • Call your own methods • Call methods of parameter objects • Call methods if you create the object • Do NOT call methods on objects returned by calls List all = obj.getList(); all.addSpecial(key,getValue()); obj.addToList(key,getValue()); // ok here

10. Aside: ethics of software • What is intellectual property, why is it important? • what about FSF, GPL, copy-left, open source, • what about money • What does it mean to act ethically and responsibly? • What is the Unix philosophy? What about protection? What about copying? What about stealing? What about borrowing? • No harm, no foul? Is this a legitimate philosophy?

11. Implementation model user’s model worse better Software Design See Alan Cooper, The Essentials of User Interface Design • who designs the software? • Implementation is view of software developer, user's view is mental model, software designer has to bridge this gap • Example: copy/move files in a Windows/Mac environment, what’s the difference in dragging a file/folder between two folders on the same device and dragging between devices, e.g., c: to a:? Is this a problem? To whom? • Implications in QuizMaster: what's a quiz? A score?

12. Design patterns “... describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice” Christopher Alexander, quoted in GOF • Name • good name is a handle for the pattern, builds vocabulary • Problem • when applicable, context, criteria to be met, design goals • Solution • design, collaborations, responsibilities, and relationships • Forces and Consequences • trade-offs, problems, results from applying pattern: help in evaluating applicability

13. QuizMaster -- Abstract Factory? • https://en.wikipedia.org/wiki/Abstract_factory_pattern • Where do Quizzes come from? • Is the source of the quiz important? • Should MainActivity be aware of source? • Is there more than one kind of Quiz? • Number of answers? • Type of answer, e.g., text or image? • Not correct/incorrect, but wizardry, personality, dating?

14. QuizMaster: Quiz Interface? Proxy? • How to deal with multiple quiz types? • Is it the progression through questions? • Currently what part of the program does this? • What is current Quiz "interface"? • What are alternatives to getQuestion(index)? • How to redesign, test, deploy? • Who should track the score on the quiz • MainActivity? Quiz? Something different?

15. Bumper sticker CS Jon Bentley, More Programming Pearls • Optimization • The first rule: don't do it • The fastest algorithm can frequently be replaced by one that is almost as fast and much easier to understand -- Douglas Jones, U. Iowa • premature optimization is the downfall of many programs/designs -- William Wulf, UVA • the fastest I/O is no I/O, cf. The cheapest, fastest and most reliable components of a system are those that aren't there -- Nils-Peter Nelson, Gordon Bell

16. Managing Software • The first 90% of the code accounts for 90% of the development time, the remaining 10% of the code accounts for the other 90% of the development time-- Tom Cargill, Bell Labs • Plan to throw one away, you will anyhow -- Fred Brooks • If you plan to throw one away, you will throw away two -- Craig Zerouni • Prototyping cuts the work to produce a system by 40% -- Larry Bernstein, Bell Communications • Furious activity is no substitute for understanding • It’s faster to make a four-inch mirror, then a six-inch mirror than to make a six-inch mirror -- Bill McKeeman

17. Writing programs • Always do the hard part first. If the hard part is impossible, why waste time on the easy part? Once the hard part is done, you’re home free. • Always do the easy part first. What you think at first is the easy part often turns out to be the hard part. Once the easy part is done, you can concentrate all your efforts on the hard part. • Whenever possible, re-use, share, borrow, but do not steal code

18. Essential Design Patterns (by name) • MVC, aka Observer/Observable • Separate concerns, especially important for GUIs • Composite • Container is/contains Layout/View, File/Directory • Factory • Separate creation from class, install new creators

19. Essential Design Patterns (by name) • Proxy/Adapter • Stand-in with same interface, adapt interface as needed • Decorator • Is-a and Has-a, e.g., Filters and java I/O • Command • Function/request object, undoable action

20. Patterns continued • Singleton • Enforce single point of creation, conserve resources • Template method • Hooks filled in by sublcasses • Strategy • Human player, AI, change algorithm • Forces in a problem lead to solution via appropriate pattern • Should know what GOF is: gang of four

21. Loose Coupling: OO Design • We want classes to be loosely coupled • Independent of each other in that they interact via APIs • Changes in one class have minimal impact on other classes except via APIs and those should be changed infrequently • Applications and programs change • Minimize the "ripple" effect through the system

22. High Cohesion: OO Design • Classes capture one abstraction • Create more classes when you need them, don't be a class miser or misanthrope (word abuse) • Keep things simple, strive for simplicity • Don't use Swiss-army knife approach, one tool for one purpose • Loose coupling and high cohesion, goals for programming

23. Open Closed Principle • Classes and Programs will be changed … • Open to extension • Closed to modification • What does this mean? • If not modified, don't need to be re-tested on a Unit testing basis • Extension can be by design, by language features

24. SOLID OO design • Single Responsibility Principle • Open/Closed Principle • Liskov Substitution Principle • Interface Segregation Principle • Dependency Inversion Principle • We'll look at these in more detail, but these principles are in general widely accepted • Principles, not rules