An Introduction to C++ Lecture 05: Programming paradigms

Priv. Doz. Dr. Roger Wolf http://ekpwww.physik.uni-karlsruhe.de/~rwolf/

INSTITUTE OF EXPERIMENTAL PARTICLE PHYSICS (IEKP) – PHYSICS FACULTY

An Introduction to C++

Lecture 05: Programming paradigms

Roger Wolf23. June 2021

http://ekpwww.physik.uni-karlsruhe.de/~rwolf/



Part 1:

Growing software programs

1/22



The world of software…

● A universe of possibilities.

● Everything that can be thought in a computer language can be realized.

● If more people speak the same (standardized) language such realizations can be shared, discussed and exchanged.

2/22



Growing software

● Often small projects grow into larger ones. Very quickly software projects may comprise several ten thousands lines of code and spread over many files (see Lecture-02).

● Sometimes the scope of a project changes/widens (depending on the preceding planning phase).

● Often software requires (sometimes substantial) re-writing during its life time (“code re-factorization”). Sometimes the software is even completely re-written in a new language (e.g. translated from ‘FORTRAN to C++)

3/22


http://ekpwww.physik.uni-karlsruhe.de/~rwolf/teaching/courses/CppIntro/Cpp-VL-02-CodeManagement.pdf


Program != Implementation

● Note: a program is never defined by the way it is implemented. It is always defined by its functionality.

● Excellent programmers do not imply excellent programs.

● Excellent programs can be written in horrible code. (Of course good code helps to produce good programs).

● Remember the discussion about “bugs” in Lecture-02. A good program, that has been extensively tested and serves a use case with a minimal set of bugs (or “unwanted features”) is an extremely valuable achievement.

● This is why NASA code usually is many decades old and changes only under strictest security conditions.

● The same is true for software for medical applications (e.g. steering software for heavy ion therapy).

4/22


http://ekpwww.physik.uni-karlsruhe.de/~rwolf/teaching/courses/CppIntro/Cpp-VL-02-CodeManagement.pdf


What is a good program?

A good program

5/22




Easy to use.

A good program

5/22




Easy to use.

Easy to adapt/expand.

A good program

5/22




Addresses all use cases.

Easy to use.


A good program

5/22





Easy to use.


A good program

Free of “bugs” or “unwanted features”,

no crashes.

5/22





Free of “bugs” or “unwanted features”,

no crashes.

Easy to use.


A good program

Portable, w/o exotic hardware or OS requirements.

5/22



What is a good implementation?

A good implementation

6/22




i.e. the executable is moderate in use of disc space or RAM


Space efficient.

6/22






Space efficient. CPU efficient.

i.e. the executable is fast during execution time

6/22







Easy to maintain/ extend


6/22








Easy to read/understand


6/22








Easy to read/understand


● Unless you are an adapt of a community of programming freaks, if you have a complicated and a simple solution to a task, go for the simple one.

● Do not overload your code with comments, but use them. When using them be clear and complete.

7/22



Take your time to make up your mind…

● To prevent major factorizations, before you start coding, the design phase of your program plays a major role.

● Questions to address include:

● How large shall the program be, what shall it be able to do?

● How much time/energy should go into its development?

● What language is best suited for the implementation (C, C++, python, FORTRAN, shell, perl, …)? Certain languages support certain requirements better than others.

● What programming paradigm is best suited for your development?

8/22



The life cycle of your software development

● You can coarsely separate the development of a program into three phases:

Design phase Implementation phase

Testing phase

9/22






Testing phase

● Desired features, ● Choice of language, ● Choice of paradigm,…

9/22






Testing phase


9/22

● Translate design choices into language,

● Reconsider design to adapt to language restrictions…






Testing phase ● Check that implementation meets the requirements…

● Reconsider design or fix implementation flaws if necessary…


● Translate design choices into language,

● Reconsider design to adapt to language restrictions…

9/22




Part 2:

Programming paradigms

10/22



Thinking in tasks…

● How you would naively start your program as a beginner.

● Start from top, end at bottom, address one problem after the other, as they appear.

● This is how language processing/thinking usually works in most (male) brains.

● This is how your special and personal use case can be implemented with least complications.

● This can be suited for small (encapsulated) applications with very little development time (→ scripts, well supported e.g. by bash, shell, python, …).

11/22



Thinking in functions/procedures…

● How C and any modern language are organized.

● Identify functionalities, encapsulate them in functions.

● Never write the same procedural code twice into your program if you can put it into a function.

● Naturally supported by C, C++, python, …

12/22



Thinking in objects…

● Identify the objects that are part of your project.

● Identify their functionality and what consequences it has for their environment (i.e. other objects in your implementation).

● The way the objects act with their environment defines the interface that must be “known to the public”.

● Every part of your implementation that is not mapped to an interface can be “kept private” and hidden away from the public.

● Naturally supported by every object-oriented language, like e.g. C++, python, …

13/22



Abstraction and inheritance

● An object-oriented view to my car:

body

light

wheel

Object

What makes a car. engine

14/22





body

light

wheel

● Drives the car● Requires fuel

● Lights the environment● Requires power● Increases visibility of car

● Turns● Moves car

● Hosts persons

Interface

What the other parts of the car need to know about the object.

engine

14/22





body

light

wheel

● Drives the car● Requires fuel

● Lights the environment● Requires power● Increases visibility of car

● Turns● Moves car

● Hosts persons

Attributes

The important characteristics of an object.

engine

Car relevant attribute of “wheel”.

14/22






Discussion of programming paradigms

Task-oriented: ● Easiest to meet

special features.● Fastest to implement.

Object-oriented: ● Increase abstraction level.● Improve portability of code

(with well defined interfaces).

15/22

Procedure-oriented: ● Reduce redundancies.● Reuse functions.

Back to slide 20



Discussion of programming paradigms

Task-oriented: ● Easiest to meet

special features.● Fastest to implement.

● Object-orientation does not automatically provide the best suited solution to any problem. E.g. if you have difficulties formulating your problem in objects it most probably is not…

Object-oriented: ● Increase abstraction level.● Improve portability of code

(with well defined interfaces).

Procedure-oriented: ● Reduce redundancies.● Reuse functions.

15/22



Which paradigm fits my problem?

● Problem-1: you need a program that you can easily execute to archive a working directory on a remote server. It should clean the working directory from obsolete files, so that it only contains .h and .cc files, pack the directory into a singe .tar file and execute the copy to the remote server.

16/22




● Answer:

16/22

Shell script

● Problem-1: you need a program that you can easily execute to archive a working directory on a remote server. It should clean the working directory from obsolete files, so that it only contains .h and .cc files, pack the directory into a singe .tar file and execute the copy to the remote server.



● Problem-2: you need a program to perform a scan of a user-defined likelihood function to calculate a probability profile and eventually determine the minimum for a fit.

Which paradigm fits my problem?17/22




● Answer:


Likelihood

Poisson

Gaussian

Basic functions

Numerical derivative

Newton minimizer Alternative

minimizer Likelihood scan

Set of functions to build up the likelihood:

A set of minimizers:

● Step through the range of validity of the likelihood function .

● Evaluate likelihood function in a fine grid and print to std::out.

● Run minimizer to find best fit value.

main

17/22

C program




● Answer:


Likelihood

Poisson

Gaussian

Basic functions

Numerical derivative

Newton minimizer Alternative

minimizer Likelihood scan

Set of functions to build up the likelihood:

A set of minimizers:

● Step through the range of validity of the likelihood function .

● Evaluate likelihood function in a fine grid and print to std::out.

● Run minimizer to find best fit value.

main

17/22

C program

C is even better suited if you have to dig deep into the architecture of

you computer …



● Problem-3: you need a program to draw circles, boxes, triangles and lines with different line and fill color on a canvas. For each object it should allow to return the corner or endpoints of the drawn object in absolute and relative coordinates. At the end it should allow to save the canvas in different output format, among those a compact program internal format.

Which paradigm fits my problem?18/22




● Answer:


CanvasLine

● Has coordinates.● Returns absolute

coordinates.● Returns relative

coordinates.

Box

Triangle

Circle

● Is localized by a point.● Consists of lines.● Can be filled.● Has a radius.

Point● Defines coord’s.● Draws objects.● Can be saved to

a file.

Saver

● Takes a canvas.● Writes canvas to

file. png

pdfown

LineAttrFillAttr

18/22

C++ program




● Answer:


CanvasLine

● Has coordinates.● Returns absolute

coordinates.● Returns relative

coordinates.

Box

Triangle

Circle

● Is localized by a point.● Consists of lines.● Can be filled.● Has a radius.

Point● Defines coord’s.● Draws objects.● Can be saved to

a file.

Saver

● Takes a canvas.● Writes canvas to

file. png

pdfown

LineAttrFillAttr

18/22

C++ program

C++ is even better suited if you want your program easy to maintain and to

port, and if you have more than one person working on it …




Part 3:

Programming styles

19/22



● Assume that the final list of features of a project is not yet fully defined at the beginning of a development and might still change during the development phase (compare to slide 15).

Extreme programming (XP)

● The final product is reached via an iterative process of defining – testing – assessing – and integrating new features.

● Often the programmer is not an expert in the features that a program should have, a client is not expert in programming.

20/22


https://en.wikipedia.org/wiki/Extreme_programming


Test-oriented programming

● Test-oriented programming considers the test in the fist place.

● Each feature requires a test, at least in the intended use case.

● Implement each feature together with this test to be sure that it works as intended.

● The usefulness is obvious – whenever you develop your own code you should make this a common habit. All your exercise solutions have been created that way…

21/22



Summary

● What defines a good program.

● What defines a good implementation.

● Development phases of a project.

● Programming paradigms.

● What is object orientation.

● Good programming style.

22/22


Documents

An Introduction to C++ Lecture 05: Programming paradigms