With Java style OOP there's a lot of ceremony involved in making classes composable compared to pure functions, and if you're changing a class it's harder to tell whether it will break dependencies and composability while changing a pure function is in principle fine as long as the parameter and return contracts stay the same.
For building UI and application flow it helps a lot to have a set of components that are easy to judge whether they compose well and to what extent they're likely to cause problems when modified. Certain OOP implementations overcome this, you could check out the GUI library and contracts in Racket, Common Lisp CLOS or perhaps Pharo Smalltalk.
Depends on the purpose and who's implementing something. In single threaded applications mutable data structures implemented as classes might be a good option for performance reasons.
Golang has structs, they're kinda-sorta object-like, but no classes. Rust is designed to be a good fit for C++ developers and sticks to inherited designs except when it conflicts with the borrower and type system.
1) These principles are applicable to any paradigm. There are lots of books about using the clean architecture with OOP, but very few resources about that with any other. Also, fronted is more close to multi-paradigm and FP than to OOP.
2) No need for them in this particular example. They would complicate the post so it would become more difficult for people who aren't familiar with the concept.
I wanted to keep the post as close to the real world as possible but as simple as possible at the same time.
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.
nice article! I have questions:
With Java style OOP there's a lot of ceremony involved in making classes composable compared to pure functions, and if you're changing a class it's harder to tell whether it will break dependencies and composability while changing a pure function is in principle fine as long as the parameter and return contracts stay the same.
For building UI and application flow it helps a lot to have a set of components that are easy to judge whether they compose well and to what extent they're likely to cause problems when modified. Certain OOP implementations overcome this, you could check out the GUI library and contracts in Racket, Common Lisp CLOS or perhaps Pharo Smalltalk.
so, class itself is a bad design? the new comers of programming langue(rust,t go) just remove it.
Depends on the purpose and who's implementing something. In single threaded applications mutable data structures implemented as classes might be a good option for performance reasons.
Golang has structs, they're kinda-sorta object-like, but no classes. Rust is designed to be a good fit for C++ developers and sticks to inherited designs except when it conflicts with the borrower and type system.
Thanks!
1) These principles are applicable to any paradigm. There are lots of books about using the clean architecture with OOP, but very few resources about that with any other. Also, fronted is more close to multi-paradigm and FP than to OOP.
However, I wrote about OOP as well, take a look 😃
2) No need for them in this particular example. They would complicate the post so it would become more difficult for people who aren't familiar with the concept.
I wanted to keep the post as close to the real world as possible but as simple as possible at the same time.