OOP/FP/FRP
props and cons of FP
props of FP:
Pure functions are easier to reason about
Testing is easier, and pure functions lend themselves well to techniques like property-based testing
Debugging is easier
Programs are more bulletproof
Programs are written at a higher level, and are therefore easier to comprehend
Function signatures are more meaningful
Declarative style
Parallel/concurrent programming is easier
cons of FP:
Writing pure functions is easy, but combining them into a complete application is where things get hard.
The advanced math terminology (monad, monoid, functor, etc.) makes FP intimidating.
For many people, recursion doesn’t feel natural.
Because you can’t mutate existing data, you instead use a pattern that I call, “Update as you copy.”
Pure functions and I/O don’t really mix.
Using only immutable values and recursion can potentially lead to performance problems, including RAM use and speed.
Props and cons of OOP
props of OOP:
OOP models complex things as reproducible, simple structures
Reusable, OOP objects can be used across programs
Allows for class-specific behavior through polymorphism
Easier to debug, classes often contain all applicable information to them
Secure, protects information through encapsulation
cons of OOP:
Steep learning curve: The thought process involved in OO programming may not be natural for some people, and it will take time to get used to it.
The complexity of creating programs: it is very complex to create programs based on the interaction of objects. Some of the key programming techniques, such as inheritance and polymorphism, can be a big challenge to comprehend initially.
Composition vs Inheritance
Inheritance: a class may inherit - use by default - the fields and methods of its superclass. Inheritance is transitive, so a class may inherit from another class which inherits from another class, and so on, up to a base class. Subclasses may override some methods and/or fields to alter the default behavior.
Composition: when a Field’s type is a class, the field will hold a reference to another object, thus creating an association relationship between them. Composition is when the class uses another object to provide some or all of its functionality.
Inheritance: “is a.” E.g. The car is a vehicle.
Composition: “has a.” E.g. The car has a steering wheel.
Inheritance is known as the tightest form of coupling in object-oriented programming. Changing a base class can cause unwanted side effects on its subclasses or even all over the codebase.
Composition is a far looser coupling. Combining with Dependency Injection, it brings more flexibility and also allows us to change runtime behavior.
Inheritance should only be used when:
Both classes are in the same logical domain
The subclass is a proper subtype of the superclass
The superclass’s implementation is necessary or appropriate for the subclass
The enhancements made by the subclass are primarily additive.
Example of using inheritance: client errors classes inherited from the common error, each class has its overridden message.
Last updated