categories | tags | Aimee's Blog
Aimee's Study Notes

It is updated automatically after each commit to the org-notes repo. It was last updated on Oct 09, 2021 05:00 UTC.


This page was created/modified in commit 0b974f7 "." on 2021-01-18.
Markdown source of this page

Learn Programming

categories: reading

tags: rust lisp programming cs


Description/Summary

Learning notes from books and lectures.

Content

Book: Code Complete

Abstract Data Types (ADTs)

An abstract data type is a collection of data and operations that work on that data. The operations both describe the data to the rest of the program and allow the rest of the program to change the data. The word “data” in “abstract data type” is used loosely. An ADT might be a graphics window with all the operations that affect it, a file and file operations, an insurance-rates table and the operations on it, or something else.

Understanding ADTs is essential to understanding object-oriented programming. Without understanding ADTs, programmers create classes that are “classes” in name only—in reality, they are little more than convenient carrying cases for loosely related collections of data and routines. With an understanding of ADTs, programmers can create classes that are easier to implement initially and easier to modify over time.

Thinking about ADTs first and classes second is an example of programming into a language vs. programming in one.

Abstract data types are exciting because you can use them to manipulate real-world entities rather than low-level, implementation entities. Instead of inserting a node into a linked list, you can add a cell to a spreadsheet, a new type of window to a list of window types, or another passenger car to a train simulation. Tap into the power of being able to work in the problem domain rather than at the low-level implementation domain!

Reasons to Create a Class

NASA’s Software Engineering Laboratory studied ten projects that pursued reuse aggressively (McGarry, Waligora, and McDermott 1989). In both the object-oriented and the functionally oriented approaches, the initial projects weren’t able to take much of their code from previous projects because previous projects hadn’t estab- lished a sufficient code base. Subsequently, the projects that used functional design were able to take about 35 percent of their code from previous projects. Projects that used an object-oriented approach were able to take more than 70 percent of their code from previous projects. If you can avoid writing 70 percent of your code by planning ahead, do it!

Notably, the core of NASA’s approach to creating reusable classes does not involve “designing for reuse.” NASA identifies reuse candidates at the ends of their projects. They then perform the work needed to make the classes reusable as a special project at the end of the main project or as the first step in a new project. This approach helps prevent “gold-plating”—creation of functionality that isn’t required and that unneces- sarily adds complexity.

Classes to Avoid

Book: Structure and Interpretation of Computer Programs

1.1 The Elements of Programming

1.1.8 Procedures as Black-Box Abstractions

1.2 Procedures and the Processes They Generate

Videos: MIT 6.001 Structure and Interpretation, 1986

Coupled with the book: Structure and Interpretation of Computer Programs

I like this lecture a lot: Lecture 3A: Henderson Escher Example

blur the line between what’s data and what’s a procedure.


This site is generated with ox-hugo for Emacs/Org-mode + hugo-bare-min-theme [Aimee's Study Notes]