When considering this question, numerous thoughts arise. To start, it's important to understand that the use of private is limited to compile-time control and does not provide runtime enforcement. Therefore, any notion of utilizing private for security purposes should be disregarded.
The primary purpose of private lies in encapsulation. By marking a field or method as private within a component, you are clearly indicating that it should not be accessed externally. This serves to communicate your intention effectively: It signifies restricted access.
Similarly, the concept of public also operates solely at compile time, with no impact during runtime. Defaulting class members to public may seem irrelevant in practice, but explicitly declaring a member as
public</code signals its intended exposure in the class's API.</p>
<p>These principles hold true in the context of TypeScript overall. In the realm of Angular, there are specific scenarios where having public members in component classes is justified. For example, when implementing the container/component (or smart/dumb) pattern, clarity about which parent members can be accessed by child components is crucial to preventing unauthorized manipulation.</p>
<p>In response to the question:</p>
<blockquote>
<p>Should all members be marked as private like so?</p>
</blockquote>
<p>I emphatically say <strong>no</strong>. Blanket application of <code>private
undermines its purpose, as indiscriminate usage fails to convey any meaningful intent. It is more effective to selectively apply
private on elements requiring restricted access than to overwhelm code with unnecessary restrictions.