Programming Computers

Data Types: Atomic and Compound

Data types are the types of data that can be stored in a variable.

Some datatypes are numeric, very much as in mathematics.

• integers: both natural and whole numbers
• floats: decimals, scientific notation, fractions...
• complex: as in mathematics, they have a real and an imaginary part

Most computer languages also have a string or text data type. A string is often enclosed in double quotes, as in "Meet me at eleven." (save in standard SQL, which uses single quotes: 'MY_STRING')

Most computer languages have a Boolean data type too, which can only take on two values: true and false.

Some, but certainly not all, computer languages have a null value to signify that a variable has not been initialized. This is regarded as a high-level feature.

Finally, some computer languages have pointers, that is variables that hold the address of an actual variable. For instance, int * pInt0; declares variable pInt0 to be a pointer to (the address of) an integer variable. This is considered a low-level feature.

Weakly- and Strongly-Typed Languages*

Processing

Processing is a free graphics library and integrated development environment (IDE) built for the electronic arts, new media art, and visual design communities with the purpose of teaching non-programmers the fundamentals of computer programming in a visual context.

Processing uses the Java programming language, with additional simplifications such as additional classes and aliased mathematical functions and operations. It also provides a graphical user interface for simplifying the compilation and execution stage.

Latest release: november of 2024. Official site: https://processing.org/

Information Expert

This principle recommends that if you have an operation to do, and this operations needs inputs, then you should consider putting the responsibility of carrying out this operation in the class that contains the inputs for it.

This helps keeping the data local, because if you put the operation somewhere else then the inputs will have to be carried over there, creating a relationship between the class that holds the input data (the information expert) and that new place. This would create coupling and be detrimental for encapsulation, thus creating complexity.

Granted, it’s a natural thing to do. But formalizing this as a principle still has several benefits. For example, if you feel that a design is not quite right, thinking about the information expert principle can help you pinpoint what was disturbing you in it. Also, it helps expressing your remarks in a code review.

Creator

The Creator Principle gives guidelines as to which class B should be in charge of creating a certain type of objects A. The principle contains a set of conditions to be fulfilled, such as:

• B contains or aggregates instances of A
• B closely uses A
• B has the inputs to construct A
• (and so on)

The more rules are fulfilled, the better B is suited to instantiate objects of type A.

This goes a little further than Information Expert: it’s not just about having the input of the operation of construction, it’s about being close to the operation.

If you put together two parts of the code that are semantically close (the construction of A, and the code that works a lot with A), then they become easier to reason about than if they were far apart.

Low Coupling

Coupling happens between two parts of the code when one depends on the other. Coupling introduces complexity, if only because the code can then no longer be understood isolation.

Such dependencies can be explicit, in terms of a function call for example, and that’s unavoidable and often OK.

But other types of coupling are less sane and less visible, for example when a part of the code expects that another part has set a data member to a certain value.

The design principle of low coupling encourages to keep coupling low, and it can help in particular to choose between two designs: select the one that introduces the lower amount of coupling.

For more details about the various types of coupling and the various types of problems that coupling generates, refer to this dedicated article on coupling.

Protected Variations

The principle of Protected variations is related to the one of Low Coupling, because it helps to reduce the impacts of the changes of the code of one part A on another part B. The code of part B is protected against the variations of the code of part A, hence the name of the pattern.

How do you achieve such a protection? By organizing the responsibilities around stable interfaces.

This is particularly relevant for code that tends to change often. Introducing an interface between this unstable part of the code and the rest of the codebase helps limiting the rippling effects of those frequent changes.

The principle of protected variations is, according to my understanding, very close to the concept of anti-corruption layer from Domain Driven Design.

Indirection

The Indirection pattern is another way to reduce coupling by creating an intermediary class (or any kind of component) between two classes A and B. This way, the changes in each one of A and B don’t affect the other one. The intermediary class absorbs the impact by adapting its code rather than A or B (or more other classes).

This relates a lot to the Adapter Design Pattern, even though the Adapter design pattern is rather made to connect two existing incompatible interfaces. But it also has the effect of protecting each one against the changes of the other.

Indirection looks a bit like Protected variations, as they both introduce a layer between components in order to reduce coupling.

To my mind, the difference between Protected Variations and Indirection is that Protected Variations is about designing interfaces in the existing components, whereas Indirection is about introducing a new component in the middle.

Polymorphism

The Polymorphism principle is an exhortation to use… polymorphism in your code.

Polymorphism is often seen as having a base class with virtual methods that defines an interface, and derived classes implementing this interface, but this is only one type of polymorphism. There are plenty of types of polymorphism (including templates for example) and I hope we’ll get to dive into this topic at some point on Fluent C++.

The usage for polymorsphism is when there are several ways to accomplish a task, and you want to decouple the clients of this task from the various pieces of code that implement the various ways to perform it.

The Polymorphism principle is very close to the GoF Strategy Pattern, if not identical. It contributes to the Low Coupling principle.

High Cohesion

The principle of High cohesion encourages to focus classes around one responsibility, and to have all its components oriented towards achieving this responsibility. This is the principle of do one thing and do it well.

The principle of high cohesion also applies to other elements of the code, such as functions, and also modules and systems.

This ties back well with the idea of having a well-organized code: a highly cohesive component lets you label it in your mind with this is the part of the code that does X. This allows better mental abstractions as well as code abstractions.

Pure Fabrication

It is natural to represent in our code objects that map the reality of the domain that we’re trying to model. For example, if you’re working on a financial application, you can probably expect to encounter some classes called Transaction or Portfolio in the code.

But sometimes you have a responsibility to assign, and it seems to not fit well in any domain class. And according to the principle of High Cohesion above, you shouldn’t force a responsibility into a class that is already doing something else.

That’s when the principle of Pure Fabrication comes into play: create a class that does not map to a domain object, and let it achieve this new responsibility in a cohesive way.

This principle is probably one of the hardest to understand, because it goes against our natural tendency to write code that represents the problem we’re trying to solve.

Controller

Here is an example of a pure fabrication: a UI Controller. This is such a common pattern that it was included in the 9 GRASP principles. Personal opinion: I would have kept this as an example of pure fabrication and not made a principle out of it.

The controller is the first non-UI component that receives the UI event and organizes the operations to react to this event. Indeed, that doesn’t map to any domain object, even if the UI itself can display domain concepts.

There are also other examples of pure fabrications in the GoF design patterns: for example, a Facade object is a pure fabrication.