Design First, But Not Too Much

Starting with a high-level draft of a design document provides a preliminary architectural overview. It sets the stage by outlining the software's main objectives and offers an initial roadmap for the journey ahead. Yet, this is not an exhaustive exercise; the purpose is to sketch, not to draw every detail.

Refining Through Coding

When transitioning from the design phase to coding, new insights invariably emerge. These insights, often unanticipated during the initial design phase, can lead to significant refinements. Incorporating these learnings back into the design doc ensures it remains a living document, continually updated to reflect the project's evolving state.

Ties to Domain-Driven Design (DDD)

The idea of starting with a design document aligns with the principles of Domain-Driven Design (DDD). At the heart of DDD is creating an accurate model that represents the domain, its constraints, and its intricacies. Similarly, the design doc seeks to model the software's architecture and objectives.

Keeping design documents updated and close to the code can be seen as parallel to DDD's concept of a ubiquitous language. Such a practice ensures a shared understanding, bridging any knowledge gap among team members. Furthermore, as DDD encourages collaboration and discussion about the domain, design docs can serve as catalysts for these essential conversations.

Conclusion

While some developers may lean towards diving directly into code, alternating between design and development offers a balanced perspective. It promotes clarity, foresight, and adaptability, qualities indispensable in a constantly evolving domain.

For those skeptical about the utility of design docs, consider them as extensions of READMEs. Naming them DESIGN.md or something similar and placing them in the project repository ensures they're accessible and continually relevant.

so port mappings will not work

but note that this option is only avaiable on linux. Not on macOS or Windows.

so a docker-compose file or docker run command working on linux might not work on macOS with this

The law of leaky abstractions means that whenever somebody comes up with a wizzy new code-generation tool that is supposed to make us all ever-so-efficient, you hear a lot of people saying “learn how to do it manually first, then use the wizzy tool to save time.” Code generation tools which pretend to abstract out something, like all abstractions, leak, and the only way to deal with the leaks competently is to learn about how the abstractions work and what they are abstracting. So the abstractions save us time working, but they don’t save us time learning.

https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/

old article, but had a lot of fun reading. abstractions save us time working, but they don’t save us time learning..

ChatGPT4 and other AI tools are sort of same I think. Although they also do save time some time learning by being a high-class personal tutor that answers my flood of questions without being irritated.

I mostly use AI tools for coding in these 2 reasons:

• To solve a conceptual problem
  • Large scale: ex. How would I design the structure of a new database
  • Smaller scale: ex. How would I implement this service function in my api-server
• To reduce menial keyboard typing of stuff.
  • Implement a type predicate for this interface A

    Stuff I used

    I used chatGPT (both paid and free), Google Bard, new Bing, and HuggingFace chat, Hugging Face Code VSC extension so far.

    How I use

    I mostly use ChatGPT 4 for the larger conceptual problem. Because it has the highest context retention and reasoning. The smartest one. But this one has a message cap for 25 messages/3 hrs

So For menial tasks I would use anything else.

Miscellaneous

• new bing for search.
• Hugging Face chat is not really credible IMO. But since it is open-source seems to get a lot of updates. Also the most fun to play with because it spits out lots of funny nonsense
• Hugging Face code is also decent if you don't want to spend money on Github copilot.

there are many ways to format a string in python

• String concatenation.
  • "My name is " + my_name + "."
• % format
• "My name is %s.".format(my_name)
• "".join(["My name is " , my_name , "."])
• f-strings (string literals)
  • f"My name is {my_name}."

We can think about some aspects to consider when choosing which method to use.

First,need to decide which implementation are we using? CPython? PyPI? Rust-Python? CPython is most used, so talking about that.

Then,

• Usability. easy to make mistakes? easy to write code?
• Performance.
  • Speed. How fast is it for large strings or when it is repeated?
  • Memory usage. How many new strings, i.e. PyObjects

This blog is about performance part. For Usability you can refer to many good posts, or realpython.org, or google python guide.

Most performance issue in CPython is due to creation of PyObject structs. While strings look mutable in python source code, under the hood new PyObject is created everytime a string is updated.

so "My name is " + my_name + "." usually shows worst performance. % format str.format() ''.join(list_of_str_to_join) these 3 joins the string at once, but with additional parsing.

f-string, introduced at python 3.6, called ''.join() as subroutine in its alpha stage. Then in this discussion, a patch was made to join them straight from the stack using a new Opcode BUILD_STRING.

refrences https://hg.python.org/cpython/rev/28e280915508#l10.1 https://bugs.python.org/issue27078

Intent

Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates.

Motivation

Consider a compiler that represents programs as abstract syntax trees. It will need to perform operations on abstract syntax trees for “static semantic” analyses like checking that all variables are defined. It will also need to generate code. So it might define operations for type-checking, code optimization, flow analysis, checking for variables being assigned values before they’re used, and so on. Moreover, we could use the abstract syntax trees for pretty-printing, program restructuring, code instrumentation, and computing various metrics of a program.

Most of these operations will need to treat nodes that represent assignment statements differently from nodes that represent variables or arithmetic expressions. Hence there will be one class for assignment statements, another for variable accesses, another for arithmetic expressions, and so on. The set of node classes depends on the language being compiled, of course, but it doesn’t change much for a given language. This diagram shows part of the Node class hierarchy. The problem here is that distributing all these operations across the various node classes leads to a system that’s hard to understand, maintain, and change. It will be confusing to have type-checking code mixed with pretty-printing code or flow analysis code. Moreover, adding a new operation usually requires recompiling all of these classes (not really relevant for python). It would be better if each new operation could be added separately, and the node classes were independent of the operations that apply to them.

We can have both by packaging related operations from each class in a separate object, called a visitor, and passing it to elements of the abstract syntax tree as it’s traversed. When an element “accepts” the visitor, it sends a request to the visitor that encodes the element’s class. It also includes the element as an argument. The visitor will then execute the operation for that element—the operation that used to be in the class of the element.

For example, a compiler that didn’t use visitors might type-check a procedure by calling the TypeCheck operation on its abstract syntax tree. Each of the nodes would implement TypeCheck by calling TypeCheck on its components (see the preceding class diagram). If the compiler type-checked a procedure using visitors, then it would create a TypeCheckingVisitor object and call the Accept operation on the abstract syntax tree with that object as an argument. Each of the nodes would implement Accept by calling back on the visitor: an assignment node calls VisitAssignment operation on the visitor, while a variable reference calls VisitVariableReference. What used to be the TypeCheck operation in class AssignmentNode is now the VisitAssignment operation on TypeCheckingVisitor.

To make visitors work for more than just type-checking, we need an abstract parent class NodeVisitor for all visitors of an abstract syntax tree. NodeVisitor must declare an operation for each node class. An application that needs to compute program metrics will define new subclasses of NodeVisitor and will no longer need to add application-specific code to the node classes. The Visitor pattern encapsulates the operations for each compilation phase in a Visitor associated with that phase. With the Visitor pattern, you define two class hierarchies: one for the elements being operated on (the Node hierarchy) and one for the visitors that define operations on the elements (the NodeVisitor hierarchy). You create a new operation by adding a new subclass to the visitor class hierarchy. As long as the grammar that the compiler accepts doesn’t change (that is, we don’t have to add new Node subclasses), we can add new functionality simply by defining new NodeVisitor subclasses.

Applicability

Use the Visitor pattern when

• an object structure contains many classes of objects with differing interfaces, and you want to perform operations on these objects that depend on their concrete classes.
• many distinct and unrelated operations need to be performed on objects in an object structure, and you want to avoid “polluting” their classes with these operations. Visitor lets you keep related operations together by defining them in one class. When the object structure is shared by many applications, use Visitor to put operations in just those applications that need them.
• the classes defining the object structure rarely change, but you often want to define new operations over the structure. Changing the object structure classes requires redefining the interface to all visitors, which is potentially costly. If the object structure classes change often, then it’s probably better to define the operations in those classes.

  Structure

  

  Participants

• Visitor (NodeVisitor)
  • declares a Visit operation for each class of ConcreteElement in the object structure. The operation’s name and signature identifies the class that sends the Visit request to the visitor. That lets the visitor determine the concrete class of the element being visited. Then the visitor can access the element directly through its particular interface
• Concrete Visitor (TypeCheckingVisitor)
  • implements each operation declared by Visitor. Each operation implements a fragment of the algorithm defined for the corresponding class of object in the structure. ConcreteVisitor provides the context for the algorithm and stores its local state. This state often accumulates results during the traversal of the structure.
• Element (Node)
  • defines an Accept operation that takes a visitor as an argument.
• ConcreteElement (AssignmentNode, VariableRefNode)
  • implements an Accept operation that takes a visitor as an argument.
• ObjectStructure (Program)
  • can enumerate its elements.
  • may provide a high-level interface to allow the visitor to visit its elements.
  • may either be a composite or a collection such as a list or a set.

    Collaborations

• A client that uses the Visitor pattern must create a ConcreteVisitor object and then traverse the object structure, visiting each element with the visitor.
• When an element is visited, it calls the Visitor operation that corresponds to its class. The element supplies itself as an argument to this operation to let the visitor access its state, if necessary. The following interaction diagram illustrates the collaborations between an object structure, a visitor, and two elements:

  Consequences

  Some of the benefits and liabilities of the Visitor pattern are as follows:

1. Visitor makes adding new operations easy. Visitors make it easy to add operations that depend on the components of complex objects. You can define a new operation over an object structure simply by adding a new visitor. In contrast, if you spread functionality over many classes, then you must change each class to define a new operation.

2. A visitor gathers related operations and separates unrelated ones. Related behavior isn’t spread over the classes defining the object structure; it’s localized in a visitor. Unrelated sets of behavior are partitioned in their own visitor subclasses. That simplifies both the classes defining the elements and the algorithms defined in the visitors. Any algorithm-specific data structures can be hidden in the visitor.

3. Adding new ConcreteElement classes is hard. The Visitor pattern makes it hard to add new subclasses of Element. Each new ConcreteElement gives rise to a new abstract operation on Visitor and a corresponding implementation in every ConcreteVisitor class. Sometimes a default implementation can be provided in Visitor that can be inherited by most of the ConcreteVisitors, but this is the exception rather than the rule.

   So the key consideration in applying the Visitor pattern is whether you are mostly likely to change the algorithm applied over an object structure or the classes of objects that make up the structure. The Visitor class hierarchy can be difficult to maintain when new ConcreteElement classes are added frequently. In such cases, it’s probably easier just to define operations on the classes that make up the structure. If the Element class hierarchy is stable, but you are continually adding operations or changing algorithms, then the Visitor pattern will help you manage the changes.

4. Visiting across class hierarchies. An iterator (Iterator Pattern) can visit the objects in a structure as it traverses them by calling their operations. But an iterator can’t work across object structures with different types of elements. Whereas a visitor can visit objects that don't have a common parent class.

5. Accumulating state. Visitors can accumulate state as they visit each element in the object structure. Without a visitor, this state would be passed as extra arguments to the operations that perform the traversal, or they might appear as global variables.

6. Breaking encapsulation. Visitor’s approach assumes that the ConcreteElement interface is powerful enough to let visitors do their job. As a result, the pattern often forces you to provide public operations that access an element’s internal state, which may compromise its encapsulation.

   Implementation

   Each object structure will have an associated Visitor class. This abstract visitor class declares a VisitConcreteElement operation for each class of ConcreteElement defining the object structure. Each Visit operation on the Visitor declares its argument to be a particular ConcreteElement, allowing the Visitor to access the interface of the ConcreteElement directly. Concrete Visitor classes override each Visit operation to implement visitor-specific behavior for the corresponding ConcreteElement class. (some example code omitted)

Here are two other implementation issues that arise when you apply the Visitor pattern:

1. Double dispatch. Effectively, the Visitor pattern lets you add operations to classes without changing them. Visitor achieves this by using a technique called double-dispatch. (not sure what this is yet) It’s a well-known technique. In fact, some programming languages support it directly (CLOS, for example). Languages like C++ and Smalltalk support single-dispatch.

   In single-dispatch languages, two criteria determine which operation will fulfill a request: the name of the request and the type of receiver. For example, the operation that a GenerateCode request will call depends In single-dispatch languages, two criteria determine which operation will fulfill a request: the name of the request and the type of receiver. For example, the operation that a GenerateCode request will call depends on the type of node object you ask. In C++, calling GenerateCode on an instance of VariableRefNode will call VariableRefNode::GenerateCode (which generates code for a variable reference). Calling GenerateCode on an AssignmentNode will call AssignmentNode::GenerateCode (which will generate code for an assignment). The operation that gets executed depends both on the kind of request and the type of the receiver.

   “Double-dispatch” simply means the operation that gets executed depends on the kind of request and the types of two receivers. Accept is a double-dispatch operation. Its meaning depends on two types: the Visitor’s and the Element’s. Double-dispatching lets visitors request different operations on each class of element.(If we can have double-dispatch, then why not triple or quadruple, or any other number? Actually, double-dispatch is just a special case of multiple dispatch, in which the operation is chosen based on any number of types. (CLOS(?) actually supports multiple dispatch.) Languages that support double- or multiple dispatch lessen the need for the Visitor pattern.)

   This is the key to the Visitor pattern: The operation that gets executed depends on both the type of Visitor and the type of Element it visits. Instead of binding operations statically into the Element interface, you can consolidate the operations in a Visitor and use Accept to do the binding at run-time. Extending the Element interface amounts to defining one new Visitor subclass rather than many new Element subclasses.

2. Who is responsible for traversing the object structure? A visitor must visit each element of the object structure. The question is, how does it get there? We can put responsibility for traversal in any of three places: in the object structure, in the visitor, or in a separate iterator object (see Iterator (257)).

   Often the object structure is responsible for iteration. A collection will simply iterate over its elements, calling the Accept operation on each. A composite will commonly traverse itself by having each Accept operation traverse the element’s children and call Accept on each of them recursively.

   Another solution is to use an iterator to visit the elements. In C++, you could use either an internal or external iterator, depending on what is available and what is most efficient. In Smalltalk, you usually use an internal iterator using do: and a block. Since internal iterators are implemented by the object structure, using an internal iterator is a lot like making the object structure responsible for iteration. The main difference is that an internal iterator will not cause double-dispatching—it will call an operation on the visitor with an element as an argument as opposed to calling an operation on the element with the visitor as an argument. But it’s easy to use the Visitor pattern with an internal iterator if the operation on the visitor simply calls the operation on the element without recursing.

   You could even put the traversal algorithm in the visitor, although you’ll end up duplicating the traversal code in each ConcreteVisitor for each aggregate ConcreteElement. The main reason to put the traversal strategy in the visitor is to implement a particularly complex traversal, one that depends on the results of the operations on the object structure. We’ll give an example of such a case in the Sample Code.

   Sample Code

   In C++, I try to rewrite in python3. omitted

   Known Uses

   check in book.

   Related Patterns

   Composite: visitors can be used to apply an operation over object hierarchy defined by the Composite Pattern. Interpreter: Visitor pattern may be applied to the interpretation

Provide a way to access the elements of an aggregator object sequentially w/o exposing its underlying representation

Also Known As

Cursor

Motivation

An aggregate object needs a way to access elems w/o exposing details. And you might also need different ways to traverse it too. But you don't want to bloat the interface w/ too many options for traversals.

The key idea in this pattern is to take the responsibility for access and traversal out of the list object and put it into an iterator object. Iterator class will define interface to traverse a List object, as well as keeping track of current elem.

Separating the traversal mechanism from the List object lets us define iterators for different traversal policies without enumerating them in the List interface. For example, FilteringListIterator might provide access only to those elements that satisfy specific filtering constraints.

Notice that the iterator and the list are coupled, and the client must know that it is a list that’s traversed as opposed to some other aggregate structure. Hence the client commits to a particular aggregate structure. It would be better if we could change the aggregate class without changing client code. We can do this by generalizing the iterator concept to support polymorphic iteration. Then an abstract class may be defined, making iterator mechanism become independent of concrete aggregate classes. The remaining problem is how to create the iterator. Since we want to write code that’s independent of the concrete List subclasses, we cannot simply instantiate a specific class. Instead, we make the list objects responsible for creating their corresponding iterator. This requires an operation like CreateIterator through which clients request an iterator object.

CreateIterator is an example of a Factory Method. We use it here to let a client ask a list object for the appropriate iterator. The Factory Method approach give rise to two class hierarchies, one for lists and another for iterators. The CreateIterator factory method “connects” the two hierarchies.

Applicability

Use the Iterator pattern • to access an aggregate object’s contents without exposing its internal representation. • to support multiple traversals of aggregate objects. • to provide a uniform interface for traversing different aggregate structures (that is, to support polymorphic iteration).

Structure

Participants

• Iterator
  • defines an interface for accessing and traversing elements.
• ConcreteIterator
  • implements the Iterator interface.
  • keeps track of the current position in the traversal of the aggregate.
• Aggregate
  • defines an interface for creating an Iterator object.
• ConcreteAggregate
  • implements the Iterator creation interface to return an instance of the proper ConcreteIterator.

    Collaborations

  • A ConcreteIterator keeps track of the current object in the aggregate and can compute the succeeding object in the traversal.

    Consequences

    The Iterator pattern has three important consequences:

1. It supports variations in the traversal of an aggregate. Complex aggregates may be traversed in many ways.

2. Iterators simplify the Aggregate interface. Iterator’s traversal interface obviates the need for a similar interface in Aggregate, thereby simplifying the aggregate’s interface.

3. More than one traversal can be pending on an aggregate. An iterator keeps track of its own traversal state. Therefore you can have more than one traversal in progress at once.

   Implementation (Long)

   Iterator has many implementation variants and alternatives. Some important ones follow. The trade-offs often depend on the control structures your language provides. Some languages even support this pattern directly.

4. Who controls the iteration? Internal iterator are usually easier to use, as they define the iteration logic. External iterator, meaning client advance traversal, request next elem explicitly, are more flexible.

5. Who defines the traversal algorithm? The iterator is not the only place where the traversal algorithm can be defined. The aggregate might define the traversal algorithm and use the iterator to store just the state of the iteration. This kind of iterator is a cursor, since it merely points to the current position in the aggregate. A client will invoke the Next operation on the aggregate with the cursor as an argument, and the Next operation will change the state of the cursor.

   If the iterator is responsible for the traversal algorithm, then it’s easy to use different iteration algorithms on the same aggregate, and it can also be easier to reuse the same algorithm on different aggregates (perhaps strategy pattern?). On the other hand, the traversal algorithm might need to access the private variables of the aggregate. If so, putting the traversal algorithm in the iterator violates the encapsulation of the aggregate.

6. How robust is the iterator? It can be dangerous to modify an aggregate while you’re traversing it. If elements are added or deleted from the aggregate, you might end up accessing an element twice or missing it completely. A simple solution is to copy the aggregate and traverse the copy, but that’s too expensive to do in general.

   A robust iterator ensures that insertions and removals won’t interfere with traversal, and it does it without copying the aggregate. There are many ways to implement robust iterators. Most rely on registering the iterator with the aggregate. On insertion or removal, the aggregate either adjusts the internal state of iterators it has produced, or it maintains information internally to ensure proper traversal. (some examples from book. Not sure what an ET++ is even.. Kofler provides a good discussion of how robust iterators are implemented in ET++ [Kof93]. Murray discusses the implementation of robust iterators for the USL StandardComponents’ List class [Mur93].)

7. Additional Iterator operations. The minimal interface to Iterator consists of the operations First, Next, IsDone, and CurrentItem. (We can make this interface even smaller by merging Next, IsDone, and CurrentItem into a single operation that advances to the next object and returns it. If the traversal is finished, then this operation returns a special value (0, for instance) that marks the end of the iteration.)

   Some additional operations might prove useful. For example, ordered aggregates can have a Previous operation that positions the iterator to the previous element. A SkipTo operation is useful for sorted or indexed collections. SkipTo positions the iterator to an object matching specific criteria.

8. Using polymorphic iterators in C++. (I think this is irrelevant for js or python) Polymorphic iterators have their cost. They require the iterator object to be allocated dynamically by a factory method. Hence they should be used only when there’s a need for polymorphism. Otherwise use concrete iterators, which can be allocated on the stack.

   Polymorphic iterators have another drawback: the client is responsible for deleting them. This is error-prone, because it’s easy to forget to free a heap-allocated iterator object when you’re finished with it. That’s especially likely when there are multiple exit points in an operation. And if an exception is triggered, the iterator object will never be freed.

   The Proxy pattern provides a remedy. We can use a stack-allocated proxy as a stand-in for the real iterator. The proxy deletes the iterator in its destructor. Thus when the proxy goes out of scope, the real iterator will get deallocated along with it. The proxy ensures proper cleanup, even in the face of exceptions. This is an application of the well-known C++ technique “resource allocation is initialization” [ES90]. The Sample Code gives an example.

9. Iterators may have privileged access. An iterator can be viewed as an extension of the aggregate that created it. The iterator and the aggregate are tightly coupled. We can express this close relationship in C++ by making the iterator a friend of its aggregate. Then you don’t need to define aggregate operations whose sole purpose is to let iterators implement traversal efficiently.

   However, such privileged access can make defining new traversals difficult, since it’ll require changing the aggregate interface to add another friend. To avoid this problem, the Iterator class can include protected operations for accessing important but publicly unavailable members of the aggregate. Iterator subclasses (and only Iterator subclasses) may use these protected operations to gain privileged access to the aggregate.

10. Iterators for composites. External iterators can be difficult to implement over recursive aggregate structures like those in the Composite pattern, because a position in the structure may span many levels of nested aggregates. Therefore an external iterator has to store a path through the Composite to keep track of the current object. Sometimes it’s easier just to use an internal iterator. It can record the current position simply by calling itself recursively, thereby storing the path implicitly in the call stack.

    If the nodes in a Composite have an interface for moving from a node to its siblings, parents, and children, then a cursor-based iterator may offer a better alternative. The cursor only needs to keep track of the current node; it can rely on the node interface to traverse the Composite. Composites often need to be traversed in more than one way. Preorder, postorder, inorder, and breadth-first traversals are common. You can support each kind of traversal with a different class of iterator.

11. Null iterators. (wow a base case) A NullIterator is a degenerate iterator that’s helpful for handling boundary conditions. By definition, a NullIterator is always done with traversal; that is, its IsDone operation always evaluates to true.

    NullIterator can make traversing tree-structured aggregates (like Composites) easier. At each point in the traversal, we ask the current element for an iterator for its children. Aggregate elements return a concrete iterator as usual. But leaf elements return an instance of NullIterator. That lets us implement traversal over the entire structure in a uniform way.

    Sample code

    in book as C++, me trying to rewrite in python3

    Known Uses

    Iterators are common in object-oriented systems. Most collection class libraries offer iterators in one form or another. So, refer to docs on collections for your language of choice?

    Related Patterns

Composite: Iterators are often applied to recursive structures such as Composites. Factory Method: Polymorphic iterators rely on factory methods to instantiate the appropriate Iterator subclass. Memento: is often used in conjunction with the Iterator pattern. An iterator can use a memento to capture the state of an iteration. The iterator stores the memento internally.

We are a team of 1~2 yr junior devs, so faced w/ a 450 page book, my study group was overwhelmed. Thankfully, there is a Guide to readers section, which tells you some of the approaches you can take to this book. You can read the 8 most basic patterns: Abstract Factory, Adapter, Composite, Decorator, Factory Method, Observer, Strategy, Template Method. Or follow w/ ch2 case study, which introduces total of 8 patterns, w/ 4 of them also included in Guide to Readers section. Or you can start from one pattern and propagate to other related patterns.

But whichever apporach you take, the end result you want is this: When a problem arises in your daily SW development, you can think of patterns that can solve this problems. You may need to adapt it a bit, like mixing a few patterns together or being smart w/ your implementation. But the key thing is you have a instant pattern match to your problem you can build on.

Our group took the case study route. It was because we wanted to see an actual example of design patterns application. But I don't think it was the optimal way.

The upside of this choice is that it gives you some place to start on the book. It is a 450 page book, w/ about 350 pages being catalog of popular software Design Patterns. Unless you are experienced in both SW and reading, it can be overwhelming. It was for me.

But there was also downside. While reading through [ch2, A Case Study: Designing a Document Editor], we realized the book is 30 yrs old. So the case study was not relatable albeit being a good example. Also, you have to read 50 page of detailed explanations, so it is some reading. A single pattern catalog takes ~12 pages (i think), so if you wish you could have read at least 4 more patterns.

There are also some augmentations you can take, like accompany an online course in the language of your choice. This book came out 30 yrs ago. The example screenshots are old. C++ is old. I mean it is still used extensively, but there can be better examples. If you are doing web dev or ML, C++ is probably not what you would learn. All the catalogs are also in C++. But then again, it also means there are many good online courses in Java, JS, Python, Rust etc.

Now it is the last week of this study, and I think I at least indexed the 8 patterns mentally. Starting from these 8 patterns, I can stem from it as needed, checking out related patterns.

=== This was my 2nd study at this company, following Refactoring 2nd ed by Martin Fowler. We studied a subsection each week, met at lunch and discussed points.

Intent

Encapsulate request as an object, thereby letting you parameterize clients with difference requests, queue or log requests, and support undoable operations

Also Known As

Action, Transaction

Motivation

Sometimes it’s necessary to issue requests to objects without knowing anything about the operation being requested or the receiver of the request.

Here, Menuitem will have reference to a Command's instance, command. command.execute() will be called when this MenuItem is clicked. But MenuItem doesn't need to know about details of Execute(). It suffices to know that it will cause some expected consequence.

Also, different kind of MenuItem will have reference to different type of Command objects. But it doesn't matter. MenuItem will just call MenuItem.Command.Execute().

Then Command subclasses will store reference to receiver of the request, and invoke operations on the receiver as needed. Ex. a PasteCommand could have reference to a Document object, which is supplied to PasteCommand at instantiation. When Execute() is called on PasteCommand, it will run some operations (maybe Document.Paste()) to receiver.

However, OpenCommand's Execute() will do different operations like below.

And sometimes, a MenuItem needs to execute a sequence of commands. Then we can create a macro, MacroCommand, which has a sequence of Command objects that runs in sequence. But this MacroCommand needn't keep a reference to receiver of commands, as each Command will have that.

In each of these examples, notice how the Command pattern decouples operation invoker object from operation performer object. This will give a lot of flexibility in desiging UI. (I guess this is lot like ReactJS hooks?). We can also change commands dynamically, especially for context-sensitive menus. We can also support command scripting by composing commands into larger ones.

All of this is possible because the object that issues a request only needs to know how to issue it; it doesn’t need to know how the request will be carried out.

Applicability

Use the Command Pattern when you want to:

• Parameterize objects by an action to perform. You can express such parameterization in a procedural language with a callback function. Commands are object-oriented replacement for callbacks.
• specify, queue, and execute requests at different times. A command object can have a lifetime independent of the original request. If the receiver of a request can be represented in an address-space independent way, then you can transfer a command object forthe request to a different process and fulfill the request there
• support undo. Command.Execute() can store state for reversing its effects in the command itself. then Command interface must have sth like Unexecute(). Executed command are stored in a history list. You can have unlimited-level undo and redo if you want to, by traversing this history list of commands.
• support logging changes so that they can be reapplied in case of a system crash. Augment Command interface w/ load/store operations, so you can keep a persistent log of changes. When it crashes, reload logged commands from disk and reexecute them in order. I guess this works in simple cases?
• strucute a system around high-level operations built on primitives operations. Such a structure is common in information system that support transactions. A transaction encapsulates a set of changes to data. The Command pattern offers a way to model transaction. Commands have a common interface, letting you invoke all transactions the same way. Also makes it easy to extend the system with new transactions.

  Structure

  

  Participants

• Command
  • declares an interface for executing an operation.
• ConcreteCommand (PasteCommand, OpenCommand)
  • defines a binding between a Receiver object and an action.
  • Implements Execute() by invoking necessary operations on Receiver.
• Client (Application)
  • creates a ConcreteCommand object and sets its receiver.
• Invoker (MenuItem)
  • asks the command to carry out the request.
• Receiver (Document, Application)
  • knows how to perform the operations with carrying out a request. Any object can be a receiver.

    Collaborations

• The client creates a ConcreteCommand object and specifies its receiver.
• An Invoker object stores the ConcreteCommand object.
• The invoker issues a command by doing Invoker.Command.Execute(). If commands are undoable, ConcreteCommand will store state for undoing the command prior to invoking Execute()
• The ConcreteCommand object invokes operations on its receiver to carry out the request.

The following diagram shows the interactions between these objects. It illustrates how Command decouples the invoker from the receiver (and the request it carries out).

Consequences

1. Command decouples invoker from receiver.
2. Commands are first-class objects. They can be manipulated and extended like any other objects.
3. You can assemble commands into a composite command. An example is the MacroCommand class described earlier. In general, composite commands are an instance of the Composite Pattern.
4. Easy to add new commands, because you don't have to change existing classes.

Implementation

1. How intelligent should a command be? One extreme can make command merely a binding between a receiver and the actions that carry out the request. Another extreme it implements everything itself w/o delegating to a receiver at all. The latter extreme is useful when you want to:

• define commands that are independent of existing classes.
• no suitable receiver exists
• command knows its receiver explicitly. For example, a command that creates another application window may be just as capable of creating the window as any other object. Somewhere in between the two extremes are commands that have enough knowledege to find their receiver dynamically.

2. Supporting undo and redo. Commands can support undo and redo capabilities if they provide a way to reverse their execution (ex. Unexecute(), Undo()). A ConcreteCommand class might need to store additional state to do so. This state can include:

• the Receiver object, which actually carries out operations in response to the request.
• the arguments to the operation performed on the receiver
• any original values in the receiver that can change as a result of handling the request. The receiver must provide operations that let the command return the receiver to its prior state.

Usually history list of commands that have been executed is kept, w/ reasonable size limit. Traverse thru the list and call Execute()/Unexecute() as needed.

An undoable command might have to be copied before it can be placed on the history list. That's because the command object that carried out the original request, will perform other requests at later times. Copying is required to distinguish different invoacations of the same command if its state can vary across invocations.

For example, a DeleteCommand that deletes selected objects must store different sets of objects each time it's executed. Therefore the DeleteCommand object must be copied following execution, and the copy is placed on the history list. If the command's state doesn't change, keeping a reference to it in the object is enough. Commands that must be copied before being placed on the history list act as prototypes.

3. Avoiding error accumulation in the undo process. Hysterisis can be a problem in ensuring a reliable semantics-preserving undo/redo mechanism. Erros can accumulate as commands are executed, unexecuted, and reexecuted repeatedly so that an application's state eventually diverges from original values. It may be necessary therefor to store more info in the command to ensure that objects are restored to their original state. The Memento Pattern can be applied to give the command access to this info w/o exposing the internals of other objects.

4. Using C++ Templates. For commands that aren't undoable && don't require arguments. Shown in Sample Code section.

Sample Code

Book C++, me python. not sure what using C++ templates meant above.

Known Uses

some papers, old examples. someting about functors, bojects that are functions.

Related Patterns

Composite Pattern to implement MacroCommands Memento Pattern to keep state the command requires for undoing operations. Prototype Pattern for commands that must be copied before being placed on the history list.

Intent

Decouple an abstraction from its implementation so that the two can vary independently.

Also Known As

Handle/Body

Motivation

Inheritance is usually the way when an abstraction can have several implementations. Sometimes it is not flexible enough.

Say, Window abstract class has many product subclasses IconWindow, ButtonWindow etc. Then, to support platforms, you have explosion of subclasses. (# of product kind) x (# of platforms to support). Better managed in two hiearchies Window for type, WindowImpl for platform.

Also, client code becomes dependent on the platform. for example , to use window on macOS, you would need to instantiate MacIconWindow, MacButtonWindow etc., not just IconWindow or ButtonWindow. This makes porting really difficult. Clients should be able to create a window w/o commiting to a concrete information. i.e. instantiate windows w/o mentioning specific platforms. diagram from book This relationship between Window andWindowImpl abstract classes is Bridge.

Applicability

Use when

• You want to avoid a permanent binding between abstraction and its implementaion. For example, when implementaion must be selected or switched at run-time.
• Both the abstraction and implementation should be extensible by subclassing. Birdge Pattern lets you combine different abstracion and implementaions and also extend them independently.

  Structure

  

  Participants

• Abstraction (Window)
  • defines the abstraction's interface
  • maintains a reference to an object of type Implementor.
• RefmedAbstraction (IconWindow)
  • extends the interface defined by Abstraction.
• Implementor (WindowImp)
  • Defines the inteerface for implementaion classes. Doesn't have to correspond exactly to Abstraction's interface; can be different.
  • Typically, Implementor defines primitives, Abstraction has higher-level operations based on these primitives.
• ConcreteImplementor (XWindowImp, PMWindowImp)
  • implements the Implementor interface and defines its concrete implementation

    Collaborations

• Abstraction forwards client requests to its Implementor object.

  Consequences

1. Decoupling interface and implementation. An implementation is not bound permanently to an interface. It can be configured at run-time. Even possible to change its implementation at run-time.

Also eliminates compile-time dependencies. Changing an implementation class doesn’t require recompiling the Abstraction class and its clients. Essential when binary compatibility for difference versions of a class library.

Encourage layering that can lead to a better-structured system.

2. Improved Extensibility. You can extend the Abstraction and Implementor hiearchies independently.
3. Hiding implementation details from clients. Hide stuff like sharing of implementor objects and the accompanying reference count mechanism (if any).

   Implementation

4. Only one Implementor. then its a degenerate case. why bother? but still can be useful when a change in implementation of a class must not effect existing clients (ie. when recompile no, but relink ok). In C++, can hide class interface of Implementor class in a private header file that isn't provided to clients.
5. Creating the right Implementor object. If Abstraction know about all ConcreteImplementor classes, then it can instantiate one of them in its constructor, i.e. decide using parameters passed to its constructor. ex. a collection class takes small size, then use linked list. if larger size, hash table etc.

Another approach is to choose a default, then change it later accordingly. ex. If collection grows too big, change to hash table.

Also possible to delegate the decision to another oject altogeter. In the Window/WindowImp example, we can introduce a factory object (see Abstract Factory (87)) whose sole duty is to encapsulate platform-specifics. The factory knows what kind of WindowImp object to create for the platform in use; a Window simply asks it for a WindowImp, and it returns the right kind. A benefit of this approach is that Abstraction is not coupled directly to any of the Implementor classes.

3. Sharing implementors. from book about reference count managing for shared Implementors.

   Handle& Handle::operator= (const Handle& other) {
    other._body->Ref();
    _body->Unref();
   
    if(_body->RefCount() == 0_ {
        delete _body;
    }
    _body = other._body;
   
    return *this;
   

``` 4. Using multiple inheritance. In C++, you can use multiple inheritance to combine an interface with its implementaion. Possible in typescript and python too. Ex. a class can inherit publicly from Abstraction, and privately from a ConcreteImplementor. But this relies on static inheritance, binding implementation to its interface. Therefore you can't implement a true Bridge w/ multiple inheritance, at least not in C++.

Sample Code

In book, C++. I rewrite it in python3 skipping details.

Known Uses

only skim thru. What is an ET++? libg++? NXImage?

Related Patterns

Abstract Factory to create and configure a particular Bridge. The Adapter pattern is geared toward making unrelated classes work together. It is usually applied to systems after they’re designed. Bridge, on the other hand, is used up-front in a design to let abstractions and implementations vary independently.

Javascript language specification is standardized, by ECMAScript specification. the ES in ES6 is short for ECMAScript

In ES6, which is the current standard for javascript, using import is the standard.

However, in nodeJS, we often see require to use modules. This is because before ES6 standard, nodeJS introduced CommonJS as its standard, and this used require to use modules.

Comparison

So currently, it is recommended to use import. Some of its advantages are

• The ES6 standard
• import is determined at compile time, asynchronously. so enables:
  • Support for static analysis -> debuggin
  • tree shaking -> removed unused code
  • dynamic code loading. uses Promise to resolve module imports
• can import only needed part of module.

But we still need to konw require as it

• still legacy code base uses this.
• enables dynamic loading of modules at runtime.

  Miscellaneous

  I hear it is pain to create a js module that can handle both import and require.

function mocking using jest fails

description

file A - class Scanner has Scanner.useScan() method, that uses scan() from fileB, but is not injected as parameted, and used using import. file B - has export const scan = () => {}// omit arrow function test T - tests Scanner class from file A, including useScan()

in T, scan is imported using import {scan} from './B' then mocked using jest

// T.spec.ts
jest.mock('./B', () => ({
  scan : jest.fn()
})

however, original function from file B, not the mocked function, is used when testing. This is because we can't DI scan() function at test file, and is instead imported from file A.

// A.ts
import {scan} from './B'

Reason

import {scan} from './B' and import * as scanModule from './B' has different internal workings. first one imports only the function to a variable. So if we mock it, it will stay inside current context. However, second one imports the entire module as an object. So if we mock it, the mocked module will be use even if it is used in a different file.

Solution

1. Use Dependency Injection (IMO Best Practice)

If useScan() takes scan() as argument,

// A.ts
// import {scan} from './B'
class Scanner {
  ////
  useScan(scanFunc: scanFuncType){
   ////
    scanFunc() // omit detai;s
  }

we can use mocked version of scan() as argument for useScan() instead of actualscan() in test file

2. mock the entire module in test file

do either

• import entire module and mock the functions you want.

  // T.spec.ts
  import * as ScanModule from './B'
  

jest.mock('./B', ()=>({ scan: jest.fn() }))

- mock the module before importing function (**not verified**)
```ts
// T.spec.ts
jest.mock('/B')
import {scan} from './B'

then test

```ts // T.spec.ts describe('useScanner', () =>{ testScanner.useScan() // now uses mocked version of scan() expect(scan).toHaveBeenCalled() // scan name can vary })

when using git on macOS, duplicate files appeared after switching branches.

Solution

move your git repo to somewhere not tracked by iCloud

Mechanism

iCloud watches registered directories. When git sweeps files to change branches etc, iCloud will also detect a file change, and try to its own synching routine. Underlying process depends on its synching routine/algorithm.

Explanation

Don't use together a file synching service (iCloud, Dropbox, Google Drive eetc.) and a version control (git, svc etc.). Will run into duplicates. if you use repository hosting service like github, gitlab, Bitbucket), you alreaday get avilability and security you are getting from iCloud.

reference

https://stackoverflow.com/questions/59308049/icloud-drive-desktop-sync-vs-git-deleted-files-reappear-and-duplicates-with-n https://stackoverflow.com/questions/62385234/git-keeps-duplicating-files-and-appending-2-at-end-of-filename

Provide an interface for creating families of related or dependent objects, w/o specifiying their concrete classes.

Also Known As

Kit

Motivation

To enable easy changing of the look, feel of an application. Also clients should stay independent of the prevailing look and feel. WidgetFactory is the topmost abstract class. There will be concrete subclass of WidgetFactory for each look-and-feel standard. ex. MotifWidgetFactory, which returns a Motif scroll bar. PMWidgetFactory, returning a scroll bar for Presentaion Manager. Clients have no idea of WidgetFactory interface. Only use instance of the concrete subclasses, but adhere to interface defined by the abstract class WidgetFactory.

Applicability

• A system should be independent of how its products are created, composed, and represented.
• A system should be configured with one of multiple families of products.
• A family of related product objects is designed to be used together, and you need to enforce this constraint.
• You want to provide a class library of products, and want to reveal interfaces only, not implementation

  Structure

  

  Participants

• AbstractFactory (WidgetFactory)
  • declares an interface for operations that create abstract product objects.
• ConcreteFactory (MotifWidgetFactory, PMWidgetFactory)
  • implements the operations to create concrete product objects.
• AbstractProduct (Window, ScrollBar)
  • declares an interface for a type of product object.
• ConcreteProduct (MotifWindow, MotifScrollBar)
  • defines a product object to be created by the corresponding concrete factory.
    • implements the AbstractProduct interface.
• Client
  • Only use interfaces defined by AbstratFactory and AbstractProduct

    Collaborations

    • Normally a single instance of a ConcreteFactory class is created at run-time. Of course. its a factory. Creates one kind of product. If client wants different product, use another factory.
    • AbstractFactory defers creation of product objects to its ConcreteFactory subclass.

      Consequences

      Benefits & Liabilities

1. It isolates concrete classes. Product class names are isolated in the implementation of the concrete factory. not in client code.
2. _ It makes exchangin product families easy_. The class of concrete factory appears only once in an application, where it's instantiated. So no duplicate code change when changin concrete factory to use.
3. Promotes consistency among products. AbstractFactory enforcement.
4. Supporting new kinds of products is difficult. Fixed interface. What if new product requires extended interface? hard. Lots of code to change. But one possible solution in Implementaion section.

   Implementation

   Some useful techniques for implementing the Abstrat Factory pattern.
5. Factories as singletons.
6. Creating the products. See Factory Method pattern for each product. This overrides I think the constructor() for product classes? If many product families are possible, refer to Prototype pattern. A javascript like pattern I think. Pure Prototype apporach Concrete factory has protype of a product. Factory clones the prototype, and creates the product. Eliminates the need for a new concrete factory calss for each new product family. Prototype variant Possible in languages that treat classes as first-class objects. Define a new factory by initializing an instance of concrete factory with classes of products, not by subclassing. This approach takes advantage of language characteristics, whereas the pure Prototype-based approach is language-independent.
7. Defining extensible factories. AbstractFactory usually defines a different operation for each kind of product it can produce. The kinds of products are encoded in the operation signatures. Adding a new kind of product requires changin the AbstractFactory interface and all the classes that depend on it.

• A more flexible, but less safe design is to add a parameter to operations that create objects. This parameter specified the kind of object to be created. Can be class identifier, integer, whatever. Then AbstractFactory would only need a single make() method with a parmeter indicating the kind of object to create. This is the technique used in the Prototype- and the class-based abstract factories discuessed earlier.
• This variation is easier to use in a dynamically typed language (js, python).
• A inherent problem: All products are returned to the client with the same abstract interface as given by the return type. The client will not be able to differentiate or mkae safe assumptions about the class of a product. If clients need to perform subclass-specific operations, they won't be accessible through the abstract interface. Could do a downcast, but not always feasible or safe, as downcast can fail. This is a classic trade-off for a highly flexible and extensible interface.

  Sample Code

  in C++ in books. if you want dynamic language example, there is also SmallTalk example. But you have to know the C++ example first to understand.

  Known Uses

  Old cases.. Interviews? ET++?

  Related Patterns

  implement using Factory Method, or Prototype A concrete factory is often a Singleton.

@some_decorator
def some_function():
    pass

Intent

Dynamic attachment of responsibilities to an object. A flexible alternative to subclass for extending functionality.

Also Known As

Wrapper

Motivation

For adding responsibilities to individual objects, but not to an entire class. We can do this w/ inheritance. However, if this responsibility(A) can be decided statically, we can be more flexible and enclose the component in another object that does A. We call this enclosing object Decorator.

Decorator conforms to the interface of the component it decorates, so that its prescence is transparent to the component's clients. This Decorator forwards requests to the component's clients and optionally perform additional actions before/after forwarding. Transparency lets you neset decorators recursively, theoretically unlimited amount. Some example involving text editor is in book.

Again, transparenct allows clients to not depend at all on the decoration.

Applicability

Use Decorator

• to add responsibilities to individual objects dynamically and transparently. i.e. w/o affecting other objects
• for responsibilities that can be withdrawn.
• when extension by subclassing is impractical. Sometimes a large number of independent extensions are possible and would produce explosion of subclasses to support every combination. Or a class definition may be hidden or otherwise unavailable for subclassing.

  Structure

• diagram from book*

  Participants

• Component*
• Defines the interfact for objects that can have responsibilities added to them dynamically.

ConcreteComponent

• Defines and object, where additional responsibilities can be attached.

Decorator

• maintains a reference to Component object
• defines an interface that conforms to Component's interface

ConcereteDecorator

• adds responsibilities to the component.

  Collaborations

  Decorator forwards requests to its Component object. It may optionally perform additional operations before/after forwarding the request

  Consequences

  At least 2 key benefits and 2 liabilities:

1. More flexibility then static inheritance. Instead of creating a class for each responsibility, use decorators to add/remove responsibility at runtime simply by attaching and detaching them. Also, by mixing decorators you can also mix and match responsibilities.
2. Avoids feature-laden classes high up in the hiearchy. Decorators add pay-as-you-go approach to adding responsibilities. Instead of trying to support all foreseeable features in a complex, customizable class, you can define a simple class and add functionality incrementally with Decorator objects. A functionality compose of many responsibilities can be made from simple pieces, the decorator. Thus, application need not pay for features it don't use. Even when unforseen extensions arise, they can be added independently from the classes of objects they extend. Extending a complex class may expose details unrelated to the responsibilities you're adding.
3. A decorator and its component aren't identical. A decorator acts as a transparent enclosure. But from object identity point of view, decorated component and component itself is different. Hence you shouldn't rely on object identitiy when you use decorators. (?maybe this means comparing object using memory address?)
4. Lots of little objects. Often result in systems compose of lots of little objects that look alike, and differ only in the way they are interconnnected. Not in their class of in the value of their variables. These systems can be easy to customize for people who already knows them, but can be hard to learn and debug.

   Implementation

   Several issues to consider.
5. Interface conformance. A decorator's object interface must conform to the interface of the component it decorates. ConcreteDecorator classes must there for inherit from a common class (can be language dependent)
6. Omitting the abstract Decorator class. No need to define an abstract Decorator class when you only need to add one responsibility.
7. Keeping Component classes lightweight". To ensure a conforming interface, components and decorators must inherit from a common Component class. Import tant to keep this common class light. Focus on interfacd, not data. Don't make subclasses pay for features they don't need.
8. Changing the skin of an object vs changing its guts. If you need to changes guts, Strategy Pattern is a good example. It is better where Component class is instrinsically heavyweight, so Decorator pattern is too costly to apply. And as Decorator Pattern changes only the skin, the component being decorated need not know about its decorators. Conversely, in Strategy Pattern the component must know about list of strategies it can use. Also, strategy pattern can have its own modified interface. Where Decorator must conform to unified interface. ### Sample code In book, C++. I also rewrite it in python. ### Known uses Graphical, Streams etc. ### Related Patterns Adapter: can also add completely new interface, not just responsibilities. Composite: can be viewed as degenerate composite w/ one component. Strategy: Strategy changes guts, Decorator changes skin.

Intent

Define a family of algorithms, encapsulate each one, make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.

Also Known As

Policy

Motivation

Don't hardwire algorithms to classes that require them. What happens if algorithm changes? What if many classes commonly use this algorithm? What if bug is found, and it needs to be changed? Avoid duplicate code and support different algorithms using the same interface.

diagram from book In this case, Composition class uses Compositor class to call Compose(), which manipulates Composition's members. But which compositor it uses can vary, even at runtime.

Applicability

• Many related classes differ only in their behavior.
• Need different variants of an algorithm
• Algorithm uses data that clients shouldn't know about
• A class defines many behaviors, and these appear as multiple conditional statements in its operations. You can move these conditionals to their Own Strategy class.

  structure

  

  Participants

• Strategy (Compositor)
  • declares an interface common to all algorithms.
    • ConcreteStrategy
    • implements algorithm
• Context (Composition)
  • is configured with a ConcreteStrategy object
  • has reference to a Strategy Object

    Collaborations

    • Context may pass relavant data or itself to Strategy to determine the algorithm. Passing itself also allows callback functionality.
    • A context forwards requests from its clients to its strategy. Clients usually create and pass a ConcreteStrategy object to the context.

      Consequences

1. Familes of related algorithms. Filter out common functionality using inheritance. Subclasses for specific algorithm, which can is reusable.
2. An alternative to subclassing.
3. Strategies eliminate conditional statements. yay.
4. A choice of implementations. Different algorithms, same behavior
5. Clients must be aware of different strategies. So, only use when the variation in behavior is relevant to clients
6. Communication overhead between Strategy and Context. Relevant info, or Context itself is passed. But some algorithms may not use all info, while some use all. If this is an issue, neee tighter coupling between Strategy and Context.
7. Increased number of objects. Sometimes can be avoided by implementing stateless objects that contexts can share. Refer to Flyweight pattern.

   Implementation

8. Defining the Strategy and Context interfaces. Passing the Context itself couples it, but allows explicit request to Context from Strategy. Or you can pass data as parameters to decouple it, but then might pass data that some algorithms don't need. Choose wisely.
9. Strategies as template parameters. Some C++ stuff. If algorithm to use is decided at compile-time, and not changed during run-time.
10. Making Strategy objects optional. Check Context checks if Strategy objects exist. If not, carry out default behavior. if yes, use Strategy. Benefit is clients don't have to deal with Strategy objects at all, unless they don't like the default behavior.

    Sample code

    in book, C++.

    Known Uses

    Many known uses, but I know not one of these. Refer to book if needed

    Related Patterns

    Flyweight Pattern

Composite pattern

Intent

Using tree structure to represent part-whole hiearchies. Let's clients treat both individual objects and compositions of objects uniformly.

Motivation

The key is an abstract class that can represent both primitives and containers that contain a composition of these containers.

Diagram from textbook

![] (https://velog.velcdn.com/images/lucid_fizz/post/f0fa03c4-6ab3-443d-aca0-9642c77805ed/image.png)

So Graphic is the abstract class. And Line, Rectangle, Text are derived primitive subclasses. Then Picture Class is a container(or aggregate), composed of these primitive classes. Therefore it has child managing feature like Add(), Remove(), GetChild(). Since Picture Class also conforms to Graphic Abstract class, its draw() can tell its child to call draw() recursively. Note that Picture class can also be a child to another Picture class.

A more general diagram from book

Participants

Component - the abstract class Leaf - primitives Composite - aggregate of primitives + child related functionality Client - uses objects in composition, via the component interface.

Consequences

Defines hiearchy where primitive objects can be composed into more complex objects recursively. Client code is simpler. Client code can treat Composite and Leaf as same. No need for tag-and-case-statement-style functions Make it easier to add new components, using the Component abstract class. Can make your design overly general. As downside of making adding new components easier, the abstract class can be too general to enforce constraints. May need to do runtime checks instead of using type system at compile time.

Implementation

Explicit parent reference. Usually in the Component abstract class. Make sure to have the invariant, where parent has reference to child and child has reference to parent. reference should go both ways, like doubly-linked list. Easiest way is to change a component's parent only when it is added or removed from composite.

Sharing components. You can make it so there can only be one parent. But to share component, a child can have more than one parent. But this can lead to ambiguities. Flyweight Pattern shows how to rework a design to avoid having reference to parents altogether, by externalizing some or all of their state.

Maximizing the Component interface. good, but sometimes conflicts with principle of class hiearchy design that says a class should only define operations that are meaningful to its subclasses.

Declaring the child management operations. You can define them in components, or define them in composites. tradeoff vs safety tradeoff. or you could try to do GetComposite() check in component abstract class, that defaults to a null pointer. If it returns a composite object, you can do child management operations. Else, no. Usually it’s better to make Add and Remove fail by default (perhaps by raising an exception) if the component isn’t allowed to have children or if the argument of Remove isn’t a child of the component, respectively.

Should component implement a list of components? No. Only if there are very few children in the structure.

Child ordering. If needed, but design carefully. check Iterator pattern.

Caching to improve performance. Maybe. But when component changes, it needto invalidate cache of parents. I think modern interpreters/processors or sth handles this well already?

Who should delete components? Most languages have garbage collection nowdays. just remove reference to it. no need to free() memory or anything.

What's the best DS for storing components? Depends. check Interpreter pattern for example.

npm ERR! code 1
npm ERR! path /path/to/my/project/node_modules/electron
npm ERR! command failed
npm ERR! command sh -c node install.js
npm ERR! node:internal/process/promises:246
npm ERR!           triggerUncaughtException(err, true /* fromPromise */);
npm ERR!           ^
npm ERR! 
npm ERR! GotError [HTTPError]: Response code 404 (Not Found) for https://github.com/electron/electron/releases/download/v8.1.1/electron-v8.1.1-darwin-arm64.zip

It says darwin-arm64 v8.1.1 electron doesn't exist. Makes sense because m1 mac release was 11/17, 2020 electron v8.1.1 was 3/10, 2020

So how to solve? arch -x86_64 [:args] don't know how arch command works, but this fixed the problem for me note that program started in this manner, and its child process will try to inherit architecture all the same so if i start a zsh session with arch -x86_64, other programs invoked from this shell will also try to mimic architecture

way 1

launch the shell with different architecture, and use node with nvm

nvm install [:temp node version]
nvm use [:temp node version]
nvm uninstall [:target node version] # if installed already
arch -x86_64 zsh  # launch a zsh session with -x86_64 architecture.
arch  # check architecture.  might result in i386 also.
nvm install [:target node version]
nvm use [:target node version] # install and use target npm

way 2

not tested run npm i with designated architecture

arch -x86_64 npm i

reference: https://stackoverflow.com/questions/68896696/having-trouble-installing-npm-on-mac-m1 https://news.ycombinator.com/item?id=25132217#:~:text=Stickiness%20of%20architecture

Notes

Building Your First App

Electron don't support ECMAscript imports. Must use require

there is also option to debug using VScode. Might be useful later on.

Using Preload Scripts

goal :try previliged APIs on renderer, Electron's IPC

Electron's main process runs on node.js w/ full OS access, Electron modules, and npm packages. But renderer shouldn't for security reasons.

two new files, preload.js, renderer.js this will expose a versions obj? or sth to electron rendere

// preload.js
const { contextBridge } = require("electron")

contextBridge.exposeInMainWorld('versions', {
    node: () => process.versions.node,
    chrome: () => process.versions.chrome,
    electron: () => process.versions.electron,
})

and this renderer will modify some HTML elements, using the 'versions' object?'s getters

// renderer.js
const information = document.getElementById('info')
information.innerText = `This app is using Chrome (v${versions.chrome()}), Node.js (v${versions.node()}), and Electron (v${versions.electron()})`

notice the <p> with id="info" and added <script src='renderer.js>

<!DOCTYPE html>
<html>

<head>
    <meta charset="UTF-8" />
    <!-- https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP -->
    <meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self'" />
    <meta http-equiv="X-Content-Security-Policy" content="default-src 'self'; script-src 'self'" />
    <title>Hello from Electron renderer!</title>
</head>

<body>
    <h1>Hello from Electron renderer!</h1>
    <p>👋</p>
    <p id="info"></p>
</body>
<script src="./renderer.js"></script>

</html>

now for the IPC interprocess communication

electron's main and renderer process have its own responsibilities. so, main process can't access the HTML DOM, and rendere can't access nodejs APIs.

but electron has ipcMAin, ipcRenderer modules for the IPC. use this.

for security reasons, don't expose the whole ipcRenderer module via preload script. do it like this. wrap it in contextBridge module.

// preload.js
contextBridge.exposeInMainWorld('versions', {
  // ... skip
  ping: () => ipcRenderer.invoke('ping'),

now write handler in main

// main.js
// setup handler before loading loadFile.
ipcMain.handle('ping', () =>  'pong' )
win.loadFile('index.html')

then use it in renderer

// renderer.js
const func = async () => {
  const response = await window.versions.ping()
  console.log(response) // prints out 'pong'
}

func()

if pong doesn't log, check developer tools of electron app, not terminal. In macOS, you can go thru view menu on top or option+cmd+I

if it logs undefined, make sure arrow function returns sth

//ex
() => {'pong'} // wrong. executes code block on function call, but returns nothing
() => 'pong' // good. returns string

Adding Features

tutorial says some things, then says refer to its examples

This is my notes on https://www.electronjs.org/docs/latest/tutorial/process-model, and not a complete summary

why is election multi-process? web browsers like chrome are multi-process. Each tab, ui, plugin is a process. Explained very well in this Chrome Comic I liked.

So an electron app has a single main process that runs in node.js. This is the entrypoint, and can require and use all of node.js APIs. so it can read, write stuff anywhere. high level permission

This main process creates an app window using BrowserWindowmodule. like,

// main.js
const { BrowserWindow } = require('electron')

const win = new BrowserWindow({ width: 800, height: 1500 })
win.loadURL('https://github.com')

const contents = win.webContents
console.log(contents)

This provides apps with a renderer, kind of like Chromium wrapper.

• Also, for security reasons explained well in the Chrome Comic, these renderers have very little privilege. It cannot use node.js APIs to control the native machine or other renderes, or require other modules. To use npm modules in rederer, you need to use same bundler toolchains like webpack or parcel to build the binary in beforehand.

Or you can use preload scripts, which are run in a global Window interface. This can access node.js APIs.

or use utility process using UtilityProcess api, which can use use node.js and npm modules

moreover, electron has Native APIs to control native desktop functionality like menus, dialogs, tray icns.