Post by Skybuck FlyingHi,
One programmer can only do so much.
So lately I am thinking how multiple programmers could work together and
create huge applications.
I am thinking about seperating everything into API's.
That's certainly one good way of splitting a programming task. Define
a bunch of clean interfaces, then you can work on the different pieces
with considerable independence. During development you supply enough
of a dummy implementation needed to allow the users of missing
components to be developed.
"Interfaces", BTW, do not have to be traditional APIs, but rather any
reasonably clean seam between components. For example, you could
write a multi-pass compiler, and the interface between each pair of
passes could be the layout of the pass output file, or an interface
could be the definition of the datastream passed between two
components via a communications pipe of some sort. In fact, as a
general rule, the less "API-like" an interface is, the more likely
that you're going to avoid excessive coupling across the interface.
With an object-oriented language, you can, with a bit of care, define
interfaces at the class level. Avoid having anything publicly
accessible except the minimum number of methods you really have
defined as part of the interface. Again, this lets you build a dummy
class as a placeholder while other stuff is built.
The difficulty is defining the overall architecture, and then defining
the interfaces well enough. Many projects have foundered due to early
design errors. The various rapid programming paradigms take a
somewhat different tack.
Post by Skybuck FlyingI know windows is mostly made out of DLL's... but those are procedural
programmed. ( C )
Hardly. All COM, OCX and whatnot objects are implemented in DLLs.
Most other large OSs are also built out of "DLLs", although they're
usually named something slightly different.
At the end of the day, DLLs, shared libraries and whatnot are more
about packaging than the structure of your application.
Post by Skybuck FlyingI would like to keep things object oriented. A bonus would be cross language
as well.
What solutions exist ?
A few days back I used COM which was pretty impressive... I think it was
written in C or C++ and I could just import it in delphi
Via project->import type library.
Is COM the way to go when it comes to Windows and Object Oriented
Programming.
It depends on what you're trying to do. For example, many OCXs
implement some type of user interface widget (although that's
certainly not their exclusive use). So you can build your
counter-clockwise-spinning-psychedelic-push-button-control OCX with a
variety of languages in Windows (C++ and VB being fairly popular for
the task), and then use that OCX in any language that allows you to
use OCX based controls. You even get the drag-and-drop function for
the OCX in your IDE of choice.
Post by Skybuck FlyingOne last possibility might be Delphi Packages which are modified DLL's but I
don't really like packages and they are probably not cross language.
As I mentioned, things like OCXs are (mostly) language independent.
Some things (for example a straight DLL) may require that you define
the interface in an interface definition file for each language you
plan on having use the DLL (for example a C header file or the
equivalent for Pascal). I don't know much about Delphi, so I can't
relate Delphi packages to anything in particular.
Post by Skybuck FlyingAre there any other ways of splitting applications into multiple possibly
reusable language independant components ;) ?
Techniques for building large systems have been a hot topic since at
least the early sixties. Any chump out of school can hack together a
few 10's of KLOCs, It usually takes a couple of years to train people
to work on large projects - until then they're mostly annoying.
Managing a large project is *hard*. Getting a bunch of people working
together is *hard*. There's *lots* of literature on the subject,
covering everything from modularization to management issues. As
Brooks said, there's no silver bullet.
At the end of the day much of successful reuse does boil down to
interfaces. The problem domain that your component is useful for is
largely dictated by the interfaces. Too specific and it'll never be
reused because it won't apply to any other need, too general, and
it'll never be reused since it'll be like trying to nail Jello to the
wall. And making a component general purpose the first time tends to
be pretty darn expensive (see next paragraph).
Be aware that reuse is a rather tougher goal than just the minor
packaging issues related to how to structure your application. Brooks
draws a square divided into four quadrants. The upper left quadrant
is a normal program. Moving to the right is the system program box,
and moving down is the program product box, and in the lower right
corner is the system program product box. System in this context
means OS-like code as opposed to application, and product means
something packaged for sale. Most of use have come to accept that a
truly reusable component is basically equivalent to a "product".
Anyway, moving across or down the square (eg. from program to program
product or system program) involves approximately a tripling of effort
required, and moving from program to system program product is about a
nine-fold increase.
I strongly suggest reading Brooks (The "Mythical Man Month" - be sure
to get the 20th Anniversary edition).