Why Applied OO?
A few years ago I was invited by a customer to give a course on ABAP OO (aka. ABAP Objects). During the training, I then learned that some participants attended the third course on this topic in the company. It was impossible for you to implement the content ad hoc after 3-5 days of training. After a few days of dealing with the daily business, only 1% of the learned material had remained in memory. This was the starting point for me to look for a better solution and also to try to solve the arising problems better.
“All software engineers can program, but not all programmers can engineer Software.” – Samer Buna
I am a great advocate of the Asian philosophy Kaizen. The constant preoccupation with the question of what can be improved sometimes leads to impressive results. I want to share these with you here…
A new way of Object orientation?
No, don’t worry, the Object-oriented programming is not reinvented here. From my point of view, this is simply a further logical development on the subject of Object orientation and a successful introduction to the subject!
Although the topic is so old and there is most of the literature related to OO, in the course of my work as a Technology Coach, I have noticed that especially the obvious content is sometimes not easy to master. Since the beginnings of this paradigm, there have always been different interpretations of what the correct application should look like. It led to different methods of Object orientation. To name a few:
- OOP according to the principles of Alan Kay
- Radical OO after Ralf Westphal
- Elegant Objects according to Yegor Bugayenko
This led me a few years ago to rethink this paradigm and put it together in such a way that it keeps some higher purpose in focus.
I finished thinking through Applied OO in 2017 already. It is designed to focus on testable software, robustness and clean code. This has led to a significant reduction in the set of OO syntax usage. (Yes, sorry for the fans of maximum use of any syntax command, this procedure is probably nothing for you…) This is exactly because the application has always had the highest priority here. Once I couldn’t simply apply principles or practices with added value to the three Higher Goals, I stopped wasting time searching for other solutions.
Applied OO are primarily guidelines that I finished about 2 years ago on how to learn and practice OO. From the beginning, “higher” goals such as testable software, robustness, and clean code principles are used methods. The focus was on practitioners who have reached a high level, as well as content from my coaching work.
The results are contents that include modern ABAP, but also guidelines that eventually lead to good designs. I tried this by myself and then later with my coaching clients with incredible success… This year I decided to share this kind of OO…
The goal of the Applied OO (Applied Object-Oriented) approach is to use guidelines in Object-Oriented Programming that also enable an impact in terms of clean code, testability, and simple, robust solutions. The principles used are named below, and there is also an indication of influences from known developers.
The values Applied OO tries to achieve:
- Building Testable Software
- Building Robust Software
- Building Clean Code
- Alan Kay’s Principles
- Clean Code
- IOSP after Ralf Westphal
- 4Rules of Simple Design by J.B. Rainsberger
- Domain and Role-based
- Modern ABAP
- Subset to ABAP Objects
Focus on Principles
Applied OO is still Object-oriented programming, with the goal of high practical usability. For this reason, only the principles and practices of colleagues who have had a significant influence on our industry with their high level of programming mastery can be found.
Here in unsorted order the ones that influenced me the most (order has no value and is not sorted in any way): Alan Kay, Kent Beck, Uncle Bob, Ralf Westphal, Eric Evans, Trygve Reenskaug, James O. Coplien, J.B. Rainsberger, Martin Fowler, Michael Feathers, Kristen Nygaard, Ole-Johan Dahl
Principles of Applied OO
The following overview shows the used principles of Applied OO.
Indeed we are purposely only working on a level of principles, in order to be able to use these correctly for each context-referred situation. I don’t believe in cheap programming tricks that bring immediate redemption. For me, software development is strongly associated with software engineering and software craftsmanship.
Applied OO is not the holy grail, but it is a commonly used programming practice of many coaching clients and we have tested it ourselves for years. The results achieved there have to lead me to present Applied OO to the community. Very good results can only be achieved with the right mindset.
“It is not enough for code to work.” – Robert C. Martin
If you want to learn more, you can watch my presentation at the SAP Inside Track Vienna 2018 : SITVienna 2018 – Damir Majer
Or you are invited to visit one of my webinars: “Webinars powered by majcon” on this topic.
I have always loved that comment by Robert Martin that working code is not enough. So many people thing it is.
Just last week SAP released a style guide in regard to Clean Code, based on Robert Martins book.
Last year SAP did an open course on Test Driven Development, which was wonderful.
I have found from practical experience that if you follow TDD then you are forced to write SOLID code, whether you like it or not. You literally get no choice and that is fantastic.This is the seemingly insane concept that if you write testable code then you do not need to write any tests! In actual fact you do because you write the tests first.
I am now waffling at random, but the point is that i think SAP as an organisation is taking OO programming seriously for the very first time.
I have found from practical experience that if you follow TDD then you are forced to write SOLID code, whether you like it or not. You literally get no choice and that is fantastic. This is the seemingly insane concept that if you write testable code then you do not need to write any tests! In actual fact, you do because you write the tests first.
So the question becomes how can we help people move to TDD? As you say, it is a seemingly insane concept – and a lot of hard work to go from legacy code to SOLID code.
It seems to me not unrelated to the question of diet and exercise. We all know what should be done, but unless we find the inner motivation ourselves, only external forces will change our behaviour.
The main constraint is a perception of not enough time vs the benefit. The benefit is only understood through practice, and most will never try.
Code that "just works" seems less time consuming in the short run and that's the main focus unfortunately.
totally agree with you. And when our industry doesn´t like to learn from the past we will face continuously the same issues which are known as 'technical debt'.
From one side this is good for my business, helping with software diagnosis and supporting as not successful projects with my 'escalation services' saves me to the next 50 years 😉 by the business...
thanks for your Feedback.
And I agree that SAP is taking OOP seriously.
Customers have now Option to take free Courses as WTC (Writing Testable Code) or the WDE401 (OOP in Practice) or oven the premium course for Teams WDAGIL.
Beside those offers also outside SAP is happening a lot. Only to mention my 'Agile-Software-Engineering-Academy' Course which focuses on serious Software Engineering.
TDD enables to get a healthy Design Structure, but to learn to do proper TDD - it takes a lot of time.
More important is to start with the first steps 😉