The new node-recovery code got me thinking about design issues. The code is simple, but spread out over several disparate sections of code. As usual, I created a view node while I worked on this task. It's called 'Node recovery' in the projects file.
View nodes work extremely well during development, as I have often said. However, project nodes have only an intermediate-length lifetime. Soon or later, and usually sooner rather than later, view nodes become mostly irrelevant. While exercising this afternoon I suddenly realized that classes offer a way of making views permanent. This is, truly, a new design pattern for me. Previously, I had considered classes as mostly encapsulation devices. Considering classes as primarily a view on a "slice" of code is not the same. It's not clear how important this pattern is. For example, the node- recovery code could be quite adequately described as "everything related to c.nodeConflictList." This includes c.nodeConflictFileName and all the "pieces" of code that use either ivar. Important: I know from experience that the notion "everything related to c.nodeConflictList" is actually a very effective way of dealing with the code. In particular, searching for c.nodeConflictList is enough to see everything I need to know. It may seem a bit clunky, but in practice this "process-oriented" (search for a key data) works well and sticks in my memory. Let's consider the alternative in more detail: 1. The c.nodeResolver *class* would indeed provide a view of most of the code. That's a plus, but to see how the code gets used one would still need to search for all the places Leo's code uses this class. 2. The c.nodeResolver class would indeed provide better encapsulation. In this case, it would hide both c.nodeConflictList and c.nodeConflictFilename. This is a double-edged business. It's good to draw attention to the links between data, but the down side is that everything gets hidden behind a curtain. Especially for simple classes, the effort of setting up the class and calling its methods be counter-productive: the "encapsulation" hides the details that are kinda useful to see directly. In the present situation, I'm not sure the advantages outweigh the drawbacks. No matter, it's fun to think of classes in this new way. It's another tool in the arsenal. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
