Download presentation
Presentation is loading. Please wait.
Published byAnnabelle Wilkins Modified over 6 years ago
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
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.