Lecture 2: Design Principles

Video 🔒

• Iteration 0 is over.
• Trade-offs: You know how to put pieces together, but you don’t know if they’re any good.
• Last lecture we had two different ways to implement subtasks:
• What principles do you follow when you’re drawing UML & writing code?
  • Not syntactical things, like arrows not crossing on a diagram, or indented code. We take those for granted.
  • Smaller classes.
  • Fewer classes.
  • Short code.
  • Code in which each line is simple to understand (80-column limit).
  • Code that runs fast.
  • Why? Why not?
• Some of these principles apply to both software design and code, as well as to other forms of design, like product design, graphic design, and so forth.
• Principles are at odds with one another.
  • To decide is to cut: “late Middle English (in the sense ‘bring to a settlement’): from French décider, from Latin decidere ‘determine’, from de- ‘off’ + caedere ‘cut’.”
  • Principles aren’t laws. But you must have a good story for why you’re breaking them.
  • Different communities tend to value different things. For example, Java values stability, while Ruby on Rails values progress.
  • For every principle ask Why? & Why not?
• For me, the most important is being easy to understand.
  • I’m mainly writing for people to read, not for machines to execute.
  • It’s relative: Who’s the audience?
  • Avoid fancy language features, avoid premature abstractions, avoid third-party dependencies, and so forth.

You Aren’t Gonna Need It (YAGNI) & Keep It Simple, Stupid (KISS)

• How to make TODOOSE simpler?
• Roboose: Use GitHub as much as possible (notifications, database (both as JSON files and in issues), and so forth).
• Why? Why not?
  • Simple is only a starting point. Sometimes simple isn’t easy.
    • Assembly is simple (few features), but difficult.

Don’t Repeat Yourself (DRY)

• When implementing subtasks in TODOOSE, have a parent field in both the Item and Subitem classes.
• Router in TODOOSE is

  .routes(() -> {
    path("items", () -> {
        get(itemsController::getAll);
        post(itemsController::create);
        path(":identifier", () -> {
            delete(itemsController::delete);
            put(itemsController::update);
        });
    });
  })
  

  but could be

  .get("/items", itemsController::getAll)
  .post("/items", itemsController::create)
  .delete("/items/:identifier", itemsController::delete)
  .put("/items/:identifier", itemsController::update)
  

• Why? Why not?

Convention Over Configuration

• Port number in Server.
  • Both when Heroku provides one and when we don’t, when running locally.
• Why? Why not?

Loose Coupling

• Least knowledge.
• Depend on interfaces, not on implementations.
• ArrayList → List → var.
• Why? Why not?

Encapsulate What Varies

• Things that change together should be near in the code.
• Controllers: Actions change more often than routes.
• Why? Why not?

SOLID

• Watch this talk, and go watch Sandi Metz on this year’s Association for Computing Machinery Lecture Series in Memory of Nathan Krasnopoler.
• We’ll only talk about the S (Single Responsibility Principle) in lecture, the rest is covered in Assignment 2.
• ItemsRepository vs. static methods on Item.
• Why? Why not?

The Rails Doctrine

• Why? Why not?

The Zen of Python

Available by running >>> import this on the Python console.

• Beautiful is better than ugly.
• Explicit is better than implicit.
• Simple is better than complex.
• Complex is better than complicated.
• Flat is better than nested.
• Sparse is better than dense.
• Readability counts.
• Special cases aren’t special enough to break the rules.
• Although practicality beats purity.
• Errors should never pass silently.
• Unless explicitly silenced.
• In the face of ambiguity, refuse the temptation to guess.
• There should be one– and preferably only one –obvious way to do it.
• Although that way may not be obvious at first unless you’re Dutch.
• Now is better than never.
• Although never is often better than right now.
• If the implementation is hard to explain, it’s a bad idea.
• If the implementation is easy to explain, it may be a good idea.
• Namespaces are one honking great idea – let’s do more of those!
• Why? Why not?