Should Configuration be a utility class or a Singleton? Why shouldn't it be a class that can have multiple instances?

In the current design, Configuration reads from the same directory as the application. This can cause problems if the application doesn't have write access to that directory. How can environment variables be used to fix this? What role do installers play?

Should Configuration have setters that are passed parameters that aren't String objects?

What is the benefit of having (some of) the getters return a default? What would you have to do otherwise?

Should the getters that don't have a default return null or throw an exception?

Why are resource loaders needed?

How does the current implementation work?

Should the ResourceLoader keep a Map of InputStream objects?

Should DocumentManager be a Singleton?

• One "Document"/Multiple "Menus": Use a single DocumentManager. Use Action objects to perform tasks (where each Action can be in more than one "menu".
  
• Multiple "Documents"/One "Menu" for Each: Use a DocumentManager for each "pair"
  

How does the design make testing the DocumentManager class more difficult than it might be otherwise? Should the design be changed as a result?

What other kinds of documents could/should the design include?

• CSVDocument
  
• XMLDocument
  
• JSONDocument
  

Where would you package them (in document, at the same level as document, elsewhere)?

• I think I would put them at the same level as document because there will probably be other classes that are associated with the format/representation (e.g., readers and writers).
  

Why does the design include an EditableFactory interface? (Hint: Think about what will happen when we need to be able to construct a new "document" using a GUI.)

How much effort was required to implement the factories?

Does the inclusion of the factories limit the design in any way?

Should BigPixelDocument include a constructor that is passed a String and does the work of createProduct(String) that is in BigPixelDocumentFactory?

How "important" is the PropertyConstants class?

Why should "magic numbers" be avoided? Should they be replaced in the class or added to another class (like PropertyConstants)?

What happens if AbstractEditable.notifyDocumentManager() is implemented as follows?

• That method must be passed an object of type D. this is of type AbstractEditable<D>, so it won't compile.
  
• (D)this will compile but is an unsafe cast.