Softwareeinheiten sollten offen für Erweiterungen, aber verschlossen gegenüber Veränderungen sein. Was zunächst wie ein Widerspruch klingt, ist ein zentraler Aspekt des Entwurfs objektorientierter Systeme. Gleichzeitig sorgt es für Modularität und damit Flexibilität, Wiederverwendbarkeit und Wartbarkeit der darauf aufbauenden Systeme. Entsprechend beruht das Open-Closed‐Prinzip auf zwei grundlegenden Aspekten der objektorientierten Programmierung: Vererbung und Polymorphie in Verbindung mit Abstraktion: Eine konkrete Klasse hängt nur von abstrakten Klassen ab. Objekte dieser Klasse nutzen Objekte konkreter Klassen, die von der abstrakten Klasse erben. Drei Symptome sind klare Hinweise auf eine Verletzung des Open-Closed‐Prinzips: Starrheit, Zerbrechlichkeit und Unbeweglichkeit. Im ersten Fall zieht jede Änderung an einer Stelle viele Änderungen an anderen Stellen nach sich, im zweiten Fall führen Änderungen zu Fehlern in konzeptionell getrennten Bereichen des Systems, während sich im dritten Fall ein System schwer in wiederverwendbare Komponenten aufteilen lässt.

错误:搜索内容不能为空,请输入英文关键词
错误:关键词超出字数限制,请精简
高级检索

Das Open-Closed-Prinzip

  • Till Biskup

摘要

Softwareeinheiten sollten offen für Erweiterungen, aber verschlossen gegenüber Veränderungen sein. Was zunächst wie ein Widerspruch klingt, ist ein zentraler Aspekt des Entwurfs objektorientierter Systeme. Gleichzeitig sorgt es für Modularität und damit Flexibilität, Wiederverwendbarkeit und Wartbarkeit der darauf aufbauenden Systeme. Entsprechend beruht das Open-Closed‐Prinzip auf zwei grundlegenden Aspekten der objektorientierten Programmierung: Vererbung und Polymorphie in Verbindung mit Abstraktion: Eine konkrete Klasse hängt nur von abstrakten Klassen ab. Objekte dieser Klasse nutzen Objekte konkreter Klassen, die von der abstrakten Klasse erben. Drei Symptome sind klare Hinweise auf eine Verletzung des Open-Closed‐Prinzips: Starrheit, Zerbrechlichkeit und Unbeweglichkeit. Im ersten Fall zieht jede Änderung an einer Stelle viele Änderungen an anderen Stellen nach sich, im zweiten Fall führen Änderungen zu Fehlern in konzeptionell getrennten Bereichen des Systems, während sich im dritten Fall ein System schwer in wiederverwendbare Komponenten aufteilen lässt.