Object oriented design principles

IT1901 Fall 2020 - 12th Lecture

Partially based on slides from Torgeir Dingsøyr and Hallvard Trætteberg

Overview

  • OOD - SOLID, DRY

  • UML Diagrams

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

  • Encapsulation

  • Abstraction

  • Inheritance

  • Polymorphism

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

SOLID principles

SOLID principles

  • Single responsibility principle

  • Open–closed principle

  • Liskov substitution principle

  • Interface segregation principle

  • Dependency inversion principle

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

Open–closed principle

Open–closed principle

  • Software entities should be open for extension, but closed for modification.

  • Example: JavaFX classes

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.

Interface segregation principle

Interface segregation principle

  • Many client-specific interfaces are better than one general-purpose interface.

Dependency inversion principle

Dependency inversion principle

  • One should depend upon abstractions, not concretions.

  • e.g. Data access layer in between controler and domain layer

DRY Principle

Don’t Repeat Yourself (DRY)

"Every piece of knowledge or logic must have a single, unambiguous representation within a system."

https://en.wikipedia.org/wiki/Don%27t_repeat_yourself

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

UML

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)

Fowler, Martin., (2003). UML distilled: a brief guide to the standard object modeling language. Pearson Education

Package diagram

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

Fowler, Martin., (2003). UML distilled: a brief guide to the standard object modeling language. Pearson Education.

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

Sommerville: Software Engineering, Pearson, 2016. 10th Edition, page 149.

Kilde: Yngve Lindsjørn, Universitetet i Oslo: IN2000: Kravhåndtering, modellering & design.

Kilde: Yngve Lindsjørn, Universitetet i Oslo: IN2000: Kravhåndtering, modellering & design.

Sequence diagram

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

Sommerville: Software Engineering, Pearson, 2016. 10th Edition, page 146.

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

Summary

Norwegian University of Science and Technology