Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!wuarchive!julius.cs.uiuc.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!m.cs.uiuc.edu!johnson
From: johnson@m.cs.uiuc.edu
Newsgroups: comp.lang.c++
Subject: Re: C++, Object Design Methodologies an
Message-ID: <4800106@m.cs.uiuc.edu>
Date: 15 Oct 90 04:33:00 GMT
References: <24872@uflorida.cis.ufl.EDU>
Lines: 19
Nf-ID: #R:uflorida.cis.ufl.EDU:24872:m.cs.uiuc.edu:4800106:000:974
Nf-From: m.cs.uiuc.edu!johnson    Oct 14 23:33:00 1990


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