Lecture 28: Principle of Least Knowledge

1. Computer Science 313 – Advanced Programming Topics Lecture 28:Principle of Least Knowledge

2. Public Fields are Evil • Always make fields private(or protected) • Cannot control field’s uses • Can be used by any class • Modified anywhere in program • Cannot track any of this • Makes future changes difficult • Cannot remove or replace field • Code may rely on its exact type • Code base stuck & so is limited

3. Getters Are

4. Getters Are Also Evil • After calling getter: • Cannot control field’s uses • Can be used by any class • Modified anywhere in program • Cannot track any of this • Makes future changes difficult • Cannot remove or replace field • Code may rely on its exact type • Code base stuck & so is limited

5. Coupling • “Measure” of how independent classes are • Classes using own fields & methods are independent • Changes to independent classes are simple • Any change to dependent class causes ripples • Consider all classes dependent on one being changed • May affect classes dependent on those classes • Completely independent classes unrealistic • One class for entire program required to do this • Instead focus on how to minimize coupling

6. Principle of Least Knowledge • More commonly called Law of Demeter • (Stupid meaningless name that need not exist) • Only call methods belonging to: • Current object (e.g., this) • Current object’s fields • Object allocated within the method • One of the parameters to the method • May not limit dependent classes • But certainly makes tracking them down easier

7. Violating the Principle • Fixing something, but what is problem? • Using getters, fields can travel everywhere • Dependent classes hard to find & count • Most common Java violation of this rule:System.err.print(“Bar);System.out.println(“Foo”); • Would this code really be any better?System.getErr().print(“Bar”);System.getOut().println(“Foo”);

8. Getters are not the Solution • Getter could make finding uses harder! public void printOutEntireDictionary(Dict d) {PrintWritere = System.getOut();PrintWritero = System.getErr();PrintWriters = new PrintWriter(new File…));for (Entry<String,String> ent : d) {s.println(ent.getKey()+ent.getValue());e.println(ent.getKey()+“\t”+ent.getValue());o.println(ent.getKey()+“”+ent.getValue());translateToGerman(ent, s);translateToSpanish(ent, o);translateToSpanish(ent, e);

9. What Can Be Done? public void buildPool(Store s) { Fish attack = null; try { attack = s.getSharks();attack.addLasers(); } catch (Exception e) { attack = s.getSeaBass();attack.mutate();attack.makeIllTempered(); }pool.populate(attack);}

10. What Can Be Done? public void buildPool(Store s) { Fish attack = null; try { attack = s.getSharks();attack.addLasers(); } catch (Exception e) { attack = s.getSeaBass();attack.mutate();attack.makeIllTempered(); }pool.populate(attack);}

11. Ugly Solution public void armFish(Fish f) {f.addLasers();}public void buildPool(Store s) { Fish attack = null; try { attack = s.getSharks();armFish(attack); } catch (Exception e) { attack = s.getSeaBass(); : :

12. Prettier Façade Solution public void buildPool(EvilStore s) { Fish attack = null; try { attack = s.getSharksWithLasers(); } catch (Exception e) { attack = s.getITMutatedSeaBass(); }pool.populate(attack);}

13. For Next Class • Keep working on Lab #5 due in 1 hour • Read pages 275-286 for Monday • Discusses another very useful design pattern • Could make classes easier, if you had known • Overlaps with other patterns, which are similar?