11-solid-uml.adoc

Object oriented design principles

IT1901 Fall 2023 - 11th Lecture

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

Overview

• OOD - SOLID, DRY

• Some useful considerations

• UML Diagrams

• Summary

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

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.

Liskov substitution principle (2)

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."

• Andy Hunt and Dave Thomas in their book The Pragmatic Programmer

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

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

UML Diagrams

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

| IT1901 - 11th Lecture | OOP SOLID + UML