> - As "Applications with Helper utils" I define shell-applications > that rely on other executables that do all the work and these > are mostly driven by using stdin and stdout or by using some sort > of (temp-)file to let the external exe work with, which are both > very dirty solutions. > > With the thought of OOP in mind, and Delphi is OOP, only the first > way of writing code is acceptable, but, and this is the exception, > the second way may only be used if, for instance, it's impossible > to use the first solution because both "Application" and "Helper > utils" do not reside on the same computer and/or "environment" > (eg on a client's machine and corporate server).
There are situations where building an application as a monolithic EXE is attractive, but you need to understand that large scale applications cannot possibly be built as a single EXE simply because they are too large. Further, you should remember that the Delphi programs that you compile make very heavy use of the OS which is largely made up of DLL's. Executing an external command-line program to perform a utility task is not a "very dirty solution", but is in fact a much cleaner solution than static linking common tasks like searching, sorting, and filtering. In the UNIX and Linux world, this approach is not only common, it is the way in which the OS itself does things. It is a time-tested way to accomplish code reuse that virtually all large scale system employ. Glenn Lawler ----------------------------------------------------- Home page: http://groups.yahoo.com/group/delphi-en/ To unsubscribe: [EMAIL PROTECTED] Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/delphi-en/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
