iCSC2010
Living OO Design: Design Patterns and Best
A Series of two lectures

Lecturers:
Tim Muenchen Bergische Universität Wuppertal - Germany

A few questions

  • How to transmit design ideas and concepts to other developers?

  • What is "good" software design, what can I do to make my design "good"?

  • What should I avoid in my design?

  • How to benefit from existing designs without reinventing the wheel?

  • How can I learn from other's mistakes?

  •  

 

All the answers at iCSC

In High Energy Physics, as in most areas of Science, using Computers to simulate, analyse and interpret physical data has become indispensable in the last decades, as the sheer amount of data one has to process has grown to dimensions difficult to handle manually. On top of that, the usage of object orientation is on the advance, replacing legacy programming languages like Fortran by modern ones like (among others) C++, Java and Python.

 

Though, one can not just carry programming style and concepts from procedural languages to object oriented languages and hope to benefit from the advantages of this new programming paradigm. Instead, there are numerous things to keep in mind to produce working, error-free and performing - but also understandable, maintainable and expandable - object oriented software designs.

 

This series of two lectures aims to sensitize the "object oriented programming physicist" to things he should be aware of and keep in mind to fully utilize the OO-paradigm.


 

Targeted audience :

This series of two lectures targets physicists designing and implementing  physics analysis code, event generators and the like in object-oriented  languages like C++, as well as junior developers of software infrastructure  libraries used at CERN. On top of that, every interested programmer can benefit from the concepts presented in these lectures.

.

 

Series: Living OO Design
Lecture: Introduction to UML for Developers and OO Best Practices

A few questions addressed in the lecture

Monday 8 March

 

10:00 10:55

Lecture
1

Introduction to UML for Developers and OO Best Practices

 

Tim Muenchen
Bergische Universität Wuppertal - Germany

Introduction to the series of two lectures
In High Energy Physics, as in most areas of Science, using Computers to simulate, analyse and interpret physical data has become indispensable in the last decades, as the sheer amount of data one has to process has grown to dimensions difficult to handle manually. On top of that, the usage of object orientation is on the advance, replacing legacy programming languages like Fortran by modern ones like (among others) C++, Java and Python.

 

Though, one can not just carry programming style and concepts from procedural languages to object oriented languages and hope to benefit from the advantages of this new programming paradigm. Instead, there are numerous things to keep in mind to produce working, error-free and performing - but also understandable, maintainable and expandable - object oriented software designs.

 

This series of two lectures aims to sensitize the "object oriented programming physicist" to things he or she should be aware of and keep in mind to fully utilize the OO-paradigm.

 

First lecture:
Introduction to UML for Developers and OO Best Practices

In this lecture, a powerful tool to express, communicate and record software design concepts, ideas and structures is briefly presented: the Universal Modeling Language.

 

Albeit being a complex and complete language to describe most aspects of (not only) software design, we will focus on the single most useful part of the UML when talking about OO best practices and patterns: the Class Diagram. This is then used in all of the rest of the series to visualize the concepts presented.

 

The main part of the lecture, then, focuses on ten best practices every OO-developer should know. The best practices and the reasons for them being crucial are described and deepened by examples and anecdotes.

 

Audience and benefits
This series of two lectures targets physicists designing and implementing  physics analysis code, event generators and the like in object-oriented languages like C++, as well as more junior developers of software infrastructure libraries used at CERN.

On top of that, every interested programmer can benefit from the concepts presented in these lectures.

 

In this first lecture, attendees will be sensitized to things to know and keep in  mind when designing software systems to ensure the best possible quality of  systems in terms of maintainability, flexibility and extensibility, comprehensibility and stability.

You will learn about a few simple rules to adhere that will help in make your design better in respect to those criteria, and what to avoid in designing software.

 

Before that, the UML class diagram is introduced briefly as means to communicate design concepts and to visualize the Best Practices presented in this lecture, and the Design Patterns in lecture 2.

 

Pre-requisite
Attendees should have basic knowledge about object-oriented programming, concepts and idioms, as well as object-oriented programming languages like C++ and Java."

 

 

Series: Living OO Design

Lecture: Design Patterns and Anti-Patterns

A few questions addressed in the lecture

Monday 8 March

11:05 12:00

Lecture 2

Design Patterns and Anti-Patterns

Tim Muenchen
Bergische Universität Wuppertal - Germany

Introduction to the series of two lectures

In High Energy Physics, as in most areas of Science, using Computers to simulate, analyse and interpret physical data has become indispensable in the last decades, as the sheer amount of data one has to process has grown to dimensions difficult to handle manually. On top of that, the usage of object orientation is on the advance, replacing legacy programming languages like Fortran by modern ones like (among others) C++, Java and Python.

 

Though, one can not just carry programming style and concepts from procedural languages to object oriented languages and hope to benefit from the advantages of this new programming paradigm. Instead, there are numerous things to keep in mind to produce working, error-free and performing - but also understandable, maintainable and expandable - object oriented software designs.

 

This series of two lectures aims to sensitize the "object oriented programming physicist" to things he should be aware of and keep in mind to fully utilize the OO-paradigm.

 

Second lecture:
Design Patterns and Anti-Patterns

In this second lecture of the series, after the core ideas in designing maintainable and well-designed software have been shown in lecture 1, a powerful concept is presented: the Design Pattern. Being reusable "blue print" design snippets - as opposed to reusable pieces of code or libraries - such patterns help in establishing high-quality software designs without "reinventing the wheel".

Furthermore, Design Patterns fulfil the very important role of establishing a common vocabulary between software engineers and developers, leveraging knowledge transfer in and between teams of software developers and turning software designs into building blocks of software that are easy to understand and easy to recognize.

 

After a few popular Design Patterns are presented and examples are given, the second big topic of this lecture are the so-called "Anti Patterns" - the exact opposite of Design Patterns. These describe things to avoid when designing a software system, albeit looking just like "the right thing to do". We will try to explain why those look so good, and what the consequences are.

 

Audience

This lecture builds up on lecture 1. Attendees will learn about established  Design Patterns that can be used to ease creating object-oriented software designs and to streamline the application of the design Best Practices presented in the first lecture.

Furthermore, Anti-Patterns are introduced that show typical things not to do when designing software that lead to common problems, although seeming attractive and easy to apply on the first sight, and thus are very dangerous.

 

 Pre-requisite
To draw maximum benefits from this lecture, the attendant should preferably have followed lecture 1.