To consider

public void printMenu(a) {
    PancakeHouseMenu pancakeHouseMenu = new PancakeHouseMenu();
    ArrayList breakfastItems = pancakeHouseMenu.getMenuItems();
    
    DinerMenu dinerMenu = new DinerMenu();
    MenuItem[] lunchItems = dinerMenu.getMenuItems();
    
    for (int i = 0; i < breakfastItems.size(); ++i) {
        MenuItem menuItem = (MenuItem) breakfastItems.get(i);
        System.out.print(menuItem.getName() + "");
        System.out.println(menuItem.getPrice() + "");
        System.out.println(menuItem.getDescription());
    }
    
    for (int i = 0; i < lunchItems.length; ++i) {
        MenuItem menuItem = lunchItems[i];
        System.out.print(menuItem.getName() + "");
        System.out.println(menuItem.getPrice() + ""); System.out.println(menuItem.getDescription()); }}Copy the code

According to our printMenu() implementation, which of the following is true? P322

  • A. We are targetingPancakeHouseMenu 和 DinerMenuRather than code for the interface.
    • Programming for a specific implementation, there is no decoupling and no dynamic replacement
  • B. The waitress did not implement the Java hospitality API, so she did not comply with the standard.
    • Hostesses have a hospitality specification that implements an implicit API and an internal implementation that encapsulates the changes
  • C. if we decide to go fromDinerMenuSwitch to another menu where the items are usedHashtableWe’re gonna need to change a lot of code in the waitress.
    • HashtableIs a new concrete implementation that needs to modify the code for adaptation
  • D. Hostesses need to know how each menu expresses an internal set of menu items, which violates encapsulation.
    • The implementation of waitress relies on the internal implementation of the menu, and the menu is strongly coupled without encapsulation changes
  • E. We have duplicate code;printMenu()Method requires two loops to traverse two different menus. If we add a third menu, we need a third loop.
    • Since you are programming for a specific implementation of a menu item collection, adding a new menu requires an additional loop
  • F. This implementation is not based on MXML(Menu XML), so there is no way to interoperate.

    • The implementation isn’t based on MXML(Menu XML) and so isn’t as interoperable as it shoule be.

    • Interoperability (English: Interoperability; Interoperability, as a feature, refers to the ability of different systems and organizations to cooperate and work cooperatively (interoperability). In software, interoperability is a term used to describe the ability of different programs to exchange data with the same exchange formats, read and write the same file formats, and use the same protocols.

    • I didn’t understand at first, but after reading the explanation on Wikipedia, I got a little confused. This implementation internally deals directly with different data formats and has some interoperability.

To consider

Continue with the implementation of PancakeHouseIterator and make the necessary changes to the PancakeHouseMenu class. P327

public class PancakeHouseIterator implements Iterator {
    ArrayList items;
    int position = 0;
    
    public PancakeHouseIterator(ArrayList items) {
        this.items = items;
    }
    
    public Object next(a) {
        return items.get(position++);
    }
    
    public boolean hasNext(a) {
        returnposition >= items.size(); }}public class PancakeHouseMenu {
    ArrayList menuItems;
    
    // Constructor and other methods
    // Remove the public ArrayList getMenuItems() method
    
    public Iterator createIterator(a) {
        return newPancakeHouseIterator(menuItems); }}Copy the code

Iterator pattern

Provides a way to sequentially access elements in an aggregate object without exposing their internal representation.P336

The characteristics of
  • Traverse the inner elements of the collection without exposing the inner representationP336
  • Keep the interface and implementation of aggregation simpleP336
  • Manage collections of objects without having to worry about traversalP336

To consider

The class diagram for the iterator pattern looks a lot like another pattern we’ve studied; Do you know which model it is? Tip: Subclasses decide which object to create. P337

  • Factory method pattern

Design principles

Single responsibility principle: a class should have only one cause of change P339

  • High cohesion: A module or a class supports only one set of related functionalityP339
The characteristics of
  • Try to assign a responsibility to only one classP339
  • Classes that follow the single responsibility principle are highly cohesiveP339

To consider

Please quickly write down the three things we need to do to the cafe menu code in order to make it conform to our framework: P342

public class CafeMenu {
    HashTable menuItems = new Hashtable(); 
    
    public CafeMenu(a) {
        // Omit the following parameters
        // addItem(...) ;
        // addItem(...) ;
        // addItem(...) ;
    }
    
    public void addItem(String name, String description, boolean vegetarian, double price) {
        MenuItem menuItem = new MenuItem(name, description, vegetarian, price);
        menuItems.put(menuItem.getName(), menuItem);
    }
    
    public Hashtable getItems(a) {
        returnmenuItems; }}Copy the code
  • implementationMenuinterface
  • deletegetItems()methods
  • increasecreateIterator()methods

This post is posted on GitHub: Reading-Notes/Head-First-Design-Patterns