Difficulty: Introductory | Prerequisites: Foundational Discoveries notes (sequence, selection, iteration)
Programming languages can be used to solve the same problems in fundamentally different ways. A programming paradigm is a style or approach to structuring code, and each paradigm shapes how you think about problems. This section covers four major paradigms: functional, imperative, object-oriented and service-oriented. Most real-world languages blend features from multiple paradigms, so understanding each one helps you read and write code across a wide range of tools and contexts.
Functional programming treats computation as evaluating mathematical functions and avoids changing state. Imperative programming uses step-by-step instructions that change a program's state. Object-oriented programming organises code around "objects" that bundle data and behaviour. Service-oriented programming structures applications as loosely coupled services that communicate over a network.
Programming paradigm
A fundamental style or approach to programming that dictates how code is structured and how problems are decomposed.
Think of it as the "philosophy" behind how you write a program.
Functional programming
A declarative paradigm that treats computation as the evaluation of mathematical functions. It avoids mutable state and side effects.
In simple terms, you describe what you want computed, not the steps to compute it, and the same inputs always produce the same outputs.
Declarative programming
A paradigm where the programmer specifies what the result should be, rather than how to achieve it. Functional programming is one form of declarative programming.
Imperative programming
A paradigm where the programmer writes step-by-step instructions (statements) that change the program's state. The name comes from the grammatical imperative mood: commands.
Think of it as giving a recipe: do this, then do that, then check this.
Object-oriented programming (OOP)
A paradigm organised around "objects," which bundle data (attributes/fields) and code (methods/functions) into a single unit. Objects interact with each other through their methods.
In simple terms, you model the world as a collection of things (objects), each with its own properties and abilities.
Attribute (field/property)
A piece of data stored inside an object. For example, a Car object might have attributes like colour, speed and fuel level.
Method
A function defined inside an object that can access and modify the object's attributes. For example, a Car object might have an accelerate() method.
Service-oriented architecture (SOA)
A paradigm that structures an application as a collection of loosely coupled "services," each performing a specific business function, communicating over a network.
Think of it as building a large system from independent specialist teams, each offering a service that others can call on.
Functional programming treats computation as the evaluation of mathematical functions. It avoids mutable state and changing data.
Declarative: you write expressions and declarations rather than step-by-step instructions
No side effects (ideally): a function's output depends only on its input, not on any external state
First-class functions: functions can be passed as arguments, returned from other functions and assigned to variables
Immutability: data, once created, is not changed. New data is produced by transforming existing data
Haskell, Erlang, Clojure, and parts of JavaScript, Python and Scala.
Functional programming is well suited to concurrent and parallel computing (because immutable data avoids many synchronisation problems), data transformation pipelines and mathematical or scientific modelling.
Imperative programming uses statements that change a program's state, step by step. It mirrors the way you would give commands to someone: "do this, then do that."
Statements over expressions: the program is a sequence of commands (assignments, loops, conditionals)
Mutable state: variables can be changed as the program runs
Explicit control flow: the programmer spells out the order of operations, including loops and branches
Imperative programming directly uses the three control structures (sequence, selection, iteration) that the Bohm-Jacopini theorem proved are sufficient for any computation. Most imperative languages implement these as statement blocks, if/else and while/for loops.
C, Pascal, Fortran, and the imperative subsets of Python, Java and JavaScript.
OOP organises code around "objects": units that bundle data (attributes) and behaviour (methods) together.
Objects: self-contained units combining data and the functions that operate on that data
Attributes (fields): the data an object holds (e.g. a Student object might have name, student_id, gpa)
Methods: the functions an object can perform (e.g. a Student object might have enrol(), drop_course())
Encapsulation: an object's internal data is accessed and modified through its methods, not directly from outside. This protects the data and hides implementation details
Interaction: OOP programs are built from objects that send messages to each other (call each other's methods)
Java, C++, C#, Python, Ruby, Swift.
OOP works well for large systems with many interacting components: GUIs, games, simulations, enterprise software. It encourages modular design, where each object has a clear responsibility.
Service-oriented programming structures applications as collections of loosely coupled "services," each performing a specific business function.
Service as the unit of design: each service handles one well-defined capability (e.g. payment processing, user authentication, inventory management)
Loose coupling: services communicate over standard protocols (typically HTTP/REST or message queues) and can be developed, deployed and scaled independently
Interoperability: services can be written in different languages and run on different platforms, as long as they agree on a communication protocol
Reusability: a service built for one application can be reused by others
Microservices architecture is a modern evolution of SOA, where services are made even smaller and more independently deployable. The core principle, building systems from independent, communicating services, is the same.
SOA suits large-scale enterprise applications and mission-critical systems where different teams build and maintain different parts of the system, and where components need to scale independently.
Students often think paradigms are mutually exclusive. Most modern languages support multiple paradigms. Python, for instance, supports imperative, functional and object-oriented programming.
"Functional programming means you cannot use variables" is a common misunderstanding. You can bind names to values. What you avoid is mutating those values after binding.
Students sometimes confuse objects and classes. A class is the blueprint; an object is an instance of that class. You write the class once and create as many objects from it as you need.
"SOA is just APIs" oversimplifies. SOA is an architectural approach to designing entire systems as interacting services, not simply exposing a few endpoints.
⚠️ Be able to define each of the four paradigms in one or two sentences
⚠️ Know the difference between declarative and imperative programming
⚠️ Be able to explain what an object is in OOP (data + methods) and what encapsulation means
⚠️ Understand that functional programming avoids mutable state and side effects
⚠️ Be prepared to match a short code example to its paradigm
True or False: Functional programming encourages changing variables as the program runs.
Fill in the blank: In OOP, data stored inside an object is called a(n) ________.
True or False: Imperative programming uses declarations rather than statements.
Fill in the blank: In service-oriented architecture, the unit of design is the ________.
True or False: Most modern programming languages support only one paradigm.
Answers: 1. False (it avoids mutable state). 2. Attribute (or field/property). 3. False (it uses statements). 4. Service. 5. False (most support multiple paradigms).
Q: What makes functional programming "declarative"?
A: In functional programming, you describe what the result should be (using expressions and function composition) rather than spelling out step-by-step instructions for how to compute it.
Q: How does imperative programming differ from functional programming?
A: Imperative programming uses statements that change mutable state in a defined sequence. Functional programming avoids mutable state and treats computation as evaluating functions whose output depends only on their input.
Q: In OOP, what is the difference between an attribute and a method?
A: An attribute is a piece of data stored inside an object (e.g. a car's colour). A method is a function defined inside the object that can access and modify its attributes (e.g. accelerate()).
Q: What is encapsulation in OOP?
A: Encapsulation is the practice of restricting direct access to an object's internal data, exposing it only through the object's methods. This protects the data from unintended changes and hides implementation details.
Q: Give a one-sentence definition of service-oriented architecture.
A: SOA is an approach to building applications as collections of loosely coupled services, each performing a specific business function and communicating over standard protocols.
Programming paradigms build directly on the foundational discoveries covered in the companion notes. The Bohm-Jacopini theorem's three control structures (sequence, selection, iteration) are the backbone of imperative programming. Functional programming connects to the mathematical side of CS, particularly lambda calculus and type theory. OOP concepts like encapsulation relate to computer security principles (restricting access, protecting data). SOA connects to databases and data mining: in a service-oriented system, individual services often own their own database.
Programming paradigms, functional programming, declarative programming, immutability, pure functions, side effects, first-class functions, Haskell, Erlang, imperative programming, statements, mutable state, control flow, C, Pascal, object-oriented programming, OOP, objects, classes, attributes, fields, properties, methods, encapsulation, inheritance, polymorphism, Java, C++, Python, service-oriented architecture, SOA, microservices, loose coupling, API, REST, enterprise software, CS 101, Arizona State University