Chapter 5: Good design = Flexible softwave

#OOAD

Transcript

1. Chapter 5: Good design = Flexible softwave
2. PART 1: NOTHING EVER STAYS THE SAME
3. Stringed instruments in Rick’s guitar is expanding - Fresh off the heels of selling three guitars to the rock group Augustana, Rick’s guitar business is doing better than ever—and the search tool you built Rick back in Chapter 1 is the cornerstone of his business. - He wants to do more Mandolin. => Improved Rick's Guitar application to support Mandolin.
5. The abstract base class • Abstract classes are placeholders for actual implementation classes. • The abstract class defines the behavior, and the subclasses implement that behavior. • An abstract class defines some basic behavior, but in reality: the subclasses of the new abstract class add the implementation of the behavior.
6. MandolinSpec class Mandolins and guitars are similar, but there are just a few things different about mandolins... we can capture those differences in a MandolinSpec class:
7. Behold: Rick’s new application Whenever you find common behavior in two or more places, look to abstract that behavior into a class, and then reuse that behavior in the common classes.
8. Class diagrams dissected (again) • Now that you’ve added abstract classes, subclasses, and a new kind of association, it’s time to upgrade your UML and class diagram skills.
9. Create an abstract class for instrument specifications • With the instruments taken care of, we can move on to the spec classes. We need to create another abstract class, InstrumentSpec, since so many instruments have common specifications:
10. Summary • By summarizing common properties and behaviors on the Instrument and InstrumentSpec classes, you create classes in Rick's application. • Adding new tools is not easy: If it's easy to change, it's how we determine whether our software is well-designed. Whenever we need to add a new tool, we have to add another subclass of Instrument • You almost always find a few new issues when you make major changes to your design and the use of these abstract classes has helped us avoid any code duplication.
11. PART 2: Give your software a 30- minute Workout
12. Back to Rick’s search tool With the new OO principles, we are ready to make Rick's application redesigned and more flexible. And what is the problem here?
13. A closer look at the search() method We have a problem with how we study Rick's client. We are going to make the InstrumentSpec class, but does that solve all the problems?
14. The benefits of our analysis • Take what we already know about turning InstrumenSpec into a specific class and see if it makes the software design better.
15. A closer look at the instrument classes • Although class search () is better, there are still some issues with subclasses, and the way addInstrument () in Inventory • Remember, we do abstract instruments because the instruments in them have subclasses.
16. All the instruments are the same. There are two reasons why each instrument has a subclass • Because the Instrument class is generally generic, not a particular instrument, it's an abstract one, so we should give each instrument a subclass. • Each instrument has different properties, from which there are InstrumentSpec subclasses, so we need a specific characteristic of each instrument.
17. Death of a design (decision) • Some of the hardest things that you will do is to let go of the mistakes you have made in your design. In Rick's search engine, it does not make sense to have separate layered classes for each instrument. • But it took them to 30 pages (and 2 parts of the chapter to find out) Why? => Because it is very difficult to change something when you are doing it. =>Code: one, look two (or more). • Design is a repetition, and we must be ready to change our design every moment needed and develop them over time and the requirements of the user. as well as learn the design of other programmers
18. IDEA • Get rid of bad decisions with better things to get a really good result. • For example, let's remove the unnecessary child classes, which will help us simplify the task and make it easier to understand.
19. “Double encapsulation” in Rick’s software • By encapsulating attributes, we make the application more flexible and easy to change.
20. Finishing up Rick’s app: the InstrumentType enum
21. Sweet! Our software is easy to change... but what about that “cohesive” thing? A cohesive class does one thing really well and does not try to do or be something else .
22. Thanks for your attention!