CSC321.01 2016S, Class 19: Design Patterns for SaaS
- Upcoming Work.
- Extra Credit.
- Refactoring, revisited.
- Design patterns.
- The GoF list of patterns.
- What did you do/learn without me?
- Readings for Wednesday: SaaSbook Chapter 11
- Reading Journal for Wednesday (due Tuesday at 8pm)
- Subject: Reading Journal for Class 20 (Your Name)
- What does the SOLID acronym stand for?
- In your own words, what is a design pattern? What is an antipattern?
- Which design principle or pattern did you find the most relevant to your CSC 322 project or other prior experience with object-oriented programming? Explain the pattern and why you chose it.
- Which design principle or pattern did you find the most confusing? Explain it as best you can and say where you got confused.
- As always, better questions were stolen from JLND.
Good Things to Do
- Public Events Concert Tuesday Night
Things We Learned
- Draw pretty pictures to illustrate software systems.
- Relationships between different components
- Method calls
- Data relationships (one:one, one:many, many:many)
- Orders of actions
- Why pictures?
- Simple and easy to understand.
- Maybe simple enough for pointy-haired managers
- Why one particular way to write the diagrams?
- Uniformity helps with clarity.
Ethics of Software Professionals
- No complete consensus.
- While we should care about the client, keep in mind what's best for
society as a whole.
- Compare to other professions, such as bridge engineers
- Software is so broad that it's not clear that everyone needs to
follow the same standards: Someone developing a game may not need
to follow the same standards as someone developing the software
to control breaks on a car.
- Should we overbuild?
- Whose responsibility is it when something breaks? It's not as simple
as you might think.
Where should ethics of computing professionals fit within the Grinnell CS
- Small case studies in CSC 321 and CSC 322 and then add the code of ethics
- "Make us write essays so that we can better formulate ideas for
what to do when we encounter ethical questions!"
- "In comic books"
- Don't worry about it; as liberal arts students we already know how to
- Add a two-credit course on ethics which includes some case studies and
compares to other professions. A serious enough issue that it shouldn't
be crammed in among the gaps in other topics. (Or is it serious enough
that we should be talking about it in every class.)
- Complicated enough that we need to focus deeply in order to apply it.
- A relevant ethics course in Philosophy doesn't suffice; the problems
feel somewhat different
- Introduce the code of ethics earlier, so that we can start to understand
what it is before we get to here. Deeper cases would be good.
- Big cases are easy. What about smaller cases, which are often more
Refactoring is an approach to dealing with bad code smells. For each
of the following, think about one or more examples and come up with
aproaches to dealing with the bad smells.
- Repeated code: Nearly identical procedures
- Repeated code: Within a procedure
- Magic numbers
- Too many parameters
- Too-long procedures
- Complex control structures, usually with nested ifs
- Code that is never executed
Repeated code: Nearly identical procedures
- Write a more general procedure that takes an additional parameter
that handles the different part.
- In a functional language, that might be a procedure.
Repeated code: Within a procedure
- Use a loop
- Turn into a separate procedure and do the stuff above
- May be difficult if we are doing assignment
- Restructure the code to put the common code together (e.g., in a
- #define in C. More generally, use constants in whatever the model
is for that language.
Too many parameters
- Maybe the function is trying to do too many things, so break it
into separate functions.
- Combine things into structs or objects or something equivalent.
- Break it into separate functions.
- In some cases, the too-long-ness is repeated code, so we should
- Move behavior to objects.
Complex control structures, usually with nested ifs
- Use a case statement.
- It depends on the case. Sometimes you need a nested if.
- Look for code that may not be executed.
- Break portions out into separate procedures.
- For complex tests, write a separate procedure.
- Use goto! (Only if absolutely necessary and you're about to quit
your job anyway.)
- Diagram the control flow and see if there's a simpler description.
- Move the control to the objects.
x += 23;
x += 11;
x += 5;
foo, bar, and baz are subclasses of soemthing
x += thing.importantValue()
Code that is never executed
- Be happy! It's probably there only when errors occur and they haven't
- Think about why it's not getting executed.
- Is it that it's not getting executed in your tests?
- Is it that it can never be executed? (Delete it.)
- Maybe it's obsolete.
- What should you do with a procedure that you know is never called?
- Comment it out.
- Use your version control system and just delete it.
The GoF list of patterns