Skip to main content

CSC 322.01, Class 34: Rethinking object-oriented design (4)

Overview

  • Preliminaries
    • Notes and news
    • Upcoming work
    • Extra credit
    • Questions
  • Debrief from Friday
  • UML sequence diagrams, revisited
  • The law of Demeter
  • Static and dynamic typing
  • Duck typing and polymorphism
  • Work time

Preliminaries

News / Etc.

  • Mentor sessions this week Tue 8-9 and Thu 7-9.

Upcoming work

Good things to do (Academic/Artistic)

  • Sexual Respect Awareness Month.
  • Squire Lecture in Physics, Tuesday at 11:45: STEM Equality and Inclusion, a Female Astronomer’s View. Noyce 1023.
  • CS Table: OLPC.
  • The Cypher Paradigm: Closing Cypher, Tuesday, 8:30 p.m., ARH 120.

Good things to do (Peer)

  • WGMC 6pm on Thursdays.
  • Contra dance in main lounge 8pm Friday.

Good things to do (Misc)

  • Escape Room, 7-9pm Monday, Gates

Questions

Debrief from Friday

  • Seeing the Git usage was really useful.
  • Hearing him crit SamR’s mediocre code was amusing, but expected.
    • Sam violated the Law of Demeter.
  • “We’d heard about it theoretically; it was useful to see it practice.”
    • Or at least better practice than what we’re currently following.
    • From real industry.
  • The importance of testing.
  • Turning interviews into user storioes.
  • Hearing about the importance of smaller teams.
    • What is small? He said 25. We work with four.
  • The importance of general skills rather than specialization.
    • Is that really sustainable?

UML sequence diagrams, revisited

  • Designing good interfaces requires some careful reflection and consideration.
    • The first interface you design is unlikely to be good.
    • You should think about interfaces in the context of how the interface is used.
  • Diagramming the messages can be useful.

Example that the different diagrams show: How do Trips talk to Mechanics about bicycle repairs?

  • One model is “Dear Mechanic: Please repair bicycles. This is the thing that will give you the bicycles that need repairs.” The mechanic can then ask that thing for an iterator of bicycles, each of which it repairs/tunes.
  • Slight variant: The mechanic can ask the thing for each bicycle in turn. That creates more back and forth between the two objects.
  • More extreme variant: The trip repeatedly sends “please repair this bike” to the mechanic. (This is more likely to be an approach that is susceptible to blocking of sorts.)

The law of Demeter

Software design guideline to help support loosely coupled software. “Software should be losely coupled.”

  • When you have a bunch of methods chained together by dots @request.params.get(:avatar).file.nil?
  • There are a lot of dependencies
    • We assume that @request has a params methods.
    • We assume that the thing from that has a get method.
    • We assume that the thing from that has a file method.
    • Everything has a nil? method.
  • Solution: Refactor the code so that there’s less method chaining.
    • We might add a hasFile(name) method to whatever type request is (or whatever type params is).
  • Note: Some chaining is natural, particularly if you rely only on procedures that are guaranteed to exist with a particular semantics.

Duck typing and polymorphism

Think / pair / share

What is polymorphism? Why do we use it?

  • The ability for one class (or function) to have/work with multiple forms.
  • Formally: “Many shapes” or “many forms”
  • Helps us reuse, maintain, and adapt code.
    • Since you don’t have to specify in advance what type you’re using, you can use it in more situations. You don’t have to go back and rewrite it for a new type.
    • Avoids copy/paste/change.

What is the difference between subtype polymorphism and parametric polymorphism?

  • Subtype polymorphism: You have a type (Interface in Java) which specifices capabilities; you can then write procedures based on that type that work with any object that has those capabilities.
  • Parametric polymorphism: When building something you have a type variable that lets you make something else more general. Like generic types in Java. You can build ListOf<X>.

What is duck typing?

  • “If it walks like a duck and quacks like a duck, it’s a duck.”
  • The ability to assume that an object has certain properties
    • interface Comparable { int compareTo(Comparable other); }
    • public class Student implements Comparable allows me to assume that Student has a compareTo method.
    • Without an explicit statement to that effect. (That is, the code trust the caller to provide it with an object that has the appropriate properties.)
  • Note: If you assume it quacks like a duck, and it doesn’t, your code will break.

What kind of polymorphism does duck typing support and how?

  • Supports subtype polymorphism. We don’t explicitly have to say what kind of data type it is, but we are making assumptions about the type.
    • “type” == “collection of methods we assume the object implements”

Static and dynamic typing

Think / pair / share

What are the arguments for static typing?

  • It allows the compiler to do more type checking.
    • Tells us about errors before we start to run the code.
  • May permit better performance
    • Not as much need to check for errors at run time, which is costly.
    • Can optimize the code based on knowledge of the types.
  • Explicit types help provide better/clearer documentation.
    • For example, it was useful to know that prepareTrip() needed a BicycleFactory and that the bicycles method returns an Iterator<Bicycle>.
  • Easier to prove correctness.

What are the arguments for dynamic typing?

  • Less stuff to write. Types are a PITA. (Pain in the Neck)
  • Looks more like pseudocode.
  • Flexible; does not get in the way of programmers.
  • Metz adds: Static type folk are wrong to worry about type correctness, good programmers write type correct code without a type checker to tell them it’s correct.

What does Sam think?

  • For good programmers, type checking is not necessary.
  • For most programmers, type checking is necessary.

Other important concepts

  • Metz suggests the power of callbacks. (E.g., you pass yourself to the Mechanic. The Mechanic then queries you for all of your bikes.)
  • I got some questions about metaprogramming. E.g., “This concept, writing code that writes code, honestly seems more complicated than it’s worth. I’d be interested to hear more about the pros and cons of metaprogramming and what it can be used for.”
    • Think about attr_reader
    • Lets us focus on the key issues.
    • More genericity.

Work time