Scribd
Upload
111 views

OO Design Principles & Metrics - Exercises

This document discusses principles and metrics for object-oriented design including: 1. Single responsibility - refactor a class to have one responsibility. 2. Interface segregation - refactor a class to have an average number of methods implemented per interface of 1. 3. Dependency inversion - refactor dependencies to depend on abstractions rather than concretions. 4. Open-closed - refactor classes to be extended without modification. 5. Law of demeter - refactor models to follow the principle of least knowledge. 6. Package cohesion - refactor packages to have high internal strength between components. 7. Package coupling - refactor packages to have low dependency

Uploaded by

knslf
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
111 views

OO Design Principles & Metrics - Exercises

This document discusses principles and metrics for object-oriented design including: 1. Single responsibility - refactor a class to have one responsibility. 2. Interface segregation - refactor a class to have an average number of methods implemented per interface of 1. 3. Dependency inversion - refactor dependencies to depend on abstractions rather than concretions. 4. Open-closed - refactor classes to be extended without modification. 5. Law of demeter - refactor models to follow the principle of least knowledge. 6. Package cohesion - refactor packages to have high internal strength between components. 7. Package coupling - refactor packages to have low dependency

Uploaded by

knslf
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 17

OO Design Principles & Metrics

Exercises

Single Responsibility

1. Calculate the responsibilities / class for the following model

ApplicationFor m

Video 0..1 1 title : Str ing year : int directorName : String directorDOB : String directorNationality : String findVideo(title : String) : Collection insertVideo() deleteVideo() updateVideo()

buildMenus() buildToolbars() findVideo(title : String) save() close() refreshVideoList()

2. Refactor the model until responsibilities / class = 1

Interface Segregation

1. Calculate average n/M for the ApplicationForm class


1 ApplicationController

openAppForm() 0..1 ApplicationFor m Pseudo code: buildMenus() buildToolbars() findVideo(title : String) show() close() refreshVideoList() 0..1 void openAppForm() { applicationFor m = new ApplicationForm() applicationFor m.buildMenus() applicationFor m.buildToolbars() applicationFor m.show () }

SearchController 1 performSearch()

Pseudo code: void performSearch() { applicationFor m.findVideoTitle(title) applicationFor m.refreshVideoList() }

2. Refactor the model until average n/M = 1

Dependency Inversion

1. Calculate dependencies on abstractions / total dependencies for this model


1 BBCSearch

performBBCSearch()

1 SearchController 1 1 AmazonSearch

performSearch() 1

performAmazonSearch()

HMVSearch

Pseudo code: void performSearch() { results = new ArrayList() results.add(bbcSearch.performBBCSearch()) results.add(amazonSearch.performAmazonSearch()) results.add(hmvSearch.performHMVSearch()) }

performHMVSearch()

2. Refactor the model until dependencies on abstractions / total dependencies = 1

Open-Closed

1. Calculate classes extended and not modified / classes extended and/or modified for this pair of models
ApplicationController ApplicationController

0..1 ApplicationFor m

openAppForm()

0..1 ApplicationFor m

openAppForm()

buildMenus() buildToolbars() findVideo(title : String) show() close() refreshVideoList() 0..1 1

on on next next check-in check-in

buildMenus() buildToolbars() findVideo(title : String) show() close() refreshVideoList() 0..1 1 SearchController

SearchController

performSearch()

performSearch() performBBCSearch() performHMVSearch() performAmazonSearch()

2. How could this change have been done so that classes extended and not modified

/ classes extended and/or modified = 1?

Liskov Substitution

1. What is wrong with this model?


1 ApplicationController Pseudo code: void findVideo(String title) { searchController.setTitle(title) searchController.performSearch() refreshVideoList(searchController.getResults().toArray()) }

0..1 ApplicationFor m

openAppForm()

buildMenus() buildToolbars() findVideo(title : String) show() close() refreshVideoList(Video[ ]) 0..1 1 SearchController # title : Str ing # results : Collection performSearch()

Pseudo code: void performSearch() { results = webConnection.go(videotitle=+HttpContext.urlEncode(title)) }

Pseudo code: BBCSearchController void performSearch() { If(title != null) then results = webConnection.go(videotitle=+HttpContext.urlEncode(title)) }

performSearch()

2. Refactor the model so that the client wont break when BBCSearchController is substituted for SearchController

Law of Demeter

1. Calculate the average depth of navigation for this model

ContactFor m areaCode : TextBox refresh()

Contact * getHomeAddress() : Address

homeAddress 1

Address

getPostcode() : Postcode getContacts() : List addresses *

Pseudo code: void ref resh() { areaCode.setText(contact.getHomeAddress().getPostcode().getPostalArea().getAreaCode()) }

1 * postcodes Postcode houseCode : String getPostalArea() : PostalArea getHouseCode() : String getPostCodeString() : String getAddresses() : List

PostalArea areaCode : String getAreaCode() : String getPopulationSize() : int 1

Pseudo code: int getPopulationSize() { int population = 0 for each Postcode postcode in postcodes { for each Address address in postcode.getAddresses() { for each Contact contact in address.getContacts() { population++; } } } return population; }

2. Refactor the model so that the average depth of navigation is 1

Package Cohesion

1. Calculate the cohesion of this package


contacts

1 ContactFor m 0..1 1 Contact

PhoneNumber

PhoneList

ContactDataAccess

DbConnection

SqlConnection

2. Refactor this model to make the package(s) more cohesive

Package Coupling

1. Calculate the abstractness and instability of each package


2. Calculate the normalised distance from the main sequence of each package

ui::contacts

model::contacts

1 ContactFor m 0..1 1 data PhoneList 1 Contact

PhoneNumber

IDataAccess

1 1 ContactDataAccess DbConnection

SqlConnection

3. Refactor the model to reduce the distance from the main sequence for every package where D > 0

You might also like