© Excellent backgrounds/Shutterstock.com
Java Magazin
Java muss nicht objektorientiert sein

Java prozedural

Java wird klassischerweise mit der objektorientierten Programmierung in Verbindung gebracht. Auch aspektorientierte und seit Java 8 funktionale Programmierung gehören zum Java-Universum. Obwohl sie bei Enterprise-Anwendungen durchaus vermehrt anzutreffen ist, wird die prozedurale Programmierung aber meist unterschlagen.

Christoph Pater


Als ich 1999 in der Ausbildung den ersten Java-Kurs machte, war das ein Kurs in objektorientierter Programmierung. Genau wie später an der Uni war Objektorientierung zum einen ganz klar ein Update zur bis dahin gelernten prozeduralen Programmierung und zum anderen fest mit Java verbunden. Java ist objektorientiert – Punkt. So war es auch lange normal, dass, wer Java programmiert, objektorientierte Software schreibt und sich spätestens als Seniorentwickler OOA/OOD (objektorientierte Architektur bzw. Design) in die Skill-Liste schreibt.

Auch wenn es sich nie „richtig“ anfühlte, zu jedem privaten Feld auch immer Getter und Setter generieren zu lassen, blieb es erst einmal dabei: Java ist objektorientiert. In den letzten Jahren habe ich mich vermehrt mit agiler Softwareentwicklung, Extreme Programming und Software Craftmanship beschäftigt. Je mehr ich dabei über Clean Code, Test-driven Development (TDD), Code Smells und objektorientierte Prinzipien gelernt habe, desto mehr hatte ich Probleme damit, diese im beruflichen Java-Enterprise-Umfeld anzuwenden. Zu groß wurde der Designbruch zum bestehenden Legacy-Code. Schließlich war es ein Ruby-Buch [1], welches mich darauf brachte, warum dies so ist: Das Design der Software ist eher prozedural als objektorientiert. Und das trifft bisher auf jede Enterprise-(Spring-)Codebasis zu, die ich in den letzten zehn Jahren gesehen habe.

Programmierparadigmen

Bevor wir tiefer in die Thematik einsteigen, wollen wir die zwei betrachteten Programmierparadigmen „prozedural“ und „objektorientiert“ genauer voneinander abgrenzen. Dabei ist es gar nicht so einfach, eine passende Definition zu finden. Die vorhandenen reichen von rein technischen bis hin zu recht theoretischen Definitionen. Meiner Ansicht nach trifft es die folgende am besten: „The focus of procedural programming is to break down a programming task into a collection of variables, data structures, and subroutines, whereas in object-oriented programming it is to break down a programming task into objects that expose behavior (methods) and data (members or attributes) using interfaces. The most important distinction is that while procedural programming uses procedures to operate on data structures, object-oriented programming bundles the two together, so an ‘object’, which is an instance of a class, operates on its ‘own’ data structure.“ [2]

Bei der prozeduralen Programmierung gibt es eine Trennung zwischen den Daten und Methoden, welche auf diesen angewendet werden, währ...

Java Magazin
Java muss nicht objektorientiert sein

Java prozedural

Java wird klassischerweise mit der objektorientierten Programmierung in Verbindung gebracht. Auch aspektorientierte und seit Java 8 funktionale Programmierung gehören zum Java-Universum. Obwohl sie bei Enterprise-Anwendungen durchaus vermehrt anzutreffen ist, wird die prozedurale Programmierung aber meist unterschlagen.

Christoph Pater


Als ich 1999 in der Ausbildung den ersten Java-Kurs machte, war das ein Kurs in objektorientierter Programmierung. Genau wie später an der Uni war Objektorientierung zum einen ganz klar ein Update zur bis dahin gelernten prozeduralen Programmierung und zum anderen fest mit Java verbunden. Java ist objektorientiert – Punkt. So war es auch lange normal, dass, wer Java programmiert, objektorientierte Software schreibt und sich spätestens als Seniorentwickler OOA/OOD (objektorientierte Architektur bzw. Design) in die Skill-Liste schreibt.

Auch wenn es sich nie „richtig“ anfühlte, zu jedem privaten Feld auch immer Getter und Setter generieren zu lassen, blieb es erst einmal dabei: Java ist objektorientiert. In den letzten Jahren habe ich mich vermehrt mit agiler Softwareentwicklung, Extreme Programming und Software Craftmanship beschäftigt. Je mehr ich dabei über Clean Code, Test-driven Development (TDD), Code Smells und objektorientierte Prinzipien gelernt habe, desto mehr hatte ich Probleme damit, diese im beruflichen Java-Enterprise-Umfeld anzuwenden. Zu groß wurde der Designbruch zum bestehenden Legacy-Code. Schließlich war es ein Ruby-Buch [1], welches mich darauf brachte, warum dies so ist: Das Design der Software ist eher prozedural als objektorientiert. Und das trifft bisher auf jede Enterprise-(Spring-)Codebasis zu, die ich in den letzten zehn Jahren gesehen habe.

Programmierparadigmen

Bevor wir tiefer in die Thematik einsteigen, wollen wir die zwei betrachteten Programmierparadigmen „prozedural“ und „objektorientiert“ genauer voneinander abgrenzen. Dabei ist es gar nicht so einfach, eine passende Definition zu finden. Die vorhandenen reichen von rein technischen bis hin zu recht theoretischen Definitionen. Meiner Ansicht nach trifft es die folgende am besten: „The focus of procedural programming is to break down a programming task into a collection of variables, data structures, and subroutines, whereas in object-oriented programming it is to break down a programming task into objects that expose behavior (methods) and data (members or attributes) using interfaces. The most important distinction is that while procedural programming uses procedures to operate on data structures, object-oriented programming bundles the two together, so an ‘object’, which is an instance of a class, operates on its ‘own’ data structure.“ [2]

Bei der prozeduralen Programmierung gibt es eine Trennung zwischen den Daten und Methoden, welche auf diesen angewendet werden, währ...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang