Unfortunately in TurboPascal/Delphi/FPC there is confusion between Objects and Classes due to the TObject/PObject versus Class.
A good discussion here: Usenet Object vs Class post
To summarize the usenet discussion:
Objects require a bit more knowledge about programming than classes, but they are not harmful. Classes are cleaner, but sometimes force you into too much typecasting in niche situations. Too much typecasting and too much organization can actually cause code to become less clear. Strings, integers, and some data structures are better off as non-objects. For example an ansi-string should not be an object itself.
Due to the constant hype from Object Oriented advocates, classes are preferred everywhere. However, in many cases, classes can reduce code clarity and lead to java-like code bloat and application bloat (and not to mention Microsoft DotNet bloat).
Don't be afraid to use classes.. but don't be afraid to use strings, records, or arrays either. And in niche situatoins, sometimes even Objects or TObjects. Do not listen to the object oriented advocate who tells you everything must be a class - because those same people probably use strings and integers every day, which are not classes.
Using the old borland object model (TObject) can reduce code clarity somewhat, but it is still not nearly as bad as a language like C++ or C. Learning how TObject model works, actually can improve greatly your knowledge about objects. Although the TObject model is not used often with the advent of classes, Tobjects are still good to learn about, so that you educate yourself on what is really happening in the background.
Learning the TObject model does help you alot in your education about objects. And if there is a good case for use of objects over classes (niche situations), don't be afraid to use them.
One issue they did not discuss in the usenet post, is robust portability:
If you are designing a plug-in system or a system library that several programmers are going to be reusing, it would be wise to not use objects or classes at all (i.e. the Windows API and the linux libraries are not object oriented). Until programming languages decide on a better common object or class standard (COM kinda sucks and is complex).... records, functions, and procedures are the best method to create robust and portable DLL/DSO/Plug-in systems. Wrappers can always be built around the procedures and records.
The linux or windows operating system, for example, allows Pascal programmers or Python programmers or Java programmers to use their C code by importing it. It would not be possible today, to talk to the operating system, if the windows or linux system libraries were language specific and class oriented.
But many times, robust portability is not needed. Example: an inhouse application that will never become a system library or plug-in host, will not need to worry so much about language portability.
So classes can be used without worry in many common situations. And TObjects can be (but don't have to be) used in niche situations where they can offer some advantages over a class.
Programming is not as simple as only using objects for all situations, or only using classes for all situations.
|
