1. Identify the areas of tight-coupling in the following code: - - PDF document

• 1. Identify the areas of tight-coupling in the following code:
• !"#$

%!"# & '"#$ %'"# & "#$

• &

& ($

• )*!+'*!

!"#$ ,%"# *!%"# & &

• % (*.'/%0

01*0% 21'0' 345"#%**6 %7 %

• %

8% +9+: ;% <% =% !"#$ >% 0'+"*")?+@?## A% & B% '"#$ C% 0'+"*"34D?##

• E% &
• -% "#$
• 8%
• ;% &
• <% D0'+"#$
• =% 0"+.#$%"#&
• >% &
• A% &
• B%
• C% 0+$

8E% "# 8-% & 88% 8;% ( 8<% +$ 8=% 8>% )*!+'*! 8A% "#$ 8B% 0"%'"#,,)?+@?#$ 8C% ,%"# ;E% *!%"# ;-% & ;8% & ;;% & ;<%

• 2. Identify the areas of tight-coupling in the following UML class diagram:
• 2. Answer: Catalog’s is tightly-coupled to the Course implementations because it is responsible

for creating them. If new Course implementations are added, Catalog will need to be refactored. The Factory Method pattern should be applied to decouple the creation of Course implementations from the Catalog.

• 3. Refactor the following code to reduce coupling:

public class Tournament { private List<TournamentListener> listeners_; … public void notifyListeners(){ TournamentChaneEvent evt = new TournamentChangeEvent(…); for(TournamentListener l : listeners_){ l.tournamentChanged(evt); } } } public class TournamentRenderer extends UIElement { private boolean underlineBrackets_ = false; private boolean showPlayerNames_ = true; private Tournament tournament_; public void tournamentChanged(TournamentChangeEvent evt){ if(needsRendering(evt)){ } } public boolean needsRendering(TournamentChangeEvent evt){ … } public void render(){ drawBasicTournament(tournament_); if(underlineBrackets_) drawUnderlinedBrackets(tournament_); if(showPlayerNames_) drawUnderlinedBrackets(tournament_); } }

• 3. Answer: Each type of decoration that needs to be added to the TournamentRenderer causes
• refactoring. The renderer is tightly-coupled to the drawing of the decorations. To eliminate this

coupling, we can apply the Decorator pattern.

public class TournamentRenderer extends UIElement { private List<Decorator> decorators_; private Tournament tournament_; public void addDecorator(Decorator d){ decorators_.add(d); d.setRenderer(this); } public void render(){ drawBasicTournament(tournament_); for(Decorator d : decorators) d.drawDecoration(); } } public interface Decorator { public void setRenderer(TournamentRenderer r); public void drawDecoration(); } public class BracketUnderliningDecorator implements Decorator {….} public class PlayerNameDecorator implements Decorator {….} public class HandicapDecorator implements Decorator {….} public class FraggedDecorator implements Decorator {….}

• 4. Refactor the following design to decrease coupling:
• 4. Answer: The logging of messages and the decision of how to log messages is tightly-coupled

to the Logger class. If we want to add logging targets or change the logic for the ordering of logging targets, we have to change Logger. We should apply the Chain of Responsibility pattern to decouple the decision on what messages get logged where, what order messages are logged,

• etc. from the single Logger class.

public class SomeLogger { public void log(Message m){ //do some logging stuff… …. nextLogger.log(m); } } next logger