SC‐24sp‐2024‐04‐22‐Morning - TheEvergreenStateCollege/upper-division-cs-23-24 GitHub Wiki

Abstraction

Rust Strings

https://rust-book.cs.brown.edu/ch08-02-strings.html

Rust Playground

https://play.rust-lang.org

City Addresses

https://github.com/TheEvergreenStateCollege/upper-division-cs/tree/main/sc-24sp/assignments/ppham/city-addresses https://sive.rs/jadr

Discussion Week 04 Assignment

https://canvas.evergreen.edu/courses/6250/assignments/119101

Abstract Data Types and Abstraction

Adapted from MIT's 6.005: Software Construction

Overall goals in studying software construction:

  • Safe from bugs Correct today and correct in the unknown future.

  • Easy to understand Communicating clearly with future programmers, including future you.

  • Ready for change Designed to accommodate change without rewriting.

Objectives

In Week 04's class we introduce two ideas:

  • Abstract data types
  • Representation independence

In this reading, we look at a powerful idea, abstract data types, which enable us to separate how we use a data structure in a program from the particular form of the data structure itself.

Abstract data types address a particularly dangerous problem: clients making assumptions about the type’s internal representation. We’ll see why this is dangerous and how it can be avoided. We’ll also discuss the classification of operations, and some principles of good design for abstract data types.

We have covered Rust modules briefly in Week 03 and will review two concepts here which give us a very general and flexible means of access control in Rust.

  • the pub keyword, which makes a member of a smaller scope visible and usable to a bigger scope

For more details about access control in Rust

What Abstraction Means

Abstract data types are an instance of a general principle in software engineering, which goes by many names with slightly different shades of meaning. Here are some of the names that are used for this idea:

Abstraction

  • Omitting or hiding low-level details with a simpler, higher-level idea.

Modularity

  • Dividing a system into components or modules, each of which can be designed, implemented, tested, reasoned about, and reused separately from the rest of the system.

Encapsulation

  • Building walls around a module (a hard shell or capsule) so that the module is responsible for its own internal behavior, and bugs in other parts of the system can’t damage its integrity.

Information hiding

  • Hiding details of a module’s implementation from the rest of the system, so that those details can be changed later without changing the rest of the system.

Separation of concerns.

  • Making a feature (or “concern”) the responsibility of a single module, rather than spreading it across multiple modules.

As a software engineer, you should know these terms, because you will run into them frequently. The fundamental purpose of all of these ideas is to help achieve the three important properties that we care about: safety from bugs, ease of understanding, and readiness for change.

User-Defined Types

In the early days of computing, a programming language came with built-in types (such as integers, booleans, strings, etc.) and built-in procedures, e.g., for input and output. Users could define their own procedures: that’s how large programs were built.

A major advance in software development was the idea of abstract types: that one could design a programming language to allow user-defined types, too. This idea came out of the work of many researchers, notably Dahl (the inventor of the Simula language), Hoare (who developed many of the techniques we now use to reason about abstract types), Parnas (who coined the term information hiding and first articulated the idea of organizing program modules around the secrets they encapsulated), and here at MIT, Barbara Liskov and John Guttag, who did seminal work in the specification of abstract types, and in programming language support for them – and developed the original 6.170, the predecessor to 6.005. Barbara Liskov earned the Turing Award, computer science’s equivalent of the Nobel Prize, for her work on abstract types.

The key idea of data abstraction is that a type is characterized by the operations you can perform on it. A number is something you can add and multiply; a string is something you can concatenate and take substrings of; a boolean is something you can negate, and so on. In a sense, users could already define their own types in early programming languages: you could create a record type date, for example, with integer fields for day, month, and year. But what made abstract types new and different was the focus on operations: the user of the type would not need to worry about how its values were actually stored, in the same way that a programmer can ignore how the compiler actually stores integers. All that matters is the operations.

In Rust, built-in types are those that are defined by language keywords that cannot be extended by the user.

You can define your own user-defined types with the struct or type keywords.

You can also import and use types defined in other crates (the Rust term for a reusable package or library of code) including those in the standard library crate std.

⚠️ **GitHub.com Fallback** ⚠️