Let's talk about object-oriented (OO) software development!
The Antipattern named ABAP
SAP NetWeaver goes into the Java direction. No one is likely to talk about ABAP when it comes to new technologies and innovations. This is no guess, it's reality. At least at the NetWeaver Congress in Germany these days. There, I got the impression that any SAP employee was forced to forget the word "ABAP" or otherwise would come directly into the lion's den (most probably Kagermann’s or SDN vs. SAP Community: Plethora of Contents office).
ABAP/Objects
ABAP/Objects is a nice try to lift up ABAP to a more sophisticated technology. This failed as a whole. First reason is the integration of an OO paradigma into a legacy procedural-driven system. Another reason is the limitations that need to be taken into account when designing ABAP/Objects (e.g. symbols already occupied by ABAP, compatibility with ABAP in respects to integrating ABAP/Objects code etc.). For further reading see my article in OBJEKTspektrum 03/2004 (sorry, only available in German) "SAP's Weg in die Objektorientierung: ABAP/Objects".
OO in general
Many discussions are on the line arguing pro and contra with OO. OO is a design principle. No one can force a developer to use it correctly. In several projects, I could observe the heavy abuse of OO languages. Mostly simple principles were broken and the result was a degenerated program looking more procedural than object oriented. If it is so difficult for one to learn to use the advantages of OO, what about the people working with ABAP the whole time? It seems to me the only way to come out of this is tool support. Like that offered by the NetWeaver Developer Studio. Just think of the WebDynpro technology with its MVC-architecture. Model-driven development appears too complicated taken as a concept in general. So the WebDynpro approach seems promising to me. When it comes to object orientation and software development in general, I showed in my dissertation that it has some relevancy.
J2EE
J2EE is another subject one could talk/write about for hours, days or even years. As with EJB 3 there are massive simplifications planned. To be honest: Who would use J2EE if there were an alternative? J2EE application servers provide some services and layers given by SAP BASIS previously. But J2EE still is too complicated, too slow to develop and a pain in the ... with configurational aspects. Not to talk of mapping entity beans to a model like a database. If you must do this, I offer you my condolences.
Additionally consider that a professional J2EE application can only be built by heavy use of Design Patterns: Boondoggle or State-of-the-Art?. But who would ask someone to learn the 15 most important Design Patterns: Boondoggle or State-of-the-Art? just to be able to do what should be taken for granted?
Conclusion
The object-oriented principle of designing software allows you to develop applications from models. What’s missing in my opinion is the general awareness of developers for the chances and risks of OO. Furthermore, tool support is needed urgently. And I mean, tools offering the possibility of drawing diagrams are nice, but don’t add much value to a development process. Visual Composer (aka: GUI Machine) seems to allow declarative development of software components i.e. GUIs. Here we see the direction the road of success could head to: Build up the infrastructure on basis of OO and do everything to assure full support for developers; lead them; give them processes to follow; assume it's a danger letting a person do coding spawning more than one method. Whilst the last statement is kind of provocative it contains some truth in it.
P.S.
This is my own's birthday article 🙂
4 Comments
