Re: debunking the myth that Greg doesn't like classes :)

Nice subject line :-) This discussion started around the question of whether using classes to represent types is good practice or not. This kind of design is pretty much reminiscent of Smalltalk (where I learnt OO design) and most PHP developers associate it with Java. As someone pointed out during the large threads, Java-like design is very prone to receiving flak from PHP developers. PHP5 is now a full fledged OO language, and allows this type of software design. As we all now, gradually, start to use PHP5, this is the ideal time for discussing these matters. My position might not have become very clear all along, but I think I can summarize it enough: OO design, when taken full length, is likely to produce large numbers of classes. I don't think this is inherently bad. It is just a form of dealing with complexity. On the other hand, most PHP developers do think it is poor design (for historical reasons). I opted for pointing out that I have never encountered a situation where poor performance was caused solely by a large number of classes. I called this the myth of require_once performance penalty. In presenting my myth debunking, I put you the devil's advocate seat. I have this opinion of your designs partly because of the XML_RPC2 discussion, partly because of the (older) PEAR base code I had to read here and there. The PEAR core code shows signs of trying to reduce class count, by joining different behaviours. This probably has historical reasons for being so. I'm not criticizing. In this text, you curiously show an opinion quite similar to mine, even if coming from the other end of the spectrum. The Games_Chess case just proves my point. The first design was poor. It was not poor because it had a large number of classes. It was poor, from what I understand, because it did not fit with PHP's API, forcing you to reimplement basic operations. Most bad designs I've seen produce lots of classes. The reverse assumption is not valid, however. This is a very important point. One can't evaluate the quality of a design by class count. Very good designs sometimes have large numbers of classes. My conclusion is very simple: A bad design will show its shortcomings easily. There is no need to try and evaluate its quality by class count. There are other criteria. Performance is one, exposed complexity is another, as is ease of extensibility and many others. Cheers, -- Sérgio Carvalho Greg Beaver wrote: > Hi all, > > Just for the record, I am not against using tons of classes. The > refactoring I have been doing in PEAR is exactly that: split behemoth > things up into more classes. This is in addition to work done adding > features of course. > > What I have not done is add a class for every single data element. Some > data is better represented by native PHP types in PHP. I have learned > this the hard way through MANY years of programming. > > Case in point: the original version of Games_Chess had a class for each > square on the chessboard, and classes for each piece on the board, as > well as a blank space. After it turned out that I had designed some > limitations into the rules for the game in the design of the pieces, I > began refactoring the classes. Shortly thereafter, it became apparent > that several thousand lines were devoted to working around the > complexity that came from what was essentially trying to do matrix > algebra with classes and delegation as well as cross-referencing classes > (square class with piece class). In addition, I couldn't get it to > work, and looking at the code couldn't even understand where to begin > debugging. > > So, I erased every file and started from scratch. What I had missed the > first time around was that each piece/square was not an object even > though they appeared to be because they are in real life. The only true > object was the chessboard itself. The squares were simply containers > for pieces, and could be more easily represented using an array. Each > piece only possessed 2 qualities: name and color. In addition, pieces > can change identity (pawns can become queens/rooks/knights/bishops). > Once I recognized that pieces were simply data, it became a simple task > to implement the chess engine. All I needed was some basic move > calculation methods and a few backend classes to implement the rules of > interaction between the pieces for different flavors of chess and I was > rolling. > > Not only does the class work better, but I saved on the most important > benchmark of all: developer time. The more unnecessarily complex a > solution is, the harder it is to debug or add features. > > I don't claim to be immune from adding too much complexity in my own > code. There are more than a few developers here who can attest to that. > I have had my fair share of ideas I have fought for that later turned > out to be overly complex. My problem has never been oversimplifying. > > As for XML_RPC2, I am sure my dogmatism and Sergio's dogmatism could > work together for a better class than either one of us would implement > on our own. I've been known to compromise a few times in the past, but > don't tell anyone. > > Greg