synthetic ood concepts and reuse lecture 3: separation of concerns

CSE 335: Software Design K. Stirewalt

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


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


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.


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…


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 featureIdea: Manage complexity by disentangling these functionally

distinct code strands


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 recompiliation

dependencies and the commands to rebuild

Concern: Dependency/configuration management– Must not miss any dependencies!– Becomes difficult when header files #include other header files


Example

System with three classes, A, B, and C, and a main

A.cc #includes A.hB.cc #includes B.hC.cc #includes C.h

B.h #includes A.hC.h #includes B.hmain.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.hC.o: A.h B.h C.hmain.o: A.h B.h C.h

What if you forget these?


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


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


Example: Minimize dependencies

#include “B.h”

class A {

public:

...

protected:

const B* bVar;

};

class B;

class A {

public:

...

protected:

const B* bVar;

};

Notice: Forward declaration of class B expresses A’s dependency on B without including the entire declaration of B


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 featureIdea: Manage complexity by disentangling these functionally

distinct code strands


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


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?


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


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


Example: Expression Visitor

class ExprVisitor {

public:

virtual void visitLiteralExpr(LiteralExpr*);

virtual void visitAddExpr(AddExpr*);

virtual void visitVarExpr(VarExpr*);

virtual void visitSubtractExpr(SubtractExpr*);

};


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); } …};


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);

}


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;

};


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 );

}


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);


Exercise

Develop a “pretty-print” visitor for the example Expr hierarchy

synthetic ood concepts and reuse lecture 3: separation of concerns

Documents