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. 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?
Implementation model
user’s model
worse
better

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?
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 Optimization The first rule: don't do it
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 Template method Strategy
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