> Object-Oriented Programming (OOP) is a programming paradigm where different components of a computer program are modeled after real-world objects.<p>This is a common, but dangerous way to introduce the object-oriented paradigm. While it is true that many object-oriented systems end up having a few classes that represent entities of its problem domain (such as, perhaps, bus stations in a public transport app), most of them do not. These other classes are abstract entities like data repositories, factories, controllers etc. that are meant to split software into understandable pieces with clear responsibilities that work together to make things happen.<p>The point is that this collaboration happens solely by these pieces sending each other messages (calling methods) that describe their intent, without needing to know how exactly the message is being processed. This style of communication is the key characteristic of object orientation, and even an introduction should probably put their focus on this aspect rather than „modeling the real world“, which isn‘t really something that is done this way in practice.<p>All this being said, I do see the appeal of the real-world rhetoric in that it seems much more approachable than ralking about little communicating abstract things. I wonder how to balance this.
When I write Python it’s exclusively without OOP. It’s totally possible to write Python in a solely functional manner. You make heavy use of NamedTuple, Enum, itertools, functools, and mypy annotations.<p>I can approach writing Python essentially the same way I’d write Haskell using the above strategy. I think it looks really nice.<p>I’ve turned a few people away from the dark path of OOP by writing in this style as well. They’re usually turned when they see how easy it is to test just regular functions with no need for magic mocks and the like.