14 Matching Annotations
- Jun 2023
-
stackoverflow.com stackoverflow.com
-
Public and/or protected fields are bad because they can be manipulated from outside the declaring class without validation; thus they can be said to break the encapsulation principle of object oriented programming.
-
When you lose encapsulation, you lose the contract of the declaring class; you cannot guarantee that the class behaves as intended or expected.
-
Using a property or a method to access the field enables you to maintain encapsulation, and fulfill the contract of the declaring class.
-
Exposing properties gives you a way to hide the implementation. It also allows you to change the implementation without changing the code that uses it (e.g. if you decide to change the way data are stored in the class)
-
- Jun 2021
-
developer.mozilla.org developer.mozilla.org
-
The encapsulation is enforced by the language. It is a syntax error to refer to # names from out of scope.
-
-
stackoverflow.com stackoverflow.com
-
Setting an instance variable by going through a setter is good practice, and using two access modifiers is the way to accomplish that for a read-only instance variable
-
- Feb 2021
-
github.com github.com
-
One of the main reasons to work with components is re-usability and portability, but also a delegation of responsibilities. Adding a component should be as easy as simply adding the component without having to know the inner workings (or markup) of this component. A consumer should only be aware of the properties, methods and events of a component. In order to style a child component one has to be aware of the markup as well, which violates this 'delegation of responsibility'-principle.
-
-
en.wikipedia.org en.wikipedia.org
-
They claim that inheritance often breaks encapsulation, given that inheritance exposes a subclass to the details of its parent's implementation.
-
- Oct 2020
-
en.wikipedia.org en.wikipedia.org
-
some programming languages that provide lexical closures view encapsulation as a feature of the language orthogonal to object orientation.
-
- Sep 2020
-
github.com github.com
-
There is a good amount of properties that should mostly be applied from a parent's point of view. We're talking stuff like grid-area in grid layouts, margin and flex in flex layouts. Even properties like position and and the top/right/left/bottom following it in some cases.
-
The main reason using classes isn't a great solution is that it completely breaks encapsulation in a confusing way, the paren't shouldn't be dictating anything, the component itself should. The parent can pass things and the child can choose to use them or not but that is different: control is still in the hands of the component itself, not an arbitrary parent.
-
The RFC is more appropriate because it does not allow a parent to abritrarily control anything below it, that responsibility still relies on the component itself. Just because people have been passing classes round and overriding child styles for years doesn't mean it is a good choice and isn't something we wnat to encourage.
-
For my point of view, and I've been annoyingly consistent in this for as long as people have been asking for this feature or something like it, style encapsulation is one of the core principles of Svelte's component model and this feature fundamentally breaks that. It would be too easy for people to use this feature and it would definitely get abused removing the style safety that Svelte previously provided.
Tags
- core principles
- whose responsibility is it?
- which component/tool/organization/etc. is responsible for this concern?
- consistency
- Svelte: CSS encapsulation
- Svelte: how to affect child component styles
- Svelte: components are their own boss (encapsulation)
- safety (programming)
- core values
- who should have control over this? (programming)
- control (programming)
- breaking encapsulation
- programming: who is responsible for this concern?
- limiting how much library consumers/users can control/override
- design goals
- abuse of feature
- confusing
Annotators
URL
-
- Jan 2019
-
www.bitwig.com www.bitwig.com
-
Grid devices can be nested or layered along with other devices and your plug-ins,
Thanks to training for Cycling ’74 Max, had a kind of micro-epiphany about encapsulation, a year or so ago. Nesting devices in one another sounds like a convenience but there’s a rather deep effect on workflow when you start arranging things in this way: you don’t have to worry about the internals of a box/patcher/module/device if you really know what you can expect out of it. Though some may take this for granted (after all, other modular systems have had it for quite a while), there’s something profound about getting modules that can include other modules. Especially when some of these are third-party plugins.
-