lecture 28: principle of least knowledge
DESCRIPTION
Computer Science 313 – Advanced Programming Topics. Lecture 28: Principle of Least Knowledge. 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 - PowerPoint PPT PresentationTRANSCRIPT
![Page 1: Lecture 28: Principle of Least Knowledge](https://reader034.vdocuments.site/reader034/viewer/2022051020/56816556550346895dd7d38e/html5/thumbnails/1.jpg)
LECTURE 28:PRINCIPLE OF LEAST KNOWLEDGE
Computer Science 313 – Advanced Programming Topics
![Page 2: Lecture 28: Principle of Least Knowledge](https://reader034.vdocuments.site/reader034/viewer/2022051020/56816556550346895dd7d38e/html5/thumbnails/2.jpg)
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
![Page 3: Lecture 28: Principle of Least Knowledge](https://reader034.vdocuments.site/reader034/viewer/2022051020/56816556550346895dd7d38e/html5/thumbnails/3.jpg)
Getters Are
![Page 4: Lecture 28: Principle of Least Knowledge](https://reader034.vdocuments.site/reader034/viewer/2022051020/56816556550346895dd7d38e/html5/thumbnails/4.jpg)
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
![Page 5: Lecture 28: Principle of Least Knowledge](https://reader034.vdocuments.site/reader034/viewer/2022051020/56816556550346895dd7d38e/html5/thumbnails/5.jpg)
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
![Page 6: Lecture 28: Principle of Least Knowledge](https://reader034.vdocuments.site/reader034/viewer/2022051020/56816556550346895dd7d38e/html5/thumbnails/6.jpg)
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
![Page 7: Lecture 28: Principle of Least Knowledge](https://reader034.vdocuments.site/reader034/viewer/2022051020/56816556550346895dd7d38e/html5/thumbnails/7.jpg)
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”);
![Page 8: Lecture 28: Principle of Least Knowledge](https://reader034.vdocuments.site/reader034/viewer/2022051020/56816556550346895dd7d38e/html5/thumbnails/8.jpg)
Getters are not the Solution Getter could make finding uses harder!public void printOutEntireDictionary(Dict d) {
PrintWriter e = System.getOut();PrintWriter o = System.getErr();PrintWriter s = 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);
![Page 9: Lecture 28: Principle of Least Knowledge](https://reader034.vdocuments.site/reader034/viewer/2022051020/56816556550346895dd7d38e/html5/thumbnails/9.jpg)
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);}
![Page 10: Lecture 28: Principle of Least Knowledge](https://reader034.vdocuments.site/reader034/viewer/2022051020/56816556550346895dd7d38e/html5/thumbnails/10.jpg)
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);}
![Page 11: Lecture 28: Principle of Least Knowledge](https://reader034.vdocuments.site/reader034/viewer/2022051020/56816556550346895dd7d38e/html5/thumbnails/11.jpg)
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(); : :
![Page 12: Lecture 28: Principle of Least Knowledge](https://reader034.vdocuments.site/reader034/viewer/2022051020/56816556550346895dd7d38e/html5/thumbnails/12.jpg)
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);}
![Page 13: Lecture 28: Principle of Least Knowledge](https://reader034.vdocuments.site/reader034/viewer/2022051020/56816556550346895dd7d38e/html5/thumbnails/13.jpg)
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?