Intent:

Motivation:

1. Students often identify OOP with the programming language which is used in an introductory course. This can make their OO-thinking not so broad and flexible. They can be less ready to meat challenges of learning and using other languages when they start to work.
2. Usually one OO-language (even a pure one) doesn't support all the essential OO-concepts and principles. For instance, Smalltalk is considered to be "very" object-oriented and suitable for an introductory OOP course. However, it doesn't support multiple inheritence (MI). It is a matter of discussion, "how much" MI is needed in OOP languages and if it is needed at all. Nevertheless, students should know at least what MI is. Another example is an important question of types in OOP languages and differences between typed and untyped languages, early and late binding. Smalltalk doesn't have types, therefore it cannot provide relevant examples.

Using at least two OOP languages gives much broader view of OOP and provides much more possibilities for the course. One language is the base language. It is used for labs and (presumably) for students' applications. The second language is supplementary and it is used for some lecture examples and (sometimes) for students' applications.

A good example pair is Smalltalk and C++ (or vice versa). Some would think that it is possible to teach the base concepts of object orientation without programming languages at all. In essence, this is true. However, expressing OO-concepts in programming languages (and possibly developing interesting applications) gives students much more confidence in OO-approach, makes course more practical and interesting. CS students, especially in their last two undergraduate years, are more used to express their thinking in computer programms than in other models (although these other models can be used just as well).

Applicability:

Use the BSLL pattern to explain and illustrate the concepts of OOP which are not supported by the base language. Use the BSLL pattern to give your students a general view of OOP, to discuss differences between languages, their advantages and shortcomings, to have more tools for students to develop their applications.

Structure:

• the base language doesn't support the concept being explained (or the support is not adequate)
• differences between implementations of the concept in different languages are discussed.

It is recommended to give a concise introduction to the supplementary language at the beginning. The goal of this introduction is to remindstudents the syntax and the basic constructs of the language. However, this is possible only when having enough time for lectures.

Consequences:

• allows students to form a broader and more general view of OO-approach
• improves understanding of essential OOP features
• encourages students to compare languages and to think about them critically
• accustoms students to the thought that they probably would use many languages in their future
• makes lectures more interesting and practical
• raises authority of the teacher (he or she knows many languages!)
• as a side effect, improves knowledge of the supplementary language
• requires the sufficient knowledge of the supplementary language by the teacher
• can require a bit more time (but not necessarily) in preparing lectures
• can be relatively difficult to those students who don't like programming (if there are such)

Implementation:

• Choice of the supplementary language (after the base language is already chosen). It should be complementary to the base language. E.g., if the base language is pure, the supplementary one should by hybrid. If the base language is untyped, the supplementary one should be typed. If the base language doesn't support MI, the supplementary one should suppoert, etc . The choice is relatively easy (if there are no other restrictions) because there are many OOP (including hybrid ones) languages now. Of course, the teacher should know the supplementary language himself.
• It is not recommended to give students too complicated examples in a supplementary language which would use intricate or less known constructs of the language.

Related Patterns:

Example Instances: