johnson@m.cs.uiuc.edu (10/15/90)
It is often a good idea to hide the complexity of a subsystem behind a single object. For example, programs in Smalltalk-80 are compiled by creating a Compiler object and telling it to compile a string. Of course, the compiler itself is complicated, but the program that uses it doesn't have to be aware of the complication. However, don't interpose an object between the application and the subsystem unless it really can hide complexity, not just provide an interface to it. Although classes are an important tool for achieving modularity, they are not the only tool, and are not sufficient in a large system. Large systems need to group classes into subsystems and to create a module for each subsystem. I don't know of any object-oriented language that supports this perfectly, though C++ is better than most, since you can control knowledge of interfaces by controlling which header files are included. Ralph Johnson - University of Illinois at Urbana-Champaign
vaughan@mcc.com (Paul Vaughan) (10/16/90)
I've worked on a project with only 3 people (ok, so it ain't exactly OOPIL), but involving on the order of 100K lines of code. We did not encounter any "object integration" problem, as mentioned by a previous poster. We divided the project like this: each person worked on his own set of objects. One of us worked on base class stuff and also a particular functionality segment that tied in closely with the base classes. The base classes went into a library that the other two of us used. Another worked on application oriented stuff that would be "used" by a developer or sophisticated user who was extending the system. The third worked on stuff that formed an initial library of such extensions (and was designed to be extensible itself). When we wanted to design something new into the interfaces between objects (that is add or change a member function declaration), we'd get together and figure it out. The guy who did application oriented stuff ended up making a suite of extension level stuff to test his code, but these test classes were far less complicated than the classes the third guy was working on. The third guy (extension level) wrote driver programs to test stuff during the early stages. Occasionally mock ups of the application level classes were created. I think the division of labor put more work on the application level guy, but we tried to help each other out all the time. Part of the reason we didn't have much of an "integration" problem is that we worked on a continuously demonstrable prototype. From nearly the very beginning there was some level of integration and some stuff we could demonstrate. We designed alot of that beginning stuff together. From then on, integration was an incremental process. Paul Vaughan, MCC CAD Program | ARPA: vaughan@mcc.com | Phone: [512] 338-3639 Box 200195, Austin, TX 78720 | UUCP: ...!cs.utexas.edu!milano!cadillac!vaughan