Abstraction #

• A generalization of something too complext to be dealt with in its entirety
• For humans not computers
  • It is a techinque we use to compensate for the relatively puny capacity of our brains
  • There aren’t enough neurons (or connections) in our brain to process the rich detail around us during a single moment in time
• Successful designers developer abstractions and hierarchies of abstractions for complex entities and move up and down this hierarchy with splendid ease.

Examples

• Anytime we see a simple interface covering a more complex system, you should think “abstraction”
  • A car is a very complex machine but the interface is simple
  • A video game controller only has a few buttons, but underneath the controller is a complex mechanism
  • A programming language can be fairly simple, but it translates the instructions you write into machine code, which is complex
• Data types are abstractions
  • A linked list abstracts a collection of connected nodes
  • A node abstracts the detail of a structure holding an instance of a primitive data type and a pointer
• Functions are abstractions
  • A function abstracts the details of an algorithm, with a simple name e.g. fahrenheitToCentrigrade()

Form consistent abstractions

• Abstraction is the ability to engage with a concept while safely ignoring some of its details
• Base classes and interfaces are abstractions
  • i.e. UIComponent (or any GUI toolkit)
  • Mammal (classic superclass when discussing OO)
  • The interface defined by a class is an abstraction of what the class represents
• You shouldn’t have to look at the method body code to understand what this method does
  • someObject.toString()

What is OO?

• Procedural paradigm:
  • Software is organized around the notion of procedures
  • Procedural abstraction
    • Works as long as the data is simple
  • Adding data abstractions
    • Groups together the pieces of data that describe some entity
    • Helps reduce the system’s complexity, such as Records and structures
• Object oriented paradigm:
  • Organizing procedural abstractions in the context of data abstractions

OO paradigm

An approach to the solution of problems in which all computations are performed in the context of objects.

• The objects are instances of classes, which:
  • are data abstractions
  • container procedural abstractions that operate on the objects
• A running program can be seen as the collectino of objects collaborating to perform a given task

What is a class?

• A unit of abstraction in an OO program
• Represents similar objects
  • its instances
• A kind of software module
  • Describes its instances’ structure (properties)
  • contains methods to implement their behavior
• A blueprint
  • we can use this blueprint to create new objects
• Are a container in which we define the properties and behaviors of the objects that will become our system
• faciliate the organization of concepts within the domain of the system
• We think of them as having responsibilities, but vlasses are an organization tool, its really the objects that have the responsibilitiy
• Classes are for the developer, they are the organizational bridge between our understanding of the software system and its runtime behavior.

Whats an object?

• A chunk of structured data in a running software system
• Has properties
  • represents its state
• Has behavior
  • how it acts and reacts
  • May simulate the behavior of an object in the real world

• An object is a bundle of capabilities
• It is defined by what it can do
  • not how it does it
• Practically, this means an object is defined by the messages that it can send and receieve
• The methods that handle these messages comprise the sole interface to the outside world
• Yes, objects have data, but the makeup of that data should be irrelevant
• Focus on what objects can do!

The prime directive

Never ask an object for information that you need to do something; rather, ask the object that has the information to do the work for you!

Modularity #

The goal of design is to partition the system into modules and assign responsibility among the components

Many languages embrace the concept of a module

• Packages are named using the concatenation of the enclosing packagee names
• Types (classes) must declare what package they belong to
  • Otherwise they are placed in the “default” (unnamed) package
• Packages name become part of the class name, for following class has the full name solarSystem.planets.earth.Human

package solarSystem.planets.earth;

// a class defining species originating on Earth
public class Human
{
  // class declarations and methods
}

• The goal of design is to partition the system into modules and assign responsibility among the components in a way that
  • High cohesion within modules, and
  • Loose coupling between modules
• Modularity reduces the total complexity a programmer has to deal with at anyone time assuming:
  1. Functions are assigned to modules in a way that groups similar functions together (separation of concerns), and
  2. There are small, simple, well-defined interfaces between modules (information hiding)
• The principles of cohesion and coupling are probably the most important design principles for evaluating the effectiveness of a design

Encapsulation #

Access modifiers

• public
  • any class has acesss
• protected
  • Only code in the package, or subclasses can access
• (blank) default is called package protected
• private
  • Only code written in the class can access
  • Inheritance still occurs

So do we need getters and setters in example 1? No. The class is really just a structure. If the class were imbued with some more behavior, then we should revisit this question.

So back to the point example, we are not hiding information at all. With the balance example, we agree there should be something hidden (the balance).