Hovden Data Laboratory

In 1985, on a practice week in  some company downtown Bergen, I was lucky to get a course in Text editing software on Wang Computers.  Extensive use of function keys.  Very advanced functions, word-splitting, etc.  No font to select, very easy that way. In 1991, while visiting ABB in Heidelberg, Germany, as a student on a job acquired through IAESTE, I met my first text file format, the NROFF unix manual typesetting language. In 1992, I tried gopher hyperlink navigation. In 1993, the World Wide Web started for me, authoring web pages.  Setting up a web server. In 1997, while starting work on master thesis, I learned LaTeX.  \bold{text}.  Very powerful.  Even math equations.  Difficult with images.  Much more powerful than MS-Word.  Many templates available, for different end-results.  Each journal had their own format standards. Sometime 2000, a colleague looked into DocBook.  Also 2000s, I used Trac wiki and its syntax. S...

Some years back I wrote a conceptual small class. This class is central to our processing of data and have over the years been extended where needed to fit many different coding projects (20+). Looking at this class and reflecting about possible improvements to be done, it is clear that having different methods that returns certain information X in different output formats can be improved by encapsulating this common behaviour in a new class. In other words, move all those methods into a class representing X and make a method in original class to return X. For instance, you got a Subscription class representing a from date and a to date, among other stuff. You can improve by making a Period class that contains a number of formatting methods, instead of putting these formatting methods in the Subscription class. I think it is an antipattern to write field formatting methods. If you need to format anything, it should be the class representation itself, not parts of it.