Hi Tony,
I do understand your decision to make the class Public. I just don’t agree with it.
If the class is Public, it better “work” for any subscriber.
Sorry, I'm not sure what gave you that idea.
The fact that two classes are designed to work with each other,
or that one class is designed to work only in conjunction with
another class, does not preclude either from being public.
For example: A BlockTableRecord is a public class.
Does that mean that because you can't add an instance of
a BlockTableRecord to a LayerTable (or any SymbolTable),
that the BlockTableRecord class should not be public?
If the designer wants to restrict the types that a class
can be used with, they're free to do that, and of course,
must ensure that a consumer understands that, and/or
enforces that restriction through code.
I could for example, make the constructor of a class
derived from a TreeNode private or internal, but leave
the TreeNode-based class itself public, which prevents
anyone but me from creating an instance of it and
adding it to any TreeView.
But at the same time, your assertion is undermined by
the simple fact that anyone can remove any TreeNode
from any parent node, and add it to any other TreeNode
in the same or a different TreeView, including ones it was
not designed to work with, and making your TreeNode
class private doesn't prevent them from doing it, because
they can still manipulate the TreeNodes through the public
TreeNode base type's Nodes collection, and the owning
TreeView's Nodes collection.
So there really is nothing served by making the TreeNode
class private, because they are not private objects that
are unavailable to consumers, in the first place.
In order to achieve what making your TreeNode class private
only pretends to achieve, you would have to implement your
own private TreeView class with a private TreeNodeCollection
so that consumers cannot access the nodes at all, and you
would have to implement all of the functionality of that, and
in doing that, you would also prevent any consumer from
extending the functionality by deriving new classes from your
'private' TreeView and TreeNode classes.
So, what your assertion amounts to is that you don't believe
that any consumer should be able to extend or enhance the
functionality of a class, by deriving new classes from it, and
that is a common misconception of people coming from legacy
VB, where there is no concept of consuming and extending
existing classes by deriving new classes from them, and who
generally do not fully understand that very basic concept.
Add your TreeNode to the base TreeView, and it doesn’t “work.”
Yes, That's correct. It doesn't work because it wasn't
designed to work with any TreeView. And that's because
in order for Lazy-loading to work, the tree node depends
on receiving a notification from the owning treeview (that
the node is expanding). There's no other way to do that
(short of a major rewrite of the TreeNode class) and that's
the only reason my 'lazy' FolderTreeNode is dependent on
a specific TreeView-based class.
It seems to me that if the TreeNode is dependent on a custom
TreeView, then that node should be contained within the custom
TreeView. The TreeView should be responsible for providing
information to its client.
A consumer can query the node for its folder, and can also
easily query its parent nodes for their folders, without having
to parse filenames. That's the point to making the class public
and making the Folder property public - to make things easy
for the consumer, rather than create illegitmate dependencies.
Another reason why the FolderTreeNode is public, is because
consumers are supposed to be able to specialize it further by
deriving new types from it. The derived types can override the
virtual methods of their base types, and change the behavior
to suit the consumer's needs. For example, one might want
to create a specialization of a FolderTreeNode that adds child
nodes that do not represent other folders, but instead can
represent any kind of object (like files for example, or nodes
that display different filtered views of files in another control).
Doing any of these things is considered routine in OOP, and
that's why we don't 'privatize' things when doing that serves
no useful purpose, and artificially limits how a consumer can
use the classes we provide.
While the default Icon and the two folder Icons are static,
the File icons are not.
Yes, but that doesn't preclude using statically-cached folder
icons for folders. The point was that you are redundantly
fetching the same icon many times, which is pointless in the
case of a folder icon.
