CSC323 2010S, Class 05: Object-Oriented Design and Analysis Overview: * Beautiful Code, Chapter 4: Finding Things. * What is Object-Oriented Analysis and Design? * Some Discussion Questions. Admin: * No Beautiful Code for Thursday. Just read chapters 2 and 3 of Head First OOA&D. * One question should suffice, although two would be nice * You can assume that if I don't respond to your emailed questions, you got a check on them. * I do expect that you'll try to read code and that you can use Google. * Apologies: Snow delays and related matters are putting me a bit behind. * EC for today's Health Fair. * EC for Thursday's convo. * EC for Thursday's Thursday extra. * EC for Friday's CS Table. Beautiful Code 4: Finding Things * Problem Domain * Amazingly general: Searching for stuff in large files * More specific: Analyzing Web files * Which posts are popular * Who is reading the stuff? * Who does the most reading? (Probably google) * What does the solution look like? * Use regular expressions to identify useful entries * Put stuff in a hash table / associative array / dictionary * Sometimes binary search provides a better alternative * Primary Theses * Regular expressions are awesome * Binary search is cool and fast. Use it. * A well-designed language can let you write compact code quickly to solve problems * For a lot of search problems, you should first try simple solutions: * Use binary search * Use dictionaries * Use binary search if dictionaries don't give you enough speed * Only if that fails, try something more complex * Secondary Theses * We have tradeoffs between programmer time and program time * Sometimes it's not worth it to spend time optimizing * A bit of profiling can be useful to help you decide * The language makes a difference. Sometimes something that's easier to program in makes much slower code. * Sometimes code we believe to be correct (and that lots of people believe to be correct ) isn't mid = (lower + upper)/2 vs. mid = (lower + upper) >>> 1 * What is beautiful? * Ruby * Regular expressions * Binary search * What is ugly? * What is confusing keys_by_count = counts.keys.sort { |a, b| counts[b] <=> counts[a] } * What are the questions you ask when choosing a sorting routine? * Correctness. Don't use sorting routines that are not correct. * Running time: Asymptotic worst case, For the particular data I have, experimental * Are there characteristics of my data that make it better or worse * Memory overhead / in-place? * Stability - What do you do if A and B are equal? * In stable sorts: If A preceded B in the input, A will precede B in the output. * In unstable sorts: We have no such guarantee Object-Oriented Design and Analysis * What are the defining characteristics * Programs are composed of objects that interact with each other * Objects group data (fields, attributes) and capabilities (methods, procedures) * Objects send each other messsages; methods respond to messages * In many object-oriented languages, objects are members of classes * ENCAPSULATION * A mechanism for grouping code and data together * Provides a mechanism for protection / limited access * Reduces the fallout when you change stuff * Objects can maintain consistent state (we can help ensure that characteristics are met) * Purpose: Ideally, a class serves just one primary function * INHERITANCE * We can define classes in terms of other classes * Provides us with a nice form of code-reuse: By default, the methods and fields of the superclass belong to the subclass. * POLYMORPHISM * The ability to write a procedure/method that can take a variety of objects as parameters, provided the objects have some characteristic * Often phrased as "we can treat an element of a subclass as an element of a superclass" (or ancestor class) * Significant code reuse * What are some goals of object-oriented programming? * A better way to think about some computing problems * Modeling * UIs * Code reuse * Extendable programs * We can reuse our objects/classes in new programs * We can add new classes/objects to our existing programs * Limit access and effect * A change in one place should not hurt others * How do we design and build good object-oriented programs? * That's one of the points of this class * The book (HFOOA&D) gives you a preliminary, three-point strategy * 1. Make sure it works correctly * 2. Incorporate some OO design principles * 3. Go for a maintainable, reusable design * Underlying ideas: * Start with something that works! Otherwise, you may get endlessly tangled in trying to build something beautiful. * Of course, that may mean that you end up rewriting everything. * In the end, the most important thing is that you satisfy the client. The client doesn't care as much about 2&3. * Does 2 imply 3? * Maybe if you follow all the rules * But often, there are competing factors * What else did you get from this chapter? * We regularly need to think about how to improve the code. * If you follow the three-step program, you'll have lots of opportunities to improve your code * Encapsulation can make the code more maintainable/extensible * Encapsulation can also lead to better overall design Discussion questions: * Why use iterators rather than a for loop? * Iterators are pretty * Iterators are likely to be faster for some data structures (e.g., a LinkedList) * Iterators are more general: If we change the underlying "set" representation, our code will still work * Why encapsulate GuitarSpec * Makes it easier to write search code * Avoids the horrendous misuse of a Guitar as a search pattern * A natural way to do OO design: Factor out the sharable parts * Robust vs. Fragile code * Fragile code works for the instance it is designed for, but is not easy to reuse and doesn't deal well with problems * Robust code is more adaptable and safer * Creating all the Enums leads to an increase in the number of files. It also means a lot of updating when we realize that we left something out. Is it worth it? * Yes: 4 * Any real project has dozens or hundreds of files anyway. * Ensures consistency. That way, we don't have the Stratocaster/Stratocastor problem. * If they want to add to the types of guitars the hire, they have to hire us for updates. * No: 2 * The computation savings is not much. Why mess things up? * The user shouldn't be doing the input anyway. * And we can tell them when they can't spell. * You shouldn't have to update the system to add a new class of wodd (or whatever) * Maybe: 3 * We haven't heard anything about the UI, and that's really what's at issue. * The programmer time issue * What do they mean by 'these guitars have too many strings'? * It's a joke, dammit! * Rick sells more than just Guitars, and it seems to me like the GuitarSpec should be a subclass of something like InstrumentSpec. How would you design this better? * It depends on how much information can be shared between instruments. * May allow some code reuse. * May require us to do more coding. Sam, why did you make us buy this book that makes Ravi's head hurt? * Other faculty had good luck with the book last time. * The really in-depth formal treatments make your heads hurt even more. * Matches the department's pedagogical philosophy: Active learning * Relatively cheap * Does a better treatment of a wide variety of issues than to many textbooks. (Just enough ___)