CSE687 Lecture #1
CSE687 - Lecture #1 Design Note
Single Responsibility Principle (SRP)
8 January 2003
../../webpages/FawcettHome.xml
../../Courses.xml
../../Code.xml
../../Books.xml
www.ecs.syr.edu/faculty/fawcett/handouts
../../research.xml
../../swdev.xml
../../webdev.xml
../../news.xml
../../OtherLinks.xml
../../SiteDesign.xml
../../CSE681/CSE681Code.xml
../../CSE687/CSE687Code.xml
../../CSE691/CSE691Code.xml
../../CSE775/CSE775Code.xml
../../CSE776/CSE776Code.xml
../../CSE778/CSE778Code.xml
../../CSE784/CSE784Code.xml
../Lecture1/CSE687CodeL1.xml
../Lecture2/CSE687CodeL2.xml
Each class should have only one reason to change.
Each module should be responsible for only a single activity.
The ../code/semi/tok.h, in
../code/semi is responsible for
extracting tokens from a stream.
tok contains three classes:
codeDelimiter is responsible for defining delimiters when parsing C or C++ code.
xmlDelimiter is responsible for defining delimiters when parsing xml.
toker is responsible for extracting tokens.
If a class has more than one responsibility, then the responsibilities become coupled.
Changes to one responsibility may impare or inhibit the ability of the class to meet
the others. This kind of coupling leads to fragile designs that break in unexpected
ways when changed.