Lecture 7 - Software Engineering II Fall 2009 Click to edit Master subtitle style Week 9 Design patterns Click to edit Master subtitle style Object

Info iconThis preview shows pages 1–10. Sign up to view the full content.

View Full Document Right Arrow Icon
Click to edit Master subtitle style Software Engineering - II Fall 2009 Week # 9
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Click to edit Master subtitle style Design patterns
Background image of page 2
Object Design What’s been done? – Prior activities (e.g workshop) and artifacts How do things relate? – Influence of prior artifacts (e.g use cases) in OO Design How much design modeling to do, and how? What’s the output?
Background image of page 3

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Design patterns A Design Pattern : Is a solution to a problem in context Is a named problem/solution combination Has been applied repeatedly over time Can be applied in new contexts Includes advice on its application in novel situations Includes a discussion of its trade-offs
Background image of page 4
Why patterns? Real engineering disciplines have handbooks that describe successful solutions to known problems. Automotive engineers don't design cars using the laws of physics—they reuse designs with successful track records. Until recently, there was no such body of knowledge for software engineering.
Background image of page 5

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Information Expert principle "An object should be responsible for something that is done to it, or something it does, in the real world." Who should be responsible for knowing the grand total of a sale? Who should be able to tell when the lander touches the lunar surface? Responsibilities don't map 1:1 to method calls, but methods are typically used to fulfill responsibilities.
Background image of page 6
High Cohesion principle "Keep cohesion high." Cohesion is a measure of how strongly related and focused the responsibilities of an element are. A class with low cohesion does many unrelated things, and has a number of problems: Hard to understand. Hard to reuse. Hard to test. Hard to maintain. Constantly affected by change. Design each class to do one thing well.
Background image of page 7

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
High Cohesion principle (example) Which of the following classes has higher cohesion? class Split1 { public Split1(InputStreamReader rdr) {. ..} public void readNextLine( ) throws IOException {. ..} public int numFields( ) {. ..} public String getField(int fieldNo) {. ..} } class Split2 { public Split2(String line) {. ..} public int numFields( ) {. ..}
Background image of page 8
(continued) High cohesion is correlated with orthogonality . A set of things is orthogonal if a change to one thing results in no change to any of the other things. Orthogonality is highly desirable
Background image of page 9

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Image of page 10
This is the end of the preview. Sign up to access the rest of the document.

This note was uploaded on 03/28/2011 for the course CS 643 taught by Professor Naumanriazchaudhry during the Spring '11 term at École Normale Supérieure.

Page1 / 42

Lecture 7 - Software Engineering II Fall 2009 Click to edit Master subtitle style Week 9 Design patterns Click to edit Master subtitle style Object

This preview shows document pages 1 - 10. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online