CSC 322.01, Class 36: Rethinking object-oriented design (5)

Overview

• Preliminaries
  • Notes and news
  • Upcoming work
  • Extra credit
  • Questions
• Exploring inheritance
• Work time

Preliminaries

News / Etc.

• Mentor sessions next week Tue 8-9 and Thu 7-9.
• Please invite your community partners to our final presentations at 2:00 p.m. on Friday, 11 May 2018. (Our normal classroom.)
• KY and I were noting that many of the ideas in the class don’t make sense until the second or third time you see them. It strikes me that for some of you, ‘template method’ works that way. We talked about it …
• Question: Should we do POODR earlier in the semester? Yes.
• “Sam, I want to …” Can I leave class at 3pm?
  • Provided you make up the work over the weekend.
  • And promise to be moderate over the weekend.

Upcoming work

• Readings for Friday
  • Chapter 7 of Practical Object-Oriented Design in Ruby
• Reports Friday.
• Final (one-week) sprint starts next Monday.
  • End of sprint retrospective.
  • Sprint planning (“What do you need to do to wrap up?”)

Good things to do (Academic/Artistic)

• Sexual Assault Awareness Month.
• Public science symposium next Thursday/Friday.
  • Cool talks Thursday
  • Up-goer five posters Friday
  • Up-goer five poster reception 3pm on Friday
  • Talk Friday at 4:15 by Minute Physics Alum Celebs

Good things to do (Peer)

• Contra dance in main lounge 8pm Friday. See the Barn Owls.
• The Grinnellian Festival on May 5 or so. The pointy finger people are performing.

Good things to do (Misc)

• Dance + Jazz (tonight (7:30), the day after this day (7:30), Sunday (2:00) )
  • Roberts theater
  • There are tickets, but it’s Grinnell. If you wait in line there will be tickets.
• Senior week stuff next week

Less good things to do (Misc)

• Relays
• Titular head

Friday PSA

• Take care of yourselves.

Questions

Exploring inheritance

What’s different?

From my perspective, there are two particularly important differences.

• We often talk about inheritance in terms of the subclass gaining methods and fields from the superclass. Metz talks about the subclass delegating messages to the superclass. That’s a different consideration.
• At least when I teach 207, we think about inheritance in terms of “design the general and then specialize”. Metz’s is more of a “design the specific and then discover the general when appropriate”.
  • That’s part of the general philosophy of agile that you solve the problem at hand, not the one you expect in the future.

There are multiple other important issues

• A third important issue that some of you raised is that Template Methods and hooks invert the way we normally think of inerhitance working.
  • Traditionally, subclasses delegate messages to the superclass.
  • In this model, a method in the superclass is calling procedures that it expects to be in the subclass. (It’s not quite delegation, but there’s a difference in perspective.)
• A fourth is the value of drawing diagrams to explain relationships. In the prior chapter, we drew diagrams to explain calling relationships. Now we draw diagrams to explain inheritance relationships.
• We’ve traditionally treated subclassing as an “is-a” relationship. In a duck-typed language, “is-a” feels much more like something handled by duck typing than inheritance.
• Looking ahead, we’ll see things like inheritance that serve more of the “add functionality” role.

Refactoring

There appears to be some confusion about the idea of refactoring. So we’ll talk about it a bit more.

• Key agile principle: When you notice bad code, you have an obligation to rewrite it.
• Refactoring is the general term for “taking less good code and rewrite it to better code”.
  • Traditional refactoring approach: “If I end up writing a procedure by copy/paste/change, I should instead write a more general procedure and make the “change” part a parameter.”
  • Traditional refactoring approach: “If I write similar code twice, I should just make the code a procedure.”
  • We’re learning new methods:
    • “Hmmm … maybe instead of building objects, I should be taking them as parameters.” (Dependency injection.)
    • “Hmmm … maybe instead of chaining together method calls, I should be adding functionality to this other class.” (Law of Demeter)
    • “Hmmm … I’m about to build a new class that is similar to another class. It will be wrong to just subclass. I guess I need to pull out a common superclass.”
• Note: In the traditional way, it takes a little longer than the easy way, but provides big payout in the end. (“Whoops, I now have ten places I’ve copied/pasted/changed that I have to fix.”)

From chapter 1-6, we have learned so many intricate and detailed techniques to make our code more efficient and reusable. However, I am a little confused as to how feasible it is to make all these changes in a real world work setting. Making sure I follow all the regulations for inheritance from chapter 6 alone would take several extra days. In the real world, with deadlines being pushed on you always and only having a sprint to work on a feature, how feasible are all these refactoring techniques?

Sam says …

• Surprisingly, most (good) agile shops really do believe in refactoring as soon as possible.
• In cases where you can’t, you do put “refactor” in as an upcoming ticket.
• Once you apply the techniques again and again and again they become much faster.
  • And you tend to design better in the first place.

Template methods

There was also some confusion about template methods. We’ll talk about them and then do a practice problem.

• Another mechanism for writing generic code.
• Parent/abstract class has primary algorithm which calls other procedures.
• Subclasses are expected to implement the other procedures.

Exercise: Write/sketch a InsertionSort class that would be subclassed with InsertionSortStringsAlphabetically, InsertionSortStringsByLength, and InsertionSortReals. (No, this is not a realistic example; it’s still good practice to think about how you’d solve a common problem using a different approach.)

• Sam diagrammed this enough.

The post_initialize approach (aka “hooks”)

• It attempts to address a potential problem with dependencies.
• However, from my reading, it doesn’t work unless people make it common practice not to override the initialize method.
  • So it introduces another kind of problem (one that doesn’t have a name).
• We debate which is easier to notice / fix.
• Are there other ways you’d address this problem?

Questions and comments

_Metz also brings to light how the concept of inheritance is sometimes misused. We often create subclasses for a class which should not have existed in the first place. Metz gives an example of how Bicycle class has been suclassed (page 116) while it should not have in the first place which leads to a class behaving in two different ways. _

Work time