DEV Community: Herbert Breunung

What is an object?

Herbert Breunung — Fri, 28 Feb 2025 18:22:43 +0000

This most bland sounding question is one important gate into proper software engineering. Answering it right unlocks a view that avoids bloat and enables understandable code - on a micro and macro level.

We all know what objects are, right? They are the things we create from a class with attributes and methods. They are like cars, all built the same way in the factory, but now have different drivers (owners), who put different stuff (data) in the trunk and do different tasks. And in order to create a better car, we take (inherit) the blueprint (class) and latch on some new functionality or change (overwrite) functionality (methods). The ladder is also called polymorphism, because the new car can replace its ancestor, but has a different form. The sad part of this rant - most students, professors and even working professionals would subscribe to that - although it's beside the point.

You can get objects without classes, which is called prototype based OO and very popular e.g. with Javascript. You can also go without inheritance and employ reuse by composition, where attributes are instances of the class you wanted to inherit from. And as a corollary, you certainly can do without polymorphism. So what is left? - Encapsulation and abstraction! And I would even replace the word abstraction with simplification, because that is less confusing. Even if both concepts go hand in hand - let's start with :

Encapsulation

A capsule is a shell, a package, which hides its content, protecting it from damage. In our case that means protected from user access. But every package and every function, in my language of choice even every block can have private variables. Why do we need objects? - For convenience! In fact, one could put all the functionality of a class into one closure (function with permanent private variables). And instead of calling methods from an object reference, one could call this closure with our object ID and other needed arguments. The computer wouldn't mind. The result would be the same. But the code would look convoluted. Instead of calling do_everything( pink_taxi, 'drive_to', 'munich'); it is natural for humans to read pink_taxi.drive_to('munich');. Even more importantly, the inside of the class is way better understandable if all functionality is packaged and sorted into neat little methods than if all is crammed into on function. So is it just about a bunch of functions sharing state (data)?

Simplification

YES! - even if that upsets some academics who like to carry around big words like polymorphism and abstraction. They sound like Plato, dealing with otherworldly ideas, from which everything is made. In reality, software works more like nature. One cell or organism produces another one, which produces another one. The only abstract ideas might be in the head of the programmer. In the previous paragraph I called the purpose of an object simplification. Because this is the side effect of a correct usage of encapsulation. The methods (functions), which are visible from outside the capsule, are called interface - or even shorter: API. They provide access to the functionality of the inner part of the class, but hide details. They should hide everything that burdens the user's mind and does not add meaningful degrees of freedom in his decision making. Crafting an API is an art form which includes using the right words, knowing what to leave as option and so forth (more on that here). But in the end it's all about lowering the mental strain. I prefer to focus on this most important goal by calling it simplification, not abstraction. What good are 10 most smart abstraction levels, if they just add confusion?
Making complexity manageable is the main purpose of objects. And please note that detail hiding and the encapsulation are consequences from the same enclosure.

The tools of OO are just two old ideas:
1. Variables and functions hide together in a namespace
2. Instantiation (like you do with any variable)

No wonder Bjarne Stroustrup calls objects in the classic "Annotated C++ Reference Manual" custom data types. Alan Kay, who coined the term object orientation and was co-inventor of Smalltalk, the second OO language, said in talks that the core concepts are encapsulation, abstraction and message passing. With message passing he just meant calling methods with arguments. Reading him also brought me to my senses regarding this matter.

One might argue that the very first OO language: Simula had multiple inheritance and Alan left it out just for personal taste. Well the vision of Simula was to unify software design and programming which is a great idea and unfortunately today unpopular. But it was after all an academic experiment and originally lacked even encapsulation.

Welcome Cellgraph

Herbert Breunung — Fri, 21 Feb 2025 17:23:03 +0000

I wrote a free app that draws tiled pictures with cellular automaton. They are a bit like the autogenerated avatar pictures on github. The picture above is for instance created by it. However, you can make them much more personalized, more beautiful and certainly more complex - once you understand the many parameters (knobs and buttons in the app). To help you with it I wrote this text. So let's start with the basic question: what are cellular automata?

Each tile is one cell. And that tile has a color, representing its state which is little more than just an one digit number. The cells are lined up in a row and you can define their starting state by hand, by clicking on them in the second tab (Starting Row), since every start configuration can produce a very different pattern.

The actual picture will be computed step by step by a rule - which you can also choose, since every rule draws the picture with a different pattern. The rule operates like a gigantic if statement. It just checks: what is the state of a cell and what is the state of its neighbors. For every combination of states in this neighborhood there is a fixed result, which will be the new state (color) of the cell. This way you get a new row of colored tiles. This process will be repeated until we get a square shaped picture.

This was a very simplified, since I expanded the original concept greatly. The (last) colors tab alone has predefined color sets a huge color store, color functions to compute gradiants and complementary colors. Furthermore can each color changed on the RGB or HSL axis with their own randomizer buttons. And this was just one of 5 tabs of setting. If you want to know every detail, please read the manual.

There are also activity rules that can hinder cell state changes for more broken patterns and also buttons that get you related rules. But the maybe most interesting and fruitful features are the following three:

Paint Direction: Default is top down as described. But you can also let it draw from outside in (on all four sides) or inside out (also), which makes your image automatically mirror symmetric, twice.
Rule Mapping: If the cell neighborhood has the size of 5 (2 neighbors on each side) and you selected 7 states they can build 7**5 (seven to the power of 5) = 16_807 different patterns. You will not manually choose the result of 16_807 sub-rules. But on other side having more states (colors) will make you drawings more interesting. So be cautious at first and select the strongest rule mapping called summing. Now you have only 35 distinct sub-rules (2 pages full). Then hit the random button to get a starting point and change only those sub-rules that are bottlenecks (the have the largest counter values - they are applied most often).
Result Application: If you're new, you might lack the logical intuition where the bottle necks are. Then you got drawing where nothing happens - even if you change some sub-rules. In that case you could choose not just insert the result of a sub-rule as the new cell state. You could also add or multiply them. If you stuck should take an operation that contains a rot or rotation in the names. Then there will be always added an additional value of one. This will make sure that the cell state changes from computation round to next and you will get interesting pictures fast.

If you want to know more , please look here and there and if you liked the program and have improvement suggestions please let me know. Thanks

Recents

Herbert Breunung — Sun, 09 Feb 2025 14:24:09 +0000

Recently changed articles:

New

What is an object? (28.Feb.2025)
Welcome Cellgraph (21.Feb.2025)
A tale of four gangster (9.Feb.2025)

Changed

What is an object? (3.,26.March.2025)
Brain Memory Management (1.March 2025)
System Thinking (9.Feb.2025)

A tale about four gangsters

Herbert Breunung — Sun, 09 Feb 2025 10:14:20 +0000

In the programming sphere "Design Pattern" by Gamma, Helm, Johnson and Vlissides is a true classic. The book from 1995 set a standard, shaped the language we use in the software engineering domain and is used in innumerable university courses. This article is my attempt to critique it on multiple levels while avoiding to sound like a know it all prick. Not an easy task, since the criticism will be harsh.

But to start with the good: the main idea is very powerful and uplifting. Yes, there are reoccurring patterns in class structures that aim to solve reoccurring challenges. And it is helpful to identify, name and analyze them in order to express concisely how our program is constructed and to know something beforehand about the up- and downsides of our design choices. Being a massive proponent of that made me write these lines.

However, as stated in the foreword and chapter 6.3 of the conclusion part, this great idea came from Christopher Alexander, an architect of buildings. He was mainly interested in architecture that supports human flourishing - something not mentioned in chapter 6.3. In order to serve the inhabitants, he expected also that design patterns were mixed and adapted freely. A stark contrast to the cooky cutter approach of our four suspects.

Their primary goal, as stated in the introduction, was to simplify the design and reuse of object oriented (OO) software. OO programming was just entering the main stream and our gang tried to facilitate that by using The main stream language for OO at the time (C++) in their examples. They did apply all the powerful OO features C++ had to offer, while ignoring the much simpler reuse by composition or argument (post about that is incoming). In short - they chose inheritance as their hammer and every problem became a nail. And as a result, some solutions are unnecessary complicated. Another big chunk of bloat could be removed by using OO features popularized after the book was published. Although, that doesn't stop people to teach the original pattern even today. And this might be the biggest mistake - to perceive these patterns as sacrosanct. The gang members spread this attitude by teaching to replicate the pattern in our own code over and over. But the natural and sane tendency of programmers is to remove boiler plate and to ensure that staples of daily life become part of the core language or at least the standard library, so that they can be accessed through an expressive syntax and with the least amount of typing. (I got that insight from Mark Jason Dominus.) These patterns should show up in the way a program functions, but not necessarily in its written form.

In summary: I miss the intellectual rigour in this book. Some patterns mix several ideas, some are repeating previous ideas and some are not pattern at all, but mere examples tied to unnecessary specifics. This confusion can only result in overcomplicated class structures that drain life force out of the programmer who mentally lives in them. That form of gangsterism is the opposite of what Christopher Alexander longed for.

Article Index

Herbert Breunung — Fri, 31 Jan 2025 10:22:29 +0000

All articles, grouped by topic. They are also interlinked and like wiki pages. Sometimes they get enhanced or rewritten (see in Recents).

Software Engineering

System Thinking
A tale of four gangster

Programming

Brain Memory Management
Good File Structure
What is an object?

My Projects

Welcome Cellgraph

Good File Structure

Herbert Breunung — Sat, 28 Dec 2024 20:42:42 +0000

My last post ended on the note, that code files need a dependable structure. Work becomes more productive and enjoyable if you know where is what, without having to read characters - just from scanning the contours. And you don't even have to memorize the order of sections, as long as the file structure adheres to one overarching rule: FROM THE GENERAL TO THE DETAIL. This rule is intuitive and helps you understand the code in one read. Let me explain.

Even Japanese or Jews start to read a code file in the upper left corner. At that point they may or may not have some knowledge of the content. So it is better to get a broad picture of the content while starting to read. Later smaller and smaller details will be added as needed - FROM THE GENERAL TO THE DETAIL.

The most general parts of a code file are the meta information are the most, like author, date and license. In my opinion the license is way too much text to be included in a code file. Just insert a reference to the file or put the file in an expected place, like the projects root directory, which is also legally binding. And keep the other meta info including its formatting to a minimum, since its rarely of interest. But put it on top or bottom so its easy to skip.

Often you see one or more lines in the meta header, that summarize the content or purpose of the file. The ladder is much more important and should stand just above the name of the namespace / package / object, so they both build a unit that sets up your orientation and expectation. This part is crucial and worth spending time on. It helps the author to sharpen his understanding of what is to be achieved here, which can dramatically improve code clarity and thus quality. It also ensures that the namespace / package / object name is the explicit and concise summary of the summary. Finding such names is a good part of professional programming and this arrangement supports you in that. Because if feel some meaning is missing in the name, you have to add it in the summary. Just don't stop there, but think hard about what aspects of the summary can be deleted by choosing a better name. After you changed the name and shortened the summary, you may want to insert other information into the summary which were left out in order not to bloat. Then the cycle starts again until its good enough.
This technique can also be applied to any other identifier like variables and method names.

The next, less general information is the version number of this namespace and the used programming language. Subsequent are pragmas (optional language features) and library load commands. First the ones from the language core, then third party libs, then the internal ones. Global constants, enums and variables follow. If there are more than a few items, group them for better oversight. Now we have left only the routines, functions or methods. Visual separators are helpful to distinguish between the just described head section and the various types of methods. The following paragraphs will be just about methods, because if you only have functions, you can group them by topic without thinking too much about it. But you should also apply some of the principles that are best taught in an object oriented context.

It is logical to start with the constructor. Not only because it's the first method you will use and probably the first a reader will seek. The constructor will tell you also about many of the arguments used in any method and more importantly about the internal data structure of the class. With that knowledge any subsequent method becomes far easier to grok. And - while we're on the topic of the life cycle of an object - the destructor method and even serialisation (if present) should be part of this section too. If only because the code that employs the same special knowledge should be pooled together to minimize searches and make code more self documenting.

The only other methods that reach into parts of the internal data structure should be the getter- and setter- methods - also known as accessors. These are the content of the second block of methods. They are usually very small and give you a good and fast outline over the internal and external interface (API) and its data flow.

Next are the methods that contain the most lines of code - let's call them workhorse methods. They should be few and well commented.

The fourth section contains helper functions and methods, that are so specific to this class, that they should not be abstracted into an own namespace. Some might protest and call this bad practice and violation of the stated goal: being able to understand the class in one reading.
They want to know the content of a method before it is called, to have a thorough understanding of what is happening. While I sympathize with this stance, I think it contains misunderstandings. First off, most constructors call others methods - so it is not a rule we can comply with while holding to the proposed order. Secondly, an implication of our stated main rule is the sub rule: from the public API on inward. This alone places the auxiliary methods last. But the best defense recalls the purpose of a method. It is a piece of abstraction. If you need to see the internals, you have created a flawed abstraction. Either the function name does not tell you what is going on, or the method is too big (complex) or even worse: it has side effects.

Sure sticking to all this takes discipline at first (read: pain). But it pays off in the long run. Your code gets easier to read, maintain and extend (all what was promised by using OO). Even writing new classes becomes easier, since you no longer think about a lot of details. You are free to concentrate on the irreducible problems that your class solves. So have fun and fine tune the rules to your sensibilities and needs - but be consistent.

Brain Memory Management

Herbert Breunung — Wed, 13 Dec 2023 19:40:48 +0000

In my first post I cheered for system thinking and understanding even the mind as a system. That can be driven to any amount of complexity, but today lets just look on two very important components: the rational and intuitive mind.

To be a good programmer you need both. Without an rational mind of course you can not construct an correct algorithm. This is the basis of any practical detail work.

But it's often overlooked that programmers using the intuitive mind as well - actually all the time. Whenever you switch context from lib to lib or even between routines (called sub in Perl), you metaphorically fold all detail knowledge you had about the previous piece of code into a general, felt notion and unzip another set of facts you know, just read or make up about the current sub. It can't be any other way, because experiments have shown, there is a single digit limit of hard facts, your rational mind can hold. In some cases it can reach 20, 25 at max.

That's why it matters to structure code in a way that: 1. you never deal with too much informations at once and 2. you prepare the reader for what is coming (the context switch) with some distinct command, identifier (name) or comment. This is what makes code intuitive. In other words: it is always a good to lower the cognitive load of code - But how we do that?

Most important are understandable abstractions, that guide thinking and usage. But this topic is a way too big for this little text and will get its own post later. Next in importance are identifiers - the names we give subs, variables, classes, packages ... Yes we heard they have to be clear, fitting, concise and if possible unique - so they lower the need for (visiting) comments and docs. But to help cognitive transitions they should also fit their surroundings. For instance an attribute named "mover" of a class named "car" should be renamed to for instance "wheel". That fits the context set by the class name, is more specific and sparks a stronger mental image.

Identifiers should invoke emotions, because that makes them memorable. Or in more neurological terms - you can connect the invoked emotions to other impressions to create an intuitive map of the code.

And you can reduce the cognitive friction even more by making terms consistent. Even smaller projects should have a little glossary file where used words are defined. And whenever this specific thing is referred too, no matter if in a variable, method or class name, it will be done only by this word. And if something is similar but not that specific thing - try hard to use another word. Especially when a method name uses 2 or 3 of these specified words - its name will work like documentation in most cases. This is why I like to start projects with writing documentation. Not only because fishing for ideas while coding is the cause of much suffering, but also because you have time to coin and define the most important terms before you start to use them.

Changing them later is tedious because its harder than just refactoring, since you have to go over many types of identifiers in many files. Normal refactoring tools would help you only partially with that, since their focus is much narrower. They rename only one variable or method name at a time. And only in one scope. You also want to have the same variable name for the same thing in different methods. Especially for arguments - which makes the API much simpler without even touching the logic.

All these practices are mentally too demanding to be done while coding. You really can only do on thing right at a time. And because you try to avoid tedious refactoring they should be done in front. On the other hand you need in most cases at least some class structure to come up with some fitting names. This is why I like to set up during the early planning stage of a project some empty dummy classes and add only certain methods, variables or comments that are essential for understanding what should go where. If you develop it in parallel with the rough outline of the user documentation and make sure you use the same words for the same things and actions in both - that also massively reduces cognitive friction. It makes the documentation more helpful and code way better understandable.

Another technique for finding good names is commenting. Quite often I just used the first best variable name and commented what i actually meant by it. Again - I was busy to figure the algorithm. Later, when glancing at the class as a whole the right name just popped out and it was just one of the words I wrote down in the comment. Having that comment, made it actually easier to find it.

If a variable has no special meaning like a counter, then "i" or "cc" is acceptable and contrasts nicely with meaningful variables with actual words in the name.

Organizing subs into parts (blocks) also helps greatly to quick scan and understand. The whole file structure should be communicating meaning, but that's also a topic for another day.

System Thinking

Herbert Breunung — Fri, 08 Dec 2023 11:28:05 +0000

Most of us here know how good software looks like. It has a functioning distribution package, docs in order, meaningful abstractions, manageable user interface comments when needed and so forth. Naturally, if you want to uphold such a nice state you have to think a lot before doing anything, then going three steps backward and make a lot of other changes just to enable the changes you want to make and maybe even fixing stuff you discovered on the way.

Yes real programming can be tedious if not broken down in small enough tasks (release often). And there is lots written about it, that loosely fits into the category of software engineering. But instead of memorizing lots of rules, I find it far more helpful to adopt system thinking.

Programmer already (should) do that when writing tests. Then we step outside our role of an app/lib dev and try to think about all the ways the software could be broken. In similar fashion we can read our docs like someone who tries to get basic help. Yes that's not easy and also a bit silly task - just to pretend what we don't know what we know. But it is an acquired skill to blend out certain knowledge and having fun to play ignorant. In the end its way more effective than organize someone who is really an outsider and communicate with him - especially with the first 70-80% of the issues. Once you have quality docs with some issues, the game is different. Then it can be helpful to have another set of eyes, that bring up issues which have to be fixed by the author anyway.

And if we understand software building as a system of interaction between the manager, developer, user and other people, we can access if things are good simply by taking the perspective of a role - after all these are humans too.

We should see - the most important system in that of the human awareness. Things like attention span, direction of focus, amount of data that fits into the rational mind or the intuitive mind (magnitudes more) and so forth are to seldom considered and taught. But if you know a bit about it (and my next posts will talk more about it) it will be less hard to simulate other perspectives. It will also help you to stick to processes, that have your own human limits as a developer in mind. This is the core of my cellular programing method, than i want to develope also in following posts.