You need to sign in to do that
Don't have an account?

Elaboration on Lightning Framework
I was reading up on Lightning and found this in their docs (https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/intro_benefits.htm):
"Components are encapsulated and their internals stay private, while their public shape is visible to consumers of the component. This strong separation gives component authors freedom to change the internal implementation details and insulates component consumers from those changes."
Can someone explain in layman's terms for someone who is a beginner developer? thanks.
"Components are encapsulated and their internals stay private, while their public shape is visible to consumers of the component. This strong separation gives component authors freedom to change the internal implementation details and insulates component consumers from those changes."
Can someone explain in layman's terms for someone who is a beginner developer? thanks.
Now maybe there are lots of places that call the square root function, they all send a number and get back an answer. Maybe the developer of the square root funciton has found a way to make her function better/faster/smaller, she can change the internals of the function, and because she has encapsulated it and created an interface for it, none of the other code that calls it will need to be modified.
Good info here about encapsulation and object oriented programming: http://codebetter.com/raymondlewallen/2005/07/19/4-major-principles-of-object-oriented-programming/
And it is the same for the lightning components (although I haven't played around with them much yet). You will want to create them so that the internals can be changed but it won't matter to the other components that use/connect to it.
Make sense?
All Answers
Now maybe there are lots of places that call the square root function, they all send a number and get back an answer. Maybe the developer of the square root funciton has found a way to make her function better/faster/smaller, she can change the internals of the function, and because she has encapsulated it and created an interface for it, none of the other code that calls it will need to be modified.
Good info here about encapsulation and object oriented programming: http://codebetter.com/raymondlewallen/2005/07/19/4-major-principles-of-object-oriented-programming/
And it is the same for the lightning components (although I haven't played around with them much yet). You will want to create them so that the internals can be changed but it won't matter to the other components that use/connect to it.
Make sense?