Design Note #1
Design Note #1
Single Responsibility Principle (SRP)
31 January 2007
../../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
StudyGuideDesign.xml
Each class should have only one reason to change.
Each module should be responsible for only a single activity.
The ../code/parser/tokenizer.h, in
../code/parser is responsible for
extracting tokens from a stream.
tokenizer contains a single class, Toker, responsible for extracting tokens from a stream. Since it refers
to the istream class, it can also work with streams derived from istream, like istringstream.
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.