docs: add slides for lecture 9

lectures/revealjs/09-oop-rest.adoc

+= OO Principles + REST APIs 
+:customcss: slides.css
+:icons: font
+:includedir: includes/
+:LECTURE_TOPIC: OO Principles + REST APIs 
+:LECTURE_NO: 9th Lecture
+
+include::{includedir}header.adoc[]
+
+[.smaller-80][.center-paragraph]
+IT1901 Fall 2024 - {LECTURE_NO}
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Overview
+[.smaller-80]
+- Administrative issues
+- Object Oriented Principles
+- REST APIs
+- Summary
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Administrative issues
+
+
+== Approaching Deadlines
+
+- Torsdag, 14. november / 23:59 
+** 3rd group deliverable
+
+
+== Remaining Lectures
+
+- w43 23rd Oct - Integration testing - Preparing sofware releases
+- w44 30th Oct - Guest lecture - current development practices in industry
+- w45 7th Nov - Questions and Answers lecture - Present individual report assignment
+
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Object Oriented Principles
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Object Oriented Design
+
+
+== Object Oriented Design
+
+“An object-oriented system is made up of interacting objects that 
+maintain their own local state and provide operations on that state. 
+The representation of the state is private and cannot be accessed directly 
+from outside the object. Object-oriented design processes involve 
+designing object classes and the relationships between these classes.” 
+(Sommerville: p 198)
+
+
+== Object Oriented Principles
+
+- Abstraction
+- Encapsulation
+- Inheritance
+- Polymorphism
+
+
+== Abstraction
+
+- hiding the internal data and implementation from the external world
+- hide complexity and show essential information
+- could be classified further 
+** data abstraction
+** process abstraction
+- abstract classes and interfaces
+
+
+== Encapsulation
+
+- integrating fields (data) and methods (behaviors) into a single unit 
+- fields are hidden from  other classes 
+- fields can only be accessed by the methods of the class in which they are found
+
+
+== Inheritance
+
+- mechanism that allows classes to acquire fields and behaviors from other class
+- the properties of the "parent" class are inherited by the "child" class
+
+== Polymorphism
+
+- the ability to perform a single action in different ways
+- differently stated -  have one interface but  have multiple implementations
+** overriding
+** overloading
+
+== Common issues OOD
+
+- External dependencies:
+** New requirements can produce changes in many places
+
+- Internal dependencies:
+** changes in a part of the code affect other parts
+** difficult to re-use code
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== SOLID principles
+
+== SOLID principles 
+
+- **S**ingle responsibility principle
+- **O**pen–closed principle
+- **L**iskov substitution principle
+- **I**nterface segregation principle
+- **D**ependency inversion principle
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Single responsibility principle
+
+
+== Single responsibility principle
+
+- A class should only have a single responsibility
+- A class should have one, and only one reason to change
+- Examples:
+** simpleexample2: JSON-serialization
+*** Latlong serializer
+*** Latlong deserializer
+
+
+== Single responsibility principle
+
+Applying this principle has as effects:
+
+- Smaller sized classes
+- Classes that are easier to:
+** understand
+** test
+** maintain
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Open–closed principle
+
+== Open–closed principle
+
+- Software entities should be open for extension, but closed for modification.
+- Example: JavaFX classes
+
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Liskov substitution principle
+
+== Liskov substitution principle
+
+- Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.
+
+
+== Liskov substitution principle (2)
+
+image::../images/lecture11/rectangle-square.png[canvas, size=contain]
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Interface segregation principle
+
+== Interface segregation principle
+
+- Many client-specific interfaces are better than one general-purpose interface.
+
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Dependency inversion principle
+
+
+== Dependency inversion principle
+
+- One should depend upon abstractions, not concretions.
+- e.g. Data access layer in between controler and domain layer
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== DRY Principle
+
+
+== Don't Repeat Yourself (DRY)
+
+- "Every piece of knowledge or logic must have a single, unambiguous representation within a system."
+- Andy Hunt and Dave Thomas in their book The Pragmatic Programmer
+
+[.smalled-40]
+https://en.wikipedia.org/wiki/Don%27t_repeat_yourself  
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== KISS Principle
+
+== Keep It Simple, Stupid (KISS)
+
+- write simple code
+- if classes / methods become lengthy and complicated you need to consider refactoring
+** extracting code in separate classes methods
+** eliminate redundant code
+
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Some useful considerations
+
+
+== Refactoring
+
+- work on the code without adding functionality
+- simplify and optimize
+- make it more maintainable and reusable
+
+== Refactoring (2)
+
+- find problem areas and improve
+** very long classes or methods
+** long list of parameters
+** confusing package structures
+** ...
+
+== Refactoring (3)
+
+- aim for short methods with simple control flow
+- avoid recursion (harder to understand the )
+- limit loops
+- limit variables to the smallest scope possible
+
+== Nesting
+
+- complex flow in methods is hard to understand
+- if you are beyond 2-3 levels you need to consider refactoring
+
+== Naming
+
+- use suggestive names
+- adhere to conventions
+- do not abbreviate
+- avoid single letter variables (y)
+- do not include types in names (intCount, bResult)
+
+== Naming (2)
+
+- do include units where needed ( delayInSeconds )
+- difficulty naming might indicate the need to rethink design
+- avoid naming classes Abstract... or Base...
+- avoid using an evergrowing "Utils" class
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== UML Diagrams
+
+[.smaller-80]
+== UML - Unified Modelling Language
+
+- 13 diagrams that show various perspectives on the system
+
+- purpose:
+** Stimulate and focus discussion about an existing or a new system
+** Document an existing system
+** Detailed description to generate a system
+
+- informal use of UML:
+** “I do not find UML to be useful during the design process itself and prefer informal notations that are quicker to write and that can be easily drawn on a whiteboard.” (Sommerville, s. 175)
+
+== !
+
+image::../images/lecture13/uml-diagrams.png[canvas, size=contain]
+
+[.smaller-20]
+[.left-30] 
+Fowler, Martin., (2003). UML distilled: a brief guide to the standard object modeling language. Pearson Education
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Package diagram
+
+[.smaller-80]
+== Package diagram
+
+- Gir en oversikt over avhengigheter mellom moduler av et system
+- Viser “pakker” - typisk grupper av klasser
+- Viser avhengigheter mellom pakker/moduler
+- Hver klasse er kun medlem av en “pakke”
+- Pakker representerer et hierarkisk navnerom, så hver klasse innen en pakke må ha et unikt navn
+- En pakke skal ikke kunne være medlem av flere moduler
+
+[.smaller-30]
+Fowler, Martin., (2003). UML distilled: a brief guide to the standard object modeling language. Pearson Education.
+
+
+== !
+
+image::../images/lecture13/package-diagram.png[canvas, size=contain]
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Class diagram
+
+
+== Class diagram
+
+- Viser typer objekter i systemet og statiske relasjoner mellom dem
+- Enkleste form: Klassenavn i bokser
+- Viser egenskaper (attributter, assosiasjoner) og operasjoner (metoder) for en klasse
+
+
+[.smaller-30]
+Sommerville: Software Engineering, Pearson, 2016. 10th Edition, page 149.
+
+== !
+
+image::../images/lecture13/class-diagram-1.png[canvas, size=contain]
+
+[.smaller-30]
+[.left-30]
+Kilde: Yngve Lindsjørn, Universitetet i Oslo: IN2000: Kravhåndtering, modellering & design.
+
+
+== !
+
+image::../images/lecture13/class-diagram-2.png[canvas, size=contain]
+
+
+[.smaller-30]
+[.left-30]
+Kilde: Yngve Lindsjørn, Universitetet i Oslo: IN2000: Kravhåndtering, modellering & design.
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Sequence diagram
+
+[.smaller-80]
+== Sequence diagram
+
+- Brukes for å analysere samarbeid mellom objekter
+- Modellerer interaksjoner mellom aktører og objekter i et system og interaksjon mellom objekter i et scenarie
+- Aktører og objekter finnes øverst i diagrammet
+- Tidsakse nedover i diagram
+- Piler indikerer interaksjon mellom objekter
+- Annoterte piler indikerer metodekall
+- Kan vise alternative sekvenser
+
+[.smaller-30]
+Sommerville: Software Engineering, Pearson, 2016. 10th Edition, page 146.
+
+== !
+
+image::../images/lecture13/sequence.png[canvas, size=contain]
+
+== !
+
+```puml
+
+actor User
+User -> "~#newTodoItemButton: Button" as newTodoItemButton: click
+newTodoItemButton -> TodoController: handleNewTodoItemAction
+TodoController -> "~#newTodoItemText: TextField" as newTodoItemText: getText
+TodoController -> TodoList: addTodoItem
+TodoList -> TodoList: fireTodoListChanged
+TodoList -> TodoListListener: todoListChanged
+TodoListListener -> TodoController: autoSaveTodoList
+TodoListListener -> TodoController: updateTodoListView
+
+```
+
+
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== REST APIs
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Architectural styles
+
+== Architectural styles
+
+An architectural style is a conceptual specification of how a certain
+system will be structured and function. 
+
+== Architectural styles
+
+- monolithic applications
+- 3-tier applications
+- REST
+
+== layers vs. tiers
+
+- sometimes the terms are used interchangeably
+- there is a difference
+** layers - logical separation
+** tiers - physical separation
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== monolithic applications
+
+== monolithic applications (1)
+
+- All the functionality is packed in a single software unit
+** ui
+** logic
+** data
+- designed without modularity
+- also called single-tiered application
+
+== !
+
+image::../images/lecture12/1tier.png[canvas, size=contain]
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== 3-tier applications
+
+== !
+
+image::../images/lecture12/3tier.png[canvas, size=contain]
+
+== 3-tier applications (2)
+
+- application where the various functions are separated
+** presentation tier (UI / frontend)
+** logic tier (business tier)
+** data tier (data storage + data access)
+- also called 3-layer
+- application is modular 
+
+== 3-tier applications (3)
+
+- ability to update / replace just parts of the application
+- ability to independently scale the layers
+- ability to re-use layers
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== REST
+
+[.smaller-80]
+== REST
+- **RE**presentational **S**tate **T**ransfer (REST)  
+- architectural style involving use of Web Services 
+- set of constraints are applied 
+** client server
+** statelessness (no client context is stored on the server side)
+** cacheability (responses state if they can be cached or not)
+** uniform interface
+** layered system (adding layers like proxy or load balancer)
+
+
+== REST (cont.)
+
+- Web services that implement REST are called RESTful APIs
+- a base URI, example: https://gitlab.stud.idi.ntnu.no/api/v4
+- standard HTTP methods (e.g., GET, POST, PUT, PATCH and DELETE);
+- data formats for requests and responses (json, xml, etc)
+
+== !
+
+image::../images/lecture12/itodo.png[canvas, size=contain]
+
+== !
+
+image::../images/lecture12/mtodo.png[canvas, size=contain]
+
+
+== !
+
+image::../images/lecture12/rtodo.png[canvas, size=contain]
+
+
+== HTTP requests
+ - **H**yper**t**ext **T**ransfer **P**rotocol (HTTP)
+ - clients (e.g. browser) send requests
+ - servers (web site / service) send responses
+
+== HTTP Request message
+ 
+ - a request line `GET / HTTP/1.1`
+ - request headers - `User-Agent`, `Accept`, `Content-Type` etc.
+ - an empty line (containing only a `carriage return` and a `line feed`)
+ - an optional message body
+
+== HTTP Methods
+
+- HTTP specification defines `methods` to indicate what action is expected from the server
+** GET, HEAD, OPTIONS
+** POST, PUT, PATCH
+** DELETE
+
+== APIs
+
+- **A**pplication **P**rogramming **I**nterface
+- "Glue" that makes possible different pieces of software to interoperate
+- It is meant to be machine readable / usable
+- APIs are everywhere - at different levels - software libraries, operating system, applications, web services etc.
+
+== APIs (2) 
+
+- typically a set of calls or requests, expected call format, expected response format, data structures
+- separate the implementation from the interface
+- allow programs in one language to use functionality written in some other language
+- cater to modular software
+
+
+== Security considerations
+
+- CORS (Cross-Origin Resource Sharing)
+** headers `Access-Control-Allow-Origin` 
+- Authentication (Basic Auth,  OAuth etc)
+- HTTPS (HTTP over TLS)
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Modularity
+
+== Modularity
+
+- means for splitting a large problems into parts
+** distribute and isolate work
+** distribute artifacts for use and reuse
+- more or less supported by tools and languages
+** maven - modular build
+** java - strong encapsulation
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Modularity with maven
+
+== Modular projects with Maven
+
+- main "parent" module with common configuration
+- sub-modules with dependencies
+** libraries (and plugins) are modules
+** own modules follow architecture
+- manages build tasks
+** sequenced according to dependencies
+** execute in appropriate context e.g. classpath
+
+== Modular projects with Maven
+
+- use of inheritance
+- parent `pom` has configuration that is inherited by modules' `pom`
+- the descendent `pom` can override inherited configuration elements
+- descendant `pom` inherits most elements with the exception of things like artifactid, name which are used to identify the parent `pom`
+
+== Modular projects with Maven (2)
+
+- reduce complexity and size of individual build files
+- reliably use consistent versions for dependencies and plugins 
+
+== Parent pom example
+
+[.smaller-40]
+```xml
+<?xml version="1.0" encoding="UTF-8" ?>
+
+<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
+    <modelVersion>4.0.0</modelVersion>
+
+    <groupId>it1901.todolist</groupId>
+    <artifactId>parent</artifactId>
+    <version>0.0.1-SNAPSHOT</version>
+    <packaging>pom</packaging>
+
+    <properties>
+        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
+    </properties>
+
+    <dependencyManagement>
+        <dependencies>
+            <dependency>
+               ...
+            </dependency>
+            ...
+        </dependencies>
+    </dependencyManagement>
+
+    <build>
+        <pluginManagement>
+            <plugins>
+                <plugin>
+      				...
+                </plugin>
+                ...
+            </plugins>
+        </pluginManagement>
+    </build>
+
+    <modules>
+        <module>core</module>
+        <module>fxui</module>
+    </modules>
+</project>
+
+```
+
+== Descendant pom example
+
+[.smaller-40]
+```xml
+<?xml version="1.0" encoding="UTF-8" ?>
+
+<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
+    <modelVersion>4.0.0</modelVersion>
+
+    <parent>
+        <groupId>it1901.todolist</groupId>
+        <artifactId>parent</artifactId>
+        <version>0.0.1-SNAPSHOT</version>
+    </parent>
+
+    <artifactId>fxui</artifactId>
+
+    <dependencies>
+		<dependency>
+			...
+		</dependency>
+		...
+    </dependencies>
+
+    <build>
+        <plugins>
+            <plugin>
+                ...
+            </plugin>
+            ...
+        </plugins>
+    </build>
+</project>
+
+```
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Modularity with Java
+
+== Java modules
+
+[.smaller-80]
+* corresponds to a set of packages
+* strong encapsulation
+** explicitly export packages
+** explicitly state dependencies
+** also enforced during runtime
+* advantages
+** avoid relying on internals
+** build lighter apps
+* disadvantages...
+
+== core - module-info.java
+
+```java
+module todolist.core {
+    requires transitive com.fasterxml.jackson.databind;
+
+    exports todolist.core;
+    exports todolist.json;
+}
+```
+
+== core - https://gitlab.stud.idi.ntnu.no/it1901/todo-list/-/blob/master/todolist/core/src/main/java/module-info.java[module-info.java]
+
+* module name
+** how to get (guess) name of libraries 
+* **requires** - what this module needs
+** **transitive** - others will need this too
+** **exports** - what others may use
+
+== fxui - https://gitlab.stud.idi.ntnu.no/it1901/todo-list/-/blob/master/todolist/fxui/src/main/java/module-info.java[module-info.java]
+
+```java
+module todolist.ui {
+    requires com.fasterxml.jackson.databind;
+
+    requires java.net.http;
+
+    requires javafx.base;
+    requires javafx.controls;
+    requires javafx.fxml;
+
+    requires todolist.core;
+    requires fxutil;
+
+    opens todolist.ui to javafx.graphics, javafx.fxml;
+}
+```
+
+== fxui - module-info.java
+
+* **opens** ... *to* - allow getting runtime info about classes using so-called _reflection_
+** fxml
+** REST frameworks
+** test frameworks
+* **--add-opens** command line option
+** support unmodularized mode
+
+
+
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Summary
+
+
+include::{includedir}footer.adoc[]
\ No newline at end of file