Do not use any programming concept, that does not help to solve your problem.
So don't use "class-based object orientation" unless there is a clear indicator that it will help to solve your problem. It should not be the default approach.
However there is the mainstream attitude that OO is the best tool for any problem simply because it was declared to be better than structured programming in the late 1980's to early 1990's.
Meanwhile technology has moved on and made some of OO's trade offs into liabilities.
Michael Feathers
@mfeathers
OO makes code understandable by encapsulating moving parts. FP makes code understandable by minimizing moving parts.
15:27 PM - 03 Nov 2010
Going through Arthur Riel's OOD heuristics (1996) it becomes clear that OO is an approach that manages complexity with complexity. Meanwhile encapsulation doesn't address one core problem:
GOTO was evil because we asked, "how did I get to this point of execution?" Mutability leaves us with, "how did I get to this state?"
14:34 PM - 11 May 2013
Mindless mutability and side effects weren't an issue in single thread environments (Thinking Outside the Synchronisation Quadrant) but given that Moore's law is done, software increasingly has to distribute processing tasks across multiple threads, if not multiple cores.
Even many client side web applications running on mobile client devices today are constrained by the legacy single thread model (single core performance was how the web was built) adopted by current frameworks despite the fact that it is becoming more common for devices to feature multiple but lower power cores.
It isn't that functional programming is fundamentally better - however immutability does limit the possibility that something shared is going to unexpectedly change and it forces a style of processing that relies less on sharing values but more on creating new ones.
Value-oriented programming tends to be simpler than place-oriented programming (PLOP) even when PLOP seems initially easier.
The fundamental tenet seems to be:
Don't share what you mutate (i.e. local mutability is OK)
Don't mutate what you share.
The most amazing achievement of the computer software industry is its continuing cancellation of the steady and staggering gains made by the computer hardware industry. — Henry Petroski
PLOP still has its place but when performance actually counts OO is overhead.
Object-oriented development is good at providing a human oriented representation of the problem in the source code, but bad at providing a machine representation of the solution. It is bad at providing a framework for creating an optimal solution.
So more than a decade ago part of the game industry abandoned object-orientation as a design time representation and embraced a different approach - Entities, components and systems ECS - aligned with the "machine" rather than the problem domain.
Even in 1994 the "Gang of Four" design patterns book stated (p.20):
Favor object composition over class inheritance.
Classes are types but not all types are classes. Classes are not a substitute for types. Polymorphism is about types, not classes (The SOLID Design Principles Deconstructed). So to get polymorphism one does not need OO - just a good type system, preferably one with abstract data types.
Conclusion: Only adopt "class orientation" which is typically mislabelled as "object orientation" if there is a clear benefit to doing so.
"class-based object orientation" carries an inherent complexity which is only appropriate for limited types of problems. Given that this article has a JavaScript tag it needs to be understood that an awful lot of work can be accomplished with just functions, object literals and modules (in my opinion a far more important addition to ES2015 than class).
That said when working with custom elements one really doesn't have much choice because class MyElement extends HTMLElement is just how it works.
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 don't use "class-based object orientation" unless there is a clear indicator that it will help to solve your problem. It should not be the default approach.
However there is the mainstream attitude that OO is the best tool for any problem simply because it was declared to be better than structured programming in the late 1980's to early 1990's.
Meanwhile technology has moved on and made some of OO's trade offs into liabilities.
Going through Arthur Riel's OOD heuristics (1996) it becomes clear that OO is an approach that manages complexity with complexity. Meanwhile encapsulation doesn't address one core problem:
Mindless mutability and side effects weren't an issue in single thread environments (Thinking Outside the Synchronisation Quadrant) but given that Moore's law is done, software increasingly has to distribute processing tasks across multiple threads, if not multiple cores.
Even many client side web applications running on mobile client devices today are constrained by the legacy single thread model (single core performance was how the web was built) adopted by current frameworks despite the fact that it is becoming more common for devices to feature multiple but lower power cores.
It isn't that functional programming is fundamentally better - however immutability does limit the possibility that something shared is going to unexpectedly change and it forces a style of processing that relies less on sharing values but more on creating new ones.
Value-oriented programming tends to be simpler than place-oriented programming (PLOP) even when PLOP seems initially easier.
The fundamental tenet seems to be:
PLOP still has its place but when performance actually counts OO is overhead.
Data-Oriented Design: Mapping the problem (2018):
So more than a decade ago part of the game industry abandoned object-orientation as a design time representation and embraced a different approach - Entities, components and systems ECS - aligned with the "machine" rather than the problem domain.
Even in 1994 the "Gang of Four" design patterns book stated (p.20):
Classes are types but not all types are classes. Classes are not a substitute for types. Polymorphism is about types, not classes (The SOLID Design Principles Deconstructed). So to get polymorphism one does not need OO - just a good type system, preferably one with abstract data types.
Conclusion: Only adopt "class orientation" which is typically mislabelled as "object orientation" if there is a clear benefit to doing so.
"class-based object orientation" carries an inherent complexity which is only appropriate for limited types of problems. Given that this article has a JavaScript tag it needs to be understood that an awful lot of work can be accomplished with just functions, object literals and modules (in my opinion a far more important addition to ES2015 than class).
That said when working with custom elements one really doesn't have much choice because
class MyElement extends HTMLElementis just how it works.