It does not happen very often, but it does occasionally; the lack of words to describe how happy this person is, that yet another chapter is history.
The experience was a mix between utmost interest in the contents of the main chapter, the Challenges were a different story. Not knowing why, but there was a feeling of disconnectedness with many of the early Challenges. There was also lots of repetition. One instance is the Number Class, which is a variation of the Programming Challenge 10.19 - Check Writer program. Another is the Date Class, which had to be modified in this chapter. With Challenge 14.4 and 5 and 6, interest grew, as it allowed me to implement some personal touch to these programs. If you don't know, the names are taken from Alexander McCall Smith's "Mma. Ramotswe" books. Please read them, if you find time! This is something I like doing, as my recurring readers and visitors should already have noticed.
All these were not very challenging, as most of the work was done in previous chapters, which does not mean that all the published solutions are mere copies. No, in most cases it was an opportunity to improve what has been done before. It reflects a growth in knowledge and gives a sense of accomplishement when the new code is indeed better than the old one.
There was little problem to solve any problem, up to the (Un)challenge 14.9
Feet Inches Modification. This was so unchallenging, that it was done
in less than 15 minutes! While in previous chapters this kind of problem would be giving a welcoming breather, it seems that it was not necessary at this chapter, and if it were, than it could have been something more interesting, or a little more challenging at least.
At a later point, Challenge 11 in particular, this one was really difficult to solve. The task was to write a FeetInches class modification, containing a copy constructor, which allows for the multiplication of two FeetInches objects. The problem was not so much how to write code, but what should the output be? Based on this decision, the formula had to change. As the feet and inches are foreign, I had little knowledge about the expected output. It has taken quite some time to find an online calculator website that offered the functionality of multiplying feet and inches, outputting a result in a way to confirm that my code delivers correct results. This is most important, correct results.
Truly interesting was the work on the Parking Ticket Simulator and Car Instrument Simulator programs. Both of which I was looking forward to, and indeed, they were rather easy to solve. 14.14 which is the Parking Ticket Simulator was rather difficult in some aspects. Here the problem was more of the nature of how to make the classes interact and do their magic behind the scenes. Most troublesome was to find a way to resolve the dreaded 'circular dependency' issue between the PoliceOfficer and ParkingMeter class. The other was the question how to write the code so, that the classes are not tightly linked to each other. (Or is the correct term coupled?) That was the nature of the problems to face when solving this problem.
On the whole, this chapter was not too difficult. There was even one solution that felt most complete. That for the Date Class Modification which was Challenge 14.8. It is difficult to express the meaning of 'most complete', the closest is that it feels like one whole, in which every part has its place and everything interacts without any one part - or function, having too much weight or content. It is not perfect, but it is the only good solution for any of the previous two chapters.
Code never feels perfect, in almost no case is this person able to say, it is good enough. Yet, this way of thinking is wrong. While researching the FeetInches problem, I found an article on Nature.com which is all about code sharing. It describes the feeling related to my own code solutions. The important thing to take away is this: "If code is good enough to to do the job, it is good enough to release ..." Of course there are differences, I would release my code anyway in the hopes that it helps someone out there in the world overcome a problem.
This is a challenge in itself - to overcome the way of thinking that everything has to be perfect, else it has little worth. The other, and I noticed this, is: "Why is this code still so long? It could be much shorter, if only I knew how ...", it is a way of thought that has resurfaced. Maybe it is something that was planted into the mind in the early stages of learning. Without the knowledge about loops, etc., code for a solution was rather long. In particular the Travel Expense program comes to mind. With the introduction of arrays and loops, it may have felt as if code has become shorter, while in fact it had not. Over time the expectation has grown that, with each new tool or part of what C++ has to offer, solutions would become shorter, less code has to be written to accomplish a task.
With time, and more experience, it still will remain an illusion, for now the important thing is what comes next. Chapter 15, the closing chapter about classes, will certainly be most interesting. My hope is, that, once this next chapter will become history, that things become much easier and it is all downhill from that point onward.
This marks the end of this chapter summary, and after a good days rest tomorrow a new chapter will begin. And with this, I wish my readers and visitors that they are able to solve - or overcome all of their challenges whatever they may be. Soon there will be more code, until then, stay well!
