Overview

• Preliminaries.
  • Admin.
  • Upcoming Work.
  • Extra Credit.
  • Questions.
• Refactoring, revisited.
• Design patterns.
• The GoF list of patterns.

Preliminaries

Admin

• What did you do/learn without me?

Upcoming Work

• 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

Academic

• Public Events Concert Tuesday Night

Peer

Other

Questions

Things We Learned

UML

• Draw pretty pictures to illustrate software systems.
• Relationships between different components
  • Method calls
  • Data relationships (one:one, one:many, many:many)
  • Orders of actions
  • Inheritance
• 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 curriculum?

• Small case studies in CSC 321 and CSC 322 and then add the code of ethics somewhere later.
  • "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 behave ethically.
• 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 complex?

Refactoring, revisited

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 conditional).

Magic numbers

• #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.

Too-long procedures

• Break it into separate functions.
• In some cases, the too-long-ness is repeated code, so we should use loops.
• 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. E.g., from case foo: x += 23; break; case bar: x += 11; break; case baz: x += 5; break; To 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 occurred.
• 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.

Design patterns

The GoF list of patterns