Learn something new every day.
- I am a senior software engineer working in industry, teaching and writing on software design, SOLID principles, DDD and TDD.
Location
Buenos Aires
Education
Computer Science Degree at Universidad de Buenos Aires
I assume you just misunderstand what a subroutine is, because you seem to think they're somehow a different thing than methods. They're not. When you call a method on an object, you're using a subroutine.
And since the behaviour of any object-oriented system is implemented in methods, and the protocols, as you've mentioned earlier, emerge from the real-world objects, not the program objects built to parallel them, you really don't need said objects in your code whatsoever to represent the protocols and behaviour of a real-world system.
Add to that a mechanism to store subroutines in variables and data structures, and you can easily write code in an object-oriented way with just those basic building blocks, as languages like Lua or early JavaScript have shown.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
So the contract and the behaviour originate in the real world and manifest themselves in subroutines; then what do we need objects for?
Subroutines are fine for programming in the small.
For example a solo work
In order to manage complexity and very large systems you need to follow principles like these
What is (wrong with) software
Maxi Contieri ・ Oct 8 '20 ・ 4 min read
IMHO, You cannot built a serious system based on subroutines.
That was 1950's approach and didn't scale. It was called 'The software crisis'.
And that's the difference between beeing a software engineer and a coder
I assume you just misunderstand what a subroutine is, because you seem to think they're somehow a different thing than methods. They're not. When you call a method on an object, you're using a subroutine.
And since the behaviour of any object-oriented system is implemented in methods, and the protocols, as you've mentioned earlier, emerge from the real-world objects, not the program objects built to parallel them, you really don't need said objects in your code whatsoever to represent the protocols and behaviour of a real-world system.
Add to that a mechanism to store subroutines in variables and data structures, and you can easily write code in an object-oriented way with just those basic building blocks, as languages like Lua or early JavaScript have shown.