Glanz: aiMOOC über GPT aiMOOC Action erstellt

2026-08-29T12:25:45Z

aiMOOC über GPT aiMOOC Action erstellt

Neue Seite

{{T}}
[[Category:English]]
[[Category:Object-Oriented Programming]]

{{BR}}
= Introduction =

Object-oriented programming, usually shortened to '''OOP''', is a way of organizing software around interacting objects. An object combines '''state''' with '''behavior''': for example, a digital library item might store a title and availability status while providing methods for borrowing, returning, or displaying information. A '''class''' is a description from which objects can be created in class-based object-oriented languages.

This aiMOOC is designed for '''Grades 11–13'''. You should already be comfortable with variables, conditions, loops, functions, and basic data structures. The examples use Python because its class syntax is compact, while comparisons with Java and C++ show that the same design ideas can be expressed differently across languages.

By the end of the course, you should be able to explain classes and objects, design encapsulated classes, use inheritance and composition appropriately, reason about polymorphism, read basic [[English:Unified Modeling Language|UML]] diagrams, test object behavior, and evaluate object-oriented designs rather than merely copying syntax.

{{#ev:youtube|https://www.youtube.com/watch?v=SiBw7os-_zI|500|center}}

The video above gives a compact overview of encapsulation, abstraction, inheritance, and polymorphism. These four ideas are often taught as the main pillars of OOP, but real object-oriented languages differ, and good design also depends on composition, interfaces, testing, and clear responsibilities.

{{BR}}
= Historical Context =

Object-oriented ideas developed over decades. [[English:Simula|Simula]] in the 1960s introduced important class and object concepts. In the 1970s, [[English:Smalltalk|Smalltalk]] made message passing and objects central to its programming model. Alan Kay, one of the influential researchers associated with Smalltalk at Xerox PARC, helped popularize the term "object-oriented programming." Modern languages such as Java, C++, Python, C#, Kotlin, Swift, and Ruby use different combinations of object-oriented features.

[[File:Alan Kay.jpg|400px|frameless|center]]

Alan Kay during a 2005 presentation. Studying the history of OOP helps you see that it is not one fixed recipe but a family of ideas about how software entities can hold state and cooperate through behavior.

[[File:Alto-smalltalk.png|500px|frameless|center]]

The Smalltalk environment illustrates an important historical idea: programs can be explored as networks of objects, classes, and messages inside an interactive development environment.

{{BR}}
= Classes, Objects, State, and Behavior =

{{BR}}
== Classes and Instances ==

In a class-based language, a '''class''' defines a kind of object. An '''instance''' is one concrete object created from that class. If `Book` is a class, then one object may represent a particular novel while another represents a textbook. Both use the same class definition, but each can store different instance data.

A constructor or initializer establishes an object's starting state. Instance methods define operations that act on that state. In Python, `__init__` is the method normally used to initialize a new instance after it is created.

<syntaxhighlight lang="python">
class Book:
def __init__(self, title, pages):
self.title = title
self.pages = pages
self.available = True

def borrow(self):
if self.available:
self.available = False
return True
return False

book_a = Book("The Time Machine", 128)
book_b = Book("Algorithms", 700)
</syntaxhighlight>

`book_a` and `book_b` are different objects. A change to `book_a.available` does not automatically change `book_b.available`. This distinction between a class-level description and instance-level state is fundamental.

{{#ev:youtube|https://www.youtube.com/watch?v=e4fwY9ZsxPw|500|center}}

The CS50P lecture above develops classes, objects, instance methods, validation, properties, class methods, inheritance, and operator overloading in Python. Use the chapter markers to revisit individual concepts after reading the sections below.

{{BR}}
== Reading a Class Diagram ==

A UML class diagram can show classes, attributes, operations, and relationships. A class box is often divided into compartments for the class name, its attributes, and its methods. UML is a modeling language, not executable code, so the same diagram can guide implementations in different programming languages.

[[File:UML class diagram example.svg|600px|frameless|center]]

When you read a class diagram, ask: What responsibility does each class have? Which data belongs inside it? Which operations should it expose? Which relationships are essential? A diagram is useful only when it improves thinking and communication.

{{BR}}
= Encapsulation and Abstraction =

{{BR}}
== Encapsulation ==

'''Encapsulation''' means bundling related state and behavior and controlling how internal state is accessed or changed. The goal is not simply to make fields private. The deeper goal is to protect valid states and provide a clear public interface.

Suppose a `BankAccount` balance must never be changed by arbitrary code. A deposit method can reject invalid amounts before modifying the state.

<syntaxhighlight lang="python">
class BankAccount:
def __init__(self, owner):
self.owner = owner
self._balance = 0.0

def deposit(self, amount):
if amount <= 0:
raise ValueError("Amount must be positive")
self._balance += amount

def balance(self):
return self._balance
</syntaxhighlight>

Python's single leading underscore is a convention signaling non-public use; it is not the same as Java's compiler-enforced `private` access. Java and C++ provide explicit access modifiers. This difference matters: encapsulation is a design principle, while access-control syntax is one language mechanism that can support it.

[[File:UML class diagram with access modifiers.svg|600px|frameless|center]]

In UML class diagrams, visibility symbols can indicate public, protected, and private members. The diagram helps you reason about which parts of a class form its external contract and which are implementation details.

{{BR}}
== Abstraction ==

'''Abstraction''' means focusing on essential capabilities while hiding unnecessary implementation detail. When you call `list.append` in Python or `add` on a Java collection, you use an operation without needing to know every internal step.

An interface or abstract base class can describe what collaborating objects must be able to do. In Java, an interface declares a contract that implementing classes must satisfy. In Python, similar designs can be expressed through abstract base classes, protocols, or simpler duck typing depending on the situation.

Good abstraction reduces the amount of information you must hold in your head at once. Bad abstraction can make code harder to understand if it introduces layers without a clear purpose.

{{BR}}
= Inheritance, Overriding, and Polymorphism =

{{BR}}
== Inheritance ==

'''Inheritance''' creates a relationship in which a subclass derives features from a superclass. It is often described with an "is-a" relationship: a `SavingsAccount` is a kind of `BankAccount`. Inheritance can reduce duplication and support substitution, but deep class hierarchies can become rigid and difficult to change.

[[File:CPT-OOP-inheritance.svg|600px|frameless|center]]

The inheritance diagram above uses vehicles to show a hierarchy. A useful design question is whether every subclass can safely be treated as the superclass. If the answer is doubtful, inheritance may be the wrong relationship.

<syntaxhighlight lang="python">
class Notification:
def send(self, message):
raise NotImplementedError

class EmailNotification(Notification):
def send(self, message):
return f"Email sent: {message}"

class SmsNotification(Notification):
def send(self, message):
return f"SMS sent: {message}"
</syntaxhighlight>

`EmailNotification` and `SmsNotification` override the same operation with different implementations.

{{BR}}
== Polymorphism ==

'''Polymorphism''' allows the same operation to work with objects of different concrete types. In the example below, the loop does not need a separate `if` statement for each notification type.

<syntaxhighlight lang="python">
channels = [EmailNotification(), SmsNotification()]

for channel in channels:
print(channel.send("Exam room changed"))
</syntaxhighlight>

The expression `channel.send(...)` has the same shape each time, but the concrete object determines which implementation runs. This is subtype polymorphism through method overriding. Other forms of polymorphism also exist, including parametric polymorphism through generics.

{{#ev:youtube|https://www.youtube.com/watch?v=wN0x9eZLix4|500|center}}

The C++ course above shows classes, access control, constructors, encapsulation, abstraction, inheritance, and polymorphism in another language. Compare its syntax with Python rather than assuming that every language implements OOP in exactly the same way.

{{BR}}
= Composition and Object Collaboration =

'''Composition''' means building an object from other objects. It usually represents a "has-a" relationship. A `Car` has an `Engine`; a `Course` has enrolled `Student` objects; a `Library` has a collection of `Book` objects.

Composition is often more flexible than inheritance because collaborators can be replaced without forcing everything into one class hierarchy.

<syntaxhighlight lang="python">
class Engine:
def start(self):
return "engine started"

class Car:
def __init__(self, engine):
self.engine = engine

def start(self):
return self.engine.start()
</syntaxhighlight>

Here `Car` delegates starting behavior to an `Engine`. The car does not need to inherit from the engine. This separation also makes testing easier because a test double could be supplied in place of a real engine.

'''Message passing''' is a useful mental model for object collaboration: one object asks another object to perform an operation. In most mainstream OOP languages, this appears as a method call.

[[File:CPT-Sequence-diagram.svg|400px|frameless|center]]

A UML sequence diagram emphasizes interactions over time. It can help you trace which object sends a request, which object responds, and where responsibilities are concentrated.

{{BR}}
= Designing with UML and Responsibilities =

Before writing code, you can sketch a system in terms of responsibilities. Consider a school media-lending system:

# [[English:Library item|Library item]]: Stores shared information such as title and inventory identifier.
# [[English:Book|Book]]: Adds book-specific data such as author or ISBN.
# [[English:Borrower|Borrower]]: Represents a person allowed to borrow items.
# [[English:Loan|Loan]]: Records which borrower has which item and when it is due.
# [[English:Library service|Library service]]: Coordinates borrowing rules rather than putting every rule into one large data class.

A strong class usually has '''high cohesion''': its fields and methods contribute to a focused purpose. Classes should also avoid unnecessary '''coupling''', meaning they should depend on as few implementation details of other classes as practical.

[[File:UML diagram of classes that model pages and titles in MediaWiki.svg|700px|frameless|center]]

This real-world class diagram from the MediaWiki codebase is intentionally more complex than the earlier examples. Do not try to memorize it. Instead, identify repeated design signals: interfaces, class relationships, dependencies, and groups of responsibilities.

{{BR}}
== Interfaces and Dependency Boundaries ==

Interfaces can separate what a component needs from how another component provides it. For example, a `ReportService` might depend on a `Storage` interface rather than directly on one database class. Then a test can use an in-memory implementation, while production code can use a database implementation.

This idea supports the principle of programming to a stable abstraction rather than to a volatile implementation. It can reduce coupling, but interfaces should be introduced where they clarify a real boundary rather than everywhere by habit.

{{BR}}
== Design Principles for Advanced Learners ==

The [[English:SOLID|SOLID]] principles are a widely discussed set of object-oriented design guidelines. At Grades 11–13, use them as questions rather than absolute rules:

# [[English:Single-responsibility principle|Single-responsibility principle]]: Does this class have one focused reason to change?
# [[English:Open–closed principle|Open–closed principle]]: Can new behavior be added without repeatedly rewriting stable code?
# [[English:Liskov substitution principle|Liskov substitution principle]]: Can a subtype be used wherever its base type is expected without breaking the intended behavior?
# [[English:Interface segregation principle|Interface segregation principle]]: Are clients forced to depend on operations they do not need?
# [[English:Dependency inversion principle|Dependency inversion principle]]: Do high-level policies avoid depending directly on low-level implementation details?

These principles can conflict with simplicity if applied mechanically. A small program may need only a few clear classes. Good design is judged by readability, correctness, adaptability, and testability in context.

{{BR}}
= Testing and Debugging Object-Oriented Code =

Unit tests should verify observable behavior and important state transitions. For example, a borrowing test can check that an available item becomes unavailable after a successful loan, that a second loan attempt is rejected, and that returning the item restores availability.

A useful testing habit is to arrange the initial objects, perform one meaningful action, and then assert the expected outcome. When a class is difficult to test, that may reveal excessive coupling, hidden dependencies, or too many responsibilities.

Common design and debugging problems include:
# [[English:Shared mutable state|Shared mutable state]]: Multiple objects unexpectedly change the same data.
# [[English:God object|God object]]: One class controls too many unrelated responsibilities.
# [[English:Deep inheritance hierarchy|Deep inheritance hierarchy]]: Behavior is spread across many ancestor classes.
# [[English:Leaky abstraction|Leaky abstraction]]: Clients must understand internal details to use a class correctly.
# [[English:Primitive obsession|Primitive obsession]]: Domain ideas are represented only by strings or numbers when a small dedicated type would improve validity and clarity.

Refactoring changes the internal structure of code while preserving intended external behavior. Useful refactorings include extracting a method, extracting a class, replacing a conditional with polymorphism when justified, or replacing inheritance with composition when a hierarchy is unstable.

{{BR}}
= Comparing OOP Across Languages =

OOP is not identical in every language. Python supports multiple inheritance and dynamic attribute lookup. Java allows a class to extend one direct superclass while implementing multiple interfaces. C++ supports multiple inheritance and gives programmers detailed control over object lifetime and memory management. JavaScript uses prototype-based inheritance rather than the classical class model underneath its `class` syntax.

You should therefore separate '''design concepts''' from '''language syntax'''. The question "What is the responsibility of this object?" is language-independent. The question "How do I declare a private field?" depends on the language.

{{#ev:youtube|https://www.youtube.com/watch?v=g7QWqKj0ch8|500|center}}

This CS50 Beyond lecture places object-oriented programming beside other computer-science ideas. Use it to reflect on when OOP is one helpful tool among several rather than the only possible programming style.

{{BR}}
= Responsible and Effective Use of OOP =

OOP is useful when a problem contains entities with meaningful state, behavior, and collaboration. It can be especially effective in graphical applications, simulations, games, enterprise systems, and large codebases with clear domain concepts. It is not automatically the best solution for every task. Small scripts, data pipelines, numerical programs, and functional designs may be clearer with other structures.

The key question is not "How many classes can I create?" but "Which structure makes the program easiest to understand, test, change, and use correctly?"

{{BR}}
= Reliable References =

For further study, compare explanations from several authoritative sources:
# [https://dev.java/learn/oop/ Dev.java: Objects, Classes, Interfaces, Packages, and Inheritance]
# [https://docs.python.org/3/tutorial/classes.html Python documentation: Classes]
# [https://en.wikipedia.org/wiki/Object-oriented_programming Wikipedia: Object-oriented programming]
# [https://commons.wikimedia.org/wiki/Class_diagram Wikimedia Commons: Class diagrams]

{{BR}}
= Interactive Tasks =

{{BR}}
== Quiz: Test Your Knowledge ==

{{MC}}

'''What is an object in class-based object-oriented programming?'''
(An instance that combines state with behavior)
(!A file that contains only comments)
(!A loop that repeats class definitions)
(!A diagram that can execute itself)

{{E}}
<br>

{{MC}}

'''What is the main role of a class?'''
(To define a kind of object and its shared structure and behavior)
(!To guarantee that every program uses inheritance)
(!To replace all functions in a program)
(!To store only global variables)

{{E}}
<br>

{{MC}}

'''Which idea focuses on protecting valid internal state behind a controlled interface?'''
(Encapsulation)
(!Compilation)
(!Recursion)
(!Serialization)

{{E}}
<br>

{{MC}}

'''Which relationship is best described as a car has an engine?'''
(Composition)
(!Inheritance)
(!Overriding)
(!Iteration)

{{E}}
<br>

{{MC}}

'''What happens when a subclass provides its own implementation of an inherited method?'''
(The method is overridden)
(!The object becomes immutable)
(!The class is deleted)
(!The method becomes a variable)

{{E}}
<br>

{{MC}}

'''What does subtype polymorphism allow?'''
(The same operation to use different implementations for different object types)
(!Every object to contain identical data)
(!A program to avoid all type relationships)
(!A constructor to run more than once automatically)

{{E}}
<br>

{{MC}}

'''What does a UML class diagram primarily describe?'''
(Classes attributes operations and relationships)
(!The exact CPU instructions of a running program)
(!Only the order of loop iterations)
(!The physical wiring of a computer)

{{E}}
<br>

{{MC}}

'''Why can composition be preferable to inheritance?'''
(It can reduce rigid class hierarchies and make collaborators replaceable)
(!It prevents objects from having methods)
(!It removes the need for testing)
(!It makes all fields public)

{{E}}
<br>

{{MC}}

'''Which statement about OOP across languages is correct?'''
(Object-oriented concepts are similar but language mechanisms differ)
(!All object-oriented languages use identical syntax)
(!All object-oriented languages require multiple inheritance)
(!All object-oriented languages enforce privacy in the same way)

{{E}}
<br>

{{MC}}

'''Which quality describes a class whose members contribute to one focused purpose?'''
(High cohesion)
(!High randomness)
(!High duplication)
(!High ambiguity)

{{E}}
<br>

{{BR}}
== Memory Game ==

<div class="memo-quiz">
{|
|-
| Class || Blueprint or definition used to create objects
|-
| Instance || One concrete object created from a class
|-
| Encapsulation || Controlled access to internal state through a defined interface
|-
| Inheritance || Deriving a more specific class from a more general one
|-
| Polymorphism || Using one operation with different concrete implementations
|-
| Composition || Building an object from collaborating contained objects
|-
| Cohesion || Degree to which a class has a focused responsibility
|}
{{E}}
<br>

{{BR}}
== Drag and Drop ==

<div class="lueckentext-quiz">

{| class="wikitable"
! Match the correct terms.
! Topic
|-
| '''Protect internal state with methods'''
| Encapsulation
|-
| '''Create a specialized subtype'''
| Inheritance
|-
| '''Delegate work to a contained collaborator'''
| Composition
|-
| '''Use the same call on different concrete types'''
| Polymorphism
|-
| '''Show static class relationships'''
| Class diagram
|}
{{E}}

<br>
<br />

{{BR}}
== Crossword Puzzle ==

<div class="kreuzwort-quiz">
{|
|-
| Encapsulation || Which concept controls access to internal state through a public interface?
|-
| Inheritance || Which mechanism derives a subclass from a superclass?
|-
| Polymorphism || Which concept lets one operation use different implementations?
|-
| Abstraction || Which concept hides unnecessary implementation detail?
|-
| Constructor || What initializes a newly created object in many class-based languages?
|-
| Interface || What defines a contract of operations that an implementing class agrees to provide?
|}
{{E}}
<br>

{{BR}}
== LearningApps ==

<iframe> https://learningapps.org/index.php?s=Object-Oriented+Programming </iframe>

{{BR}}
== Cloze Text ==

<quiz display=simple>
{'''Complete the text.'''<br>
|type="{}"}
A class defines a kind of { object } and its shared structure. One concrete object created from a class is called an { instance }. Data stored by an object represents its { state }. Operations associated with an object are commonly called { methods }. Protecting internal state behind a controlled interface supports { encapsulation }. Hiding unnecessary implementation detail is called { abstraction }. A subclass can derive features from a superclass through { inheritance }. Different object types can respond to the same operation through { polymorphism }. Building an object from contained collaborators is called { composition }. UML can represent static class relationships in a class { diagram }.
</quiz>

<br>

{{BR}}
= Open-Ended Tasks =

{{BR}}
=== Easy ===
# [[English:Object inventory|Object inventory]]: Find five objects in your classroom or home. For each one, list possible state and behavior, then decide which details would belong in a software class.
# [[English:Class card|Class card]]: Design one class card for a school-related object with a class name, at least three attributes, and at least three methods.
# [[English:Instance comparison|Instance comparison]]: Create two instances of the same simple class in Python, give them different state, and explain why changing one instance does not automatically change the other.
# [[English:UML sketch|UML sketch]]: Draw a basic UML class diagram for a `Student` class and annotate what each compartment means.

{{BR}}
=== Standard ===
# [[English:Encapsulation experiment|Encapsulation experiment]]: Implement a class with one state invariant, such as a non-negative balance or bounded score, and write tests showing that invalid updates are rejected.
# [[English:Inheritance review|Inheritance review]]: Build a small superclass and two subclasses, override one method, then explain where polymorphism appears when the objects are stored in one collection.
# [[English:Composition redesign|Composition redesign]]: Take a design that uses inheritance and redesign it using composition. Compare flexibility, coupling, and readability.
# [[English:Sequence diagram project|Sequence diagram project]]: Model a borrowing or login process with at least three collaborating objects and create a UML sequence diagram that shows the messages between them.

{{BR}}
=== Advanced ===
# [[English:Design interview|Design interview]]: Interview a software developer or advanced computing student about when they prefer composition, inheritance, or interfaces. Compare the interview with the design principles in this course.
# [[English:Refactoring investigation|Refactoring investigation]]: Find or create a small program with a god object, split its responsibilities across coherent classes, and document the behavior you preserved with tests.
# [[English:Cross-language OOP study|Cross-language OOP study]]: Implement the same two-class design in two languages such as Python and Java, then produce a short video explaining differences in access control, inheritance, constructors, and typing.
# [[English:Architecture challenge|Architecture challenge]]: Design a small school media-lending system with classes, interfaces or abstract types, composition, tests, and UML diagrams. Justify each major dependency and identify one design you deliberately rejected.

{{:Open Task - Create a MOOC}}

{{BR}}
= Learning Assessment =

# [[English:Model a changing system|Model a changing system]]: Design an object model for a bicycle-rental system in which bicycles can be available, reserved, rented, or under repair; justify where each state change is controlled and explain how your design prevents invalid transitions.
# [[English:Evaluate inheritance|Evaluate inheritance]]: Given a proposed hierarchy in which `Rectangle` inherits from `Square` or `Square` inherits from `Rectangle`, analyze substitution problems and recommend inheritance, composition, or separate types with reasons.
# [[English:Refactor conditional logic|Refactor conditional logic]]: Transform a program that uses repeated type checks for payment methods into a polymorphic design, then explain whether the change improved cohesion and extensibility enough to justify the added abstraction.
# [[English:Test an abstraction boundary|Test an abstraction boundary]]: Create unit tests for a service that depends on a storage interface, use a test double in place of real storage, and explain what this reveals about coupling.
# [[English:Compare language mechanisms|Compare language mechanisms]]: Explain how encapsulation and inheritance differ between Python and Java, distinguishing the design idea from the syntax used by each language.
# [[English:Defend a design|Defend a design]]: Present a UML class diagram and sequence diagram for a small application, then defend your assignment of responsibilities against an alternative design proposed by a peer.

<br>
<br>

{{BR}}
= Evidence of Learning =

Evidence of learning should show more than vocabulary recall. Strong evidence includes:
# '''Knowledge''': Accurate explanations of classes, objects, state, behavior, encapsulation, abstraction, inheritance, composition, polymorphism, interfaces, cohesion, coupling, and UML relationships.
# '''Programming skills''': Correct creation of classes and instances, controlled state changes, method overriding, collaborator injection, and meaningful automated tests.
# '''Design skills''': Clear responsibility assignment, justified use or rejection of inheritance, appropriate composition, and recognition of excessive coupling or weak cohesion.
# '''Products''': Working source code, UML class diagrams, sequence diagrams, test suites, refactoring notes, comparison reports, or explanatory videos.
# '''Reasoning''': Explanations that connect a design decision to consequences for correctness, readability, testability, and future change.
# '''Transfer''': Ability to recognize object-oriented ideas in a new language or domain and to choose a different programming style when OOP would not improve the solution.

<br>
<br>

{{BR}}
= OERs on the Topic =

<iframe> https://en.m.wikipedia.org/wiki/Object-oriented_programming </iframe>

<br>

{{BR}}
= Linked Learning Areas =

{| align=center
{{:D-Tab}}
'''[[English:Object-Oriented Programming|Object-Oriented Programming]]'''
# [[English:Class|Class]]
# [[English:Object|Object]]
# [[English:Encapsulation|Encapsulation]]
# [[English:Abstraction|Abstraction]]
# [[English:Inheritance|Inheritance]]
# [[English:Polymorphism|Polymorphism]]
# [[English:Composition over inheritance|Composition over inheritance]]
# [[English:Interface|Interface]]
# [[English:Unified Modeling Language|Unified Modeling Language]]
# [[English:Software design pattern|Software design pattern]]
# [[English:Unit testing|Unit testing]]
# [[English:Refactoring|Refactoring]]
|}

{{BR}}
= aiMOOC Projects =
[[Category:English]]
[[Category:Object-Oriented Programming]]
[[Category:Computer Science]]
[[Category:Programming]]
[[Category:Software Engineering]]
[[Category:Grades 11-13]]
[[Category:AI_MOOC]]
[[Category:GPT aiMOOC]]
{{MT}}

English:Object-Oriented Programming - Versionsgeschichte

Glanz: aiMOOC über GPT aiMOOC Action erstellt