Information Hiding v.s. Static Type Safety

Question

I'm working on a project with others and we have a discussion about information hiding and static type safety. Our scenario is described below.

Language: C++11

Scenario: We want to create a tree-like structure. Each tree nodes has its own class, which all are sub-types of base class NodeType. Each sub-type has its own rule to link other nodes. For example, NodeTypeA, NodeTypeB and NodeTypeC are sub-classes of NodeType, and

• NodeTypeA can only has NodeTypeB as its first child, NodeTypeA as its second child.
• NodeTypeB can only has NodeTypeB as its childron. (It may have any number of childron)
• NodeTypeC can only has NodeTypeA as its first child, NodeTypeB as its second child.

The example may have recursion problem, but for illustration is fine.

Now there is a Factory class to create each node:

• createNodeTypeA
• createNodeTypeB
• createNodeTypeC

There is a class, Builder, that wants to convert user text input to the tree.

Builder need not know information about each node's type. It just carries pointers got from Factory, and passes them to another Factory's method. In Builder's perspective, all node's type can be the base class NodeType.

Dilemma:

If we value Information Hiding more, the Factory's method should be:

• NodeType *createNodeTypeA(NodeType *first, NodeType *second)
• NodeType *createNodeTypeB(std::vector<NodeType *> children)
• NodeType *createNodeTypeC(NodeType *first, NodeType *second)

and to provide correctness, we have to provide run-time check on each parameter in Factory's method.

If we value Static Type Safety more, the Factory's method should be:

• NodeTypeA *createNodeTypeA(NodeTypeB *first, NodeTypeA *second)
• NodeTypeB *createNodeTypeB(std::vector<NodeTypeB *> childron)
• NodeTypeC *createNodeTypeC(NodeTypeA *first, NodeTypeB *second)

and Builder must know sub-types of each node. What we gain is type safety.

The figure below illustrates the two ways:

Discussion:

Favor Information Hiding:

• Information hiding itself is important. Developers of Builder can work without knowledge of sub-types of nodes.
• We can compensate the lose of static type safety by code review, testing and automatic analyzing tool. A qualified team is expected to complete those pretty well.

Favor Static Type Safety:

• Increase confidence of the program's correctness.
• When calling Factory's method, the type information (which is indicated by function name) has exposed to Builder. The one more thing Builder is expected to do is just to preserve it.
• If we erased type information, then we would violate several good code practices suggested by C++ Core Guidelines, which would cause code to be error-prone:
  • Prefer compile-time checking to run-time checking
  • Make interfaces precisely and strongly typed
  • Avoid adjacent unrelated parameters of the same type
• Avoid corresponding testing time and run-time check.

Question:

Which one may be a good practice? We value long-term impact more.

Answer 1

NodeType *createNodeTypeA(NodeType *first, NodeType *second)
NodeType *createNodeTypeB(std::vector<NodeType *> children)
NodeType *createNodeTypeC(NodeType *first, NodeType *second)

This does not "hide information", Builder still knows which factory it calls, and which data it should pass to it. So using dynamic type does not seem to give any benefit in this case

What could be done to actually make Builder to be unavare of node type, you couls use a single factory:

NodeType *createNode(std::vector<NodeType*> children)

But this does not allow to specify the node type. This is often the case with constructing, and in general puts a question: is it in principle possible to remove the node type information from the Builder. Maybe the decoupling should rather be on consiming/preocessing side.

Answer 2

Favor Information Hiding:

• Information hiding itself is important. Developers of Builder can work without knowledge of sub-types of nodes.

This is incorrect, because the arguments passed to the factory methods need to be of a certain (run-time) type. Therefore, your program needs to be aware of subtypes when building the tree, regardless whether the relations are checked at compile time or run time.

• We can compensate the loss of static type safety by code review, testing and automatic analyzing tool. A qualified team is expected to complete those pretty well.

Or you can save yourself lots of work by letting the compiler do its work.

The real problem seems to be that your interface is poorly designed. Different subtypes require knowledge of each other, so they are not independent and not interchangeable. Ask yourself how much extensibility your design actually offers and how much you actually need (if you cannot come up with a use case that could realistically occur in the near future, you don't need it).

I suspect that the cause of this design failure is the fact that you are representing your tree data structure intrusively, i.e. storing the relation between nodes as data of the nodes themselves. The only distinction between the subtypes you mention is the different relations they have to other nodes. Therefore, if you separate these relations from the representation of your nodes, you may end up without the need for subtyping nodes - or, at least, be able to provide a better abstraction.

The difficulty of such a change is that functionality that uses the relations between nodes needs to be reformulated as a graph (search) algorithm. This often requires a change of mindset. Using the Boost Graph Library will help you with this and provides data structure and algorithms in a way that makes it easy to separate the tree representation, node/edge data representation and algorithms.

Answer 3

I think a little more context would have been appreciated :).

Let me rephrase your dilemma :

• You want to be able to see a tree in the most abstract way possible. You want to be able to say : "A tree is just a non empty collection of Nodes that have one and only one parent (except the root node) that can do whatever a general tree can do".
• You want to be able to check for the invalidity of the Tree quickly.

An algorithm that builds up the tree must be aware of the different node types and build a valid tree. If the algorithm is being supplied a stream of nodes, it should be able to tell, after checking, which node should go where. If it sees an invalid input or is forced to create an invalid tree, it simply halts and prints error.

So, define a Tree containing only methods that take a NodeType as the parameter such as findChildren, getRoot, getSize, getDepth etc. You can call your Parser(algorithm) after giving it a method buildTree which returns a NodeType(which is equivalent to a Tree !!!). We will decide on whether a node is NodeTypeA, NodeTypeB, and NodeTypeC by looking at the payload of the NodeType which can contain an enum such as TypeA, TypeB etc. All the logic that distinguishes between the node types will be in the Parser!

In conclusion, we used something called the Parser(or Algorithm) which is aware of the different node types to separate concerns from the Tree abstraction which can do very general Tree things.

Answer 4

It is a faulty comparison

"Information hiding" and "static data typing" are not opposing concepts and are not mutually exclusive neither absolutely nor relatively.

This is a false dichotomy that skews away from the true issue which @DDmmr answer touches - design. Then a related comment gives a key clue: The tree structure is an Abstract Syntax Tree (AST)] of a simple script

---

The design is missing a grammar for the 'simple script'

There is a class, Builder, that wants to convert user text input to the tree.

I suggest that this design statement conflates parsing with object construction leading directly to the OP's question. Parsing requires a defined structure of the "simple script." This definition is called a grammar.

A grammar describes the fundamental bits of the "simple script" as well as the allowable combinations, and combinations of combinations, and so on. Inevitably certain (complex) bits will map directly as Nodes and Node subtypes (and potentially related properties).

Importantly, all these distinct bits from fundamental to most complex have names, e.g. "number", "keyword", "digit", "letter", "operator", etc.

---

Separation of concerns

The AST "named nodes" are a metadata, an abstraction of concrete Node objects yet to be built. This metadata is the "seam" separating the AST from Node tree implementation.

The design then is three general pieces: a defined grammar, parsing, and concrete Node object construction.

---

Node implementation Design

Parsing's output is the AST. But the eventual Node tree is derived from the AST, it is not the AST. But I can certainly see the confusion. This feels like an artificial abstraction but it is an important design point.

Now the Builder will take the AST. Note that the Node relation rules are already baked into the AST's structure. Thus the Builder constructs a Node tree based solely on the AST structure without explicit knowledge of these rules.

I'm guessing that the "simple script" is not full blown general purpose scripting language so parsing is truly simple but do not let this lull you into violating Single Responsibility a.k.a. Separation of Concerns.

Perhaps the AST does not need to be utterly parsed out into elements/nodes of script fundamental particles. Maybe there are NodeMetaData objects, let's say, in the AST that correspond to Node super class properties.

---

The OP quandary is designed away

"Information Hiding" is inherently appropriate given the separation of concerns and a thoughtfully designed Builder. Static type parameters give way to an AST object with well defined metadata.

Builder and factories do not take Node nor subtype objects as arguments. Builder controls stepping through the AST and factories are instantiated and called based on the AST metadata. Builder assembles the NodeTree from factory-created NodeTree parts.

Node tree construction is potentially complex so study construction design patterns such as "Builder" and "Factory". Note the factory pattern varies based on complexity.

Answer 5

Information hiding is an external benefit. Given class A, A has zero benefit in hiding it’s information. It doesn’t help the class do it’s job and it doesn’t help the developer reason about the code. It helps external developers who don’t have to be exposed to useless knowledge. Hiding information is a favor your class does for other classes.

Static type checking is a benefit to your class and the class developers. It benefits the class because it needs to do less validation. Give class A and method Foo, that takes an integer and returns a decimal. Method Foo doesn’t have to check to see if the integer null or an array or something else, that check is either done at compile time or at runtime elsewhere inside that method it WILL be an integer. If Foo is private it will return a decimal. This is a benefit for your developers.

Now, whether you really need to make this trade off I can’t say, but information hiding can be dispensed with. The negative’s are external and thus not directly your problem.

Update in response to a comment: imagine that you have a procedural implementation of a sorting algorithm, it uses several global variables and a couple of functions to return intermediate results. It is absolutely rock solid, fast, efficient, great big O. Not the best target for rewriting using object oriented design, but you are doing the rest of the application. If you just wrap this in a class, it’s still a rock solid implementation that is fast and efficient and bug free. Hiding it’s globals (now class level fields or properties) and private methods doesn’t make it any faster or eliminate any bugs within the class. What it does is prevent anyone else from needing to learn the details of how it operates internally in order to safely use it. Zero benefit for our hypothetical sorting class, huge win for our application.