I have just learned a lesson is object oriented programing (OOP). Not read a textbook chapter on that, no - I have known the concept before. But I have just realized something myself while trying to solve a problem and the fact that I have realized it myself should make that lesson all the more valuable.

C++ fully supports OOP and therefore not using it is usually a mistake and complication of one's task. In OOP the idea is to make the code a virtual representation of the reality as close as possible in order to simplify the code. The main tool of OOP are classes - sets of variables and functions that represent a single object. For example, a car class would have variables such as size, current speed, brand, etc. and methods (class' functions) such as accelerate and break. Code represented in this way is set up much more the way we think than a procedural code and therefore easier to write and edit.

I was planning to have a single class in my game - the piece. It would have a color and the position, an indicator that would say weather it was a king piece and an indicator of weather it was still in game or not. I was not planning to make a class of a player, simply because I was not going to implement a lot of player specific options. The other possible class would be the board. The reason why I did not want it was the fact that then the information would double - the board would know what piece is where and the pieces would know where they are standing. Therefore if a piece was moving I would have to change the piece's variables as well as the boards. However when I was planing out my algorithms I realized it would be very useful to be able to refer to the field instead of search through the pieces to find the one that has the specific coordinates.

I also did not want to have the pieces be variables of the fields' (which is, however perfectly possible) because

a) it was not a good representation of reality - a piece is NOT a part of the field and

b) it would mean that every time piece is moved, it would have to be destroyed at one field and re-created at the other.

I thought about how to solve it for quite a while and then I realized the perfect solution - it was even than my initial plans.  I realized that it is in fact NOT the piece's duty to know its coordinates - it only stands on a field. So the field will be the only class storing the position. So I needed a way of letting the piece "know" where it is and the field to "know" what's on it. I remembered the perfect way to do this - through pointers. Pointers are a basic type of variables, which, instead of a number, stores the address of a different variable. It is in fact much easier than it sounds and all it means is that I can have every field have a "link" through a pointer to the piece which is standing on it. It is in fact the most exact representation of the reality - the physical contact takes the form of a pointer. That last sentence is much more important than it might seem - it points to the moral of the whole problem. OOP is not just a fancy way of manipulating the information - it is in fact a great facilitation and the more accurately it is used the more helpful it is.


PS sorry for the bore but it is a really important point for my reflection - this is the kind of learning experience which I can't get without making and is so valuable. :)