Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Chapter 5: Good design = Flexible softwave

Chapter 5: Good design = Flexible softwave

#OOAD

mactiendinh

January 16, 2018
Tweet

More Decks by mactiendinh

Other Decks in Technology

Transcript

  1. 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.
  2. 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.
  3. 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:
  4. 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.
  5. 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.
  6. 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:
  7. 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.
  8. 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?
  9. 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?
  10. 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.
  11. 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.
  12. 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.
  13. 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
  14. 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.
  15. “Double encapsulation” in Rick’s software • By encapsulating attributes, we

    make the application more flexible and easy to change.
  16. 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 .