The best way to approach reviewing the implementation details provided by another programmer is to focus first on the physical layout of the files. Phish divides its files into different categories of class.
The classes are organized both functionally and also by whether or not they are platform-specific. Functionally, there are four principal sets of classes:
The term business object does not strictly apply here as this isn't quite a business application. Nonetheless, the broader interpretation of business objects as those objects which encapsulate the rules and protocols of the application does fit nicely. Note that most developers don't use the term business class but rather business object. I think the strongest reason for this is that business class sounds like an airline reservation.
One of the design goals of Phish was to make it platform independent. While we decided that the first iteration would run on 32-bit Windows, we wanted to ensure that porting it to other platforms, including Unix and the Web, would be a fairly straightforward exercise.
Our first design decision was that we would assume we had access to a bit-mapped display and that the operating system would provide some form of image abstraction. Other than that, we were not willing to assume any other services from the OS or from whatever application framework we might use.
We've adopted the following naming conventions in the code:
P
if they are Phish specific and with C
if they are MFC specific. Thus, all classes beginning with C
will be replaced when we port the application to another application framework. RC
T
d
, except collections, which begin with c
, and pointers, which begin with p