8 ms·

Indeed, functional programming can lead to spaghetti code just as easily as any other paradigm. I’m really growing weary of all these posts around the Internet

Indeed, functional programming can lead to spaghetti code just as easily as any other paradigm. I’m really growing weary of all these posts around the Internet claiming that some particular style of development is better than another, it’s such a very shallow metric. In this particular article, I’m with it on inheritance, I haven’t used it in many years. But I don’t at all follow the author’s argument against encapsulation.

crimsonalucard5 6y ago
>But I don’t at all follow the author’s argument against encapsulation. The authors argument is very simple. Encapsulation means everything contained inside an object CAN only be manipulated by THAT objects public methods. He is saying the concept of encapsulation breaks down when you pass by reference. If the "A" object holds an internal reference to an external "B" object and you manipulate that "B" object externally without going through the api methods of the "A" object you just broke encapsulation by changing the behavior of A by manipulating B externally. It's not even really an argument whether or not this actually occurs. It does occur as shown below. The only argument that can be made in favor of OOP in this case is whether it occurs often enough to be bad or whether breaking encapsulation occasionally is that bad in the first place. But make no mistake... encapsulation breaks in OOP period. IT IS a fallen pillar. class B: def B(): this.X = "Hello" def mutate(x: str) this.X = "I've been changed by {x}!" class A: def A(x: B) this.B = x def mutate() this.B.mutate("A") def displayB() print(this.B.X) b = B() a = A(b) // b is passed by reference. a.mutate() b.mutate("B") // <---- encapsulation broken, b which is referenced inside of 'a' but is mutated outside of 'a'. a.displayB() // <----- should display "I've been changed by A!" if b is encapsulated by a. //However because encapsulation is broken will display "I've been changed by B!" Generally this problem represents a class of errors that don't exist when all values are immutable (AKA functional programming). It is also fixed in a unique way by the borrow checker in rust. Simply put it doesn't matter how good someone is as a developer. This is a case where the language paradigm simply prevents a certain error from happening. A bad developer has a 100% chance to avoid this error in a functional language while even the best developer always has a chance of this error occurring in a non-functional language. Language categorically influences quality of code and probability of spaghetti code occurring. Also, since all objects are generally passed by reference and Since object composition is a pattern common to OOP, the following is a generally true statement: Encapsulation is frequently broken in OOP. Understand? If you don't understand I can explain to you the fundamentals of OOP and FP and how they are different context of programming in general.

crimsonalucard5 6y ago

>But I don’t at all follow the author’s argument against encapsulation. The authors argument is very simple. Encapsulation means everything contained inside an object CAN only be manipulated by THAT objects public methods. He is saying the concept of encapsulation breaks down when you pass by reference. If the "A" object holds an internal reference to an external "B" object and you manipulate that "B" object externally without going through the api methods of the "A" object you just broke encapsulation by changing the behavior of A by manipulating B externally. It's not even really an argument whether or not this actually occurs. It does occur as shown below. The only argument that can be made in favor of OOP in this case is whether it occurs often enough to be bad or whether breaking encapsulation occasionally is that bad in the first place. But make no mistake... encapsulation breaks in OOP period. IT IS a fallen pillar. class B: def B(): this.X = "Hello" def mutate(x: str) this.X = "I've been changed by {x}!" class A: def A(x: B) this.B = x def mutate() this.B.mutate("A") def displayB() print(this.B.X) b = B() a = A(b) // b is passed by reference. a.mutate() b.mutate("B") // <---- encapsulation broken, b which is referenced inside of 'a' but is mutated outside of 'a'. a.displayB() // <----- should display "I've been changed by A!" if b is encapsulated by a. //However because encapsulation is broken will display "I've been changed by B!" Generally this problem represents a class of errors that don't exist when all values are immutable (AKA functional programming). It is also fixed in a unique way by the borrow checker in rust. Simply put it doesn't matter how good someone is as a developer. This is a case where the language paradigm simply prevents a certain error from happening. A bad developer has a 100% chance to avoid this error in a functional language while even the best developer always has a chance of this error occurring in a non-functional language. Language categorically influences quality of code and probability of spaghetti code occurring. Also, since all objects are generally passed by reference and Since object composition is a pattern common to OOP, the following is a generally true statement: Encapsulation is frequently broken in OOP. Understand? If you don't understand I can explain to you the fundamentals of OOP and FP and how they are different context of programming in general.