LECTURE 28:PRINCIPLE OF LEAST KNOWLEDGE

Computer Science 313 – Advanced Programming Topics

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 May not be able to change bases

Getters Can Be 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 May not be able to change bases

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

Principle of Least Knowledge More commonly called Law of

Demeter (Stupid name that does not really mean

anything) 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

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”);

Getters are not the Solution Getter could make finding uses harder!public void printOutEntireDictionary(Dict d) {

PrintWriter e = System.getErr();PrintWriter o = System.getOut();PrintWriter f = new PrintWriter(new File…));for (Entry<String,String> ent : d) { f.println(ent.getKey()+ent.getValue()); e.println(ent.getKey()+“\t”+ent.getValue()); o.println(ent.getKey()+“”+ent.getValue()); translateToGerman(ent, f); translateToSpanish(ent, o); translateToSpanish(ent, e);

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);}

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);}

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(); : :

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);}

For Next Class

Keep working on Lab #6 due on Wednesday

Read pages 275-286 for Monday Discusses another very useful design

pattern Should have used last CSC213, if you

had known Overlaps with other patterns, which are

similar? Next set of pattern reports due after

break To be submitted day we return: Monday,

April 12th

Worth 12% of final grade, so do a good job