Synthetic OOD concepts and reuse Lecture 3: Separation of concerns

1. Synthetic OOD concepts and reuseLecture 3: Separation of concerns Topics: Separation of concerns as a general principle for managing complexity in software designs Example problems: Managing dependencies in complex configurations Need to isolate operations over composite structures Visitor pattern: Systematic design technique for encapsulating operations over such structures into a single class CSE 335: Software Design

2. Softw. design “body of knowledge” Organized around a set of core principles • Separation of concerns • Abstraction • Anticipation of change • Modularity • Generality • Incrementality Goal: At end of this course, you should be able to apply these principles with proficiency in real design contexts. Source: Fundamentals of Software Engineering by Ghezzi, Jazayeri, and Mandrioli CSE 335: Software Design

3. Quote from Edsgar Dijkstra Let me try to explain what is characteristic for all intelligent thinking. It is, that one is willing to study in depth an aspect of one's subject matter in isolation for the sake of its own consistency, all the time knowing that one is occupying oneself only with one of the aspects. We know that a program must be correct and we can study it from that viewpoint only; we also know that it should be efficient and we can study its efficiency on another day, so to speak. In another mood we may ask ourselves whether, and if so: why, the program is desirable. But nothing is gained --on the contrary!-- by tackling these various aspects simultaneously. It is what I sometimes have called "the separation of concerns", which, even if not perfectly possible, is yet the only available technique for effective ordering of one's thoughts, that I know of. This is what I mean by "focussing one's attention upon some aspect": it does not mean ignoring the other aspects, it is just doing justice to the fact that from this aspect's point of view, the other is irrelevant. It is being one- and multiple-track minded simultaneously. CSE 335: Software Design

4. Separation of concerns (SoC) Very general principle of software engineering, indeed any intellectual activity Suggests that we should manage complexity by separating (or avoid unnecessarily mixing) conceptually unrelated aspects of a problem or solution A clean separation allows each concern to be dealt with in isolation and for the composition of concerns to be well understood OO Design is flush with patterns and idioms for separating concerns Let’s look at a few of them… CSE 335: Software Design

5. Opportunities for SoC in OO Design Issue: Need to minimize time required to rebuild a large software system that is being updated Concern: Management of rebuild dependencies among files Problem: Program understanding when code contains interleaved strands that accomplish distinct purposes • Code that implements these distinct purposes tends to be “tangled together” • Code for a single purpose may be scattered across many classes and functions Concerns: Each distinct purpose or feature Idea: Manage complexity by disentangling these functionally distinct code strands CSE 335: Software Design

6. Opportunities for SoC in OO Design Issue: Need to minimize time required to rebuild a large software system that is being updated Concern: Management of rebuild dependencies among files Problem: Program understanding when code contains interleaved strands that accomplish distinct purposes • Code that implements these distinct purposes tends to be “tangled together” • Code for a single purpose may be scattered across many classes and functions Concerns: Each distinct purpose or feature Idea: Manage complexity by disentangling these functionally distinct code strands CSE 335: Software Design

7. Problem: Recompiling large systems Large software may require hours rather than minutes to rebuild from scratch Solution well known: • Cleanly separate class declarations from class definitions • Place each declaration or definition in separate file • Create a Makefile that documents the recompilation dependencies and the commands to rebuild Concern: Dependency/configuration management • Must not miss any dependencies! • Becomes difficult when header files #include other header files CSE 335: Software Design

8. System with three classes, A, B, and C, and a main A.cc #includes A.h B.cc #includes B.h C.cc #includes C.h B.h #includes A.h C.h #includes B.h main.cc #includes C.h A.o: A.cc g++ -c A.cc B.o: B.cc g++ -c B.cc C.o: C.cc g++ -c C.cc main.o: main.cc g++ -c main.cc app: main.o A.o B.o C.o g++ -o $@ main.o A.o B.o C.o B.o: A.h B.h C.o: A.h B.h C.h main.o: A.h B.h C.h Example What if you forget these? CSE 335: Software Design

9. SoC to the rescue Dependency management is a real concern that could benefit from separation Solution: Use a tool to generate those nested header dependencies for you • E.g., makedepend(1) • Requires you to: • instrument Makefile so that dependencies can be added • re-run makedepend whenever you make a change that might affect recompilation dependencies CSE 335: Software Design

10. Example (modified Makefile) .SUFFIXES: .cc .o .cc.o: g++ -c $< SRCS=A.cc B.cc C.cc main.cc OBJS=${SRCS:.cc=.o} app: ${OBJS} g++ -o $@ ${OBJS} depend: makedepend ${SRCS} Notice: depend target runs makedepend to regenerate header dependencies, which are appended to end of Makefile CSE 335: Software Design

11. #include “B.h” class A { public: ... protected: const B* bVar; }; class B; class A { public: ... protected: const B* bVar; }; Example: Minimize dependencies Notice: Forward declaration of class B expresses A’s dependency on B without including the entire declaration of B CSE 335: Software Design

12. Opportunities for SoC in OO Design Issue: Need to minimize time required to rebuild a large software system that is being updated Concern: Management of rebuild dependencies among files Problem: Program understanding when code contains interleaved strands that accomplish distinct purposes • Code that implements these distinct purposes tends to be “tangled together” • Code for a single purpose may be scattered across many classes and functions Concerns: Each distinct purpose or feature Idea: Manage complexity by disentangling these functionally distinct code strands CSE 335: Software Design

13. Motivation Suppose we have a class hierarchy that instantiates the composite pattern • E.g., expression-tree hierarchy Lots of polymorphic operations that we might want to implement: • E.g., type checking • E.g., pretty printing • E.g., evaluation CSE 335: Software Design

14. Question Suppose we have an existing Expr hierarchy that supports type checking and evaluation, but not pretty printing. How many classes must we modify in order to add pretty printing? CSE 335: Software Design

15. Visitor pattern Allows addition of new polymorphic operations to a class hierarchy without modifying any of the classes Requires two hierarchies: • Original composite hierarchy • Visitor-class hierarchy New operations implemented by specializing visitor class hierarchy CSE 335: Software Design

16. More precisely Visitor-class hierarchy must have a most abstract root class Every class in the subject hierarchy provides a polymorphic accept operation, which: • takes a reference to the visitor-hierarchy root class as a parameter • invokes a subject-class specific method on this parameter, passing itself (i.e., the object that received the accept message) as a parameter • E.g., the body of accept method in class X would invoke method visitX on visitor object, passing this as a parameter CSE 335: Software Design

17. Example: Expression Visitor class ExprVisitor { public: virtual void visitLiteralExpr(LiteralExpr*); virtual void visitAddExpr(AddExpr*); virtual void visitVarExpr(VarExpr*); virtual void visitSubtractExpr(SubtractExpr*); }; CSE 335: Software Design

18. Accept operation class Expr { public: virtual ~Expr() {} virtual void accept(ExprVisitor&)=0; protected: Expr(); }; class LiteralExpr : public Expr { public: … virtual void accept( ExprVisitor& v ) { v.visitLiteralExpr(this); } … }; CSE 335: Software Design

19. Accept operation (continued) class AddExpr : public Expr { public: void accept( ExprVisitor& v ); protected: Expr* left; Expr* right; }; void AddExpr::accept( ExprVisitor& v ) { left->accept(v); right->accept(v); v.visitAddExpr(this); } CSE 335: Software Design

20. Example: Evaluation visitor class EvaluateVisitor : public ExprVisitor { public: double getValue(); void visitLiteralExpr( LiteralExpr* ); void visitVarExpr( VarExpr* ); void visitAddExpr( AddExpr* ); void visitSubtractExpr( SubtractExpr* ); protected: stack<double> valStack; }; CSE 335: Software Design

21. Evaluation visitor (continued) void EvaluateVisitor::visitLiteral( LiteralExpr* l ) { valStack.push(l->value()); } void EvaluateVisitor::visitAdd( AddExpr* a ) { double rightVal(valStack.top()); valStack.pop(); double leftVal(valStack.top()); valStack.pop(); valStack.push( leftVal + rightVal ); } CSE 335: Software Design

22. Exercise Suppose we have: Expr* e = new AddExpr( new LiteralExpr(5), new LiteralExpr(4) ); Draw a UML sequence diagram that depicts the execution of: EvaluationVisitor ev; e->accept(ev); CSE 335: Software Design

23. Exercise Develop a “pretty-print” visitor for the example Expr hierarchy CSE 335: Software Design