Practicality of Object-Oriented Programming 1

[Glenn9999]

I know I've read all the references and I have a understanding of the basics of OOP (have to to manage doing the Visual Basic and Delphi VCL I've already done).

I'm looking for a more practical explanation as to why I would want to deal with OOP (beyond being forced to if one uses the VCL). What is the benefit to me in my programming compared to the other way?

I see a couple of advantages, and a whole lot of disadvantages to OOP, but basically I'm confused. Can anyone explain OOP in a more practical sense than all the theory I keep getting exposed to regarding to the topic?

 

[svanels]

Objects are not limited to programming or the VCL, in fact computer programs were written to resolve real world problems. In the past a pre requisite for programming was mathematics.
Coming to the point, how would you solve the dillema of the spouse sending her son to the grocery?

Monday:
5 donuts and 3 eggs costs $1.45
Thuesday:
6 eggs and 4 donuts costs $1.70

By wednessday she ought to know what is the price of a donut and an egg.

How would you let the computer solve this mundane problem for you? (using OOP)

Steven

 

[towerbase]

The VCL is actually a good example of the benefits of OOP.

The beauty of Delphi and the VCL is that it hides the complexities of writing Windows applications. It helps you to concentrate on implementing solutions to your business problems rather than wrestling with the Windows API.

Likewise, in your business domain you could build a kind of business component library where you encapsulate business entitities and code them into classes. If you design and implement these properly you will have a useful resource which will both speed development of new applications and also isolate functionality which may be subject to change at some point.

A few years ago I taught OOP at a local college. It's not an easy topic to teach because OOP rarely shows any benefits in the kind of exercises that students can do in a classroom. OOP shows benefits on big projects over a long period of time. Both in the development and maintanance stages. Students are rarely exposed to the problems of maintaining code in a large system.

You can absorb OOP technology in stages.

First get used to encapsulation. Identify objects in your problem domain and start to design classes. Hide all the implementation details and only expose those properties, functions and procedures that are required.

Second, consider where one class is special case of another and use inheritance where it is appropriate. You will almost certainly have to back to step one.

Third, consider using polymorphism where it is appropriate.

A downside of OOP is that it seems to take longer to develop an application. This is because you have to do more thinking up front before coding. You then have to build your classes. There's nothing visual to show for all this effort - whilst the hacker who starts coding straight away can have a prototype written in Delphi running almost on day one.

Despite what I've just written above, I frequently hack code out because of a deadline but then wish I'd done the job properly because the result is a mess. If I'm lucky I have the opportunity to go back, start again and do a proper OOP job.

Andrew
Hampshire, UK

 

[abrogard]

Please excuse my ignorance - I don't even know what VCL is - and perhaps I shouldn't even be sticking my neck in here but I'm going to anyway.... as quickly as I can...

Years ago I was a Clipper programmer. Way before OOPs. That's an extensible compilable dBase language, or was. Very looked down upon by C programmers and such, I think. But it was written in C and extensible into C or Pascal or Assembler and that's what one did - extend it with your own routines.

And with guidance from a certain guru whose name I've shamefully forgot but who wrote a series of books which were my bible, my programming skills grew and grew.

And my stock of written stuff grew and grew.

And my stock of re-usable code grew and grew.

And it became more and more obvious that I needed to write genereal-purpose functions just so I could re-use them.

And it became obvious that if I could include data in those functions it would be good.

And so on..... skilfully steered by this guru it became obvious that we needed to write the functions that are today called 'objects'.

And that's where I would - humbly, tentatively - say is the requirement, the need, the value, of OOPs.

In that vast palace of code, routines, functions that you have written yourself and borrowed from others and incorporated as yours there will grow certain 'entities' that are tremendously useful to you. Your own objects that you have an intimate understanding of.

And from this naturally developing understanding of objects would also come a natural appreciation of the value to you of some objects written by others.

And you'd gratefully seize them and include them in your armoury.

You would have made the shift from traditional programming to OOPs and would have an OOPs mindset. A change in the nature of your thought processes as complete as that which happens, say, when you fully assimilate recursion.

As the man says - explaining this to students wouldn't be easy. And they couldn't I suppose approach the subject from this direction, they'd want to, need to, jump straight in - not build up to it by experience.

Again, as the man says, approaching a new programming task may take considerable time and effort to see in an Object oriented way. Especially if you don't have the sort of slowly nurtured and naturally grown, deeply understood appreciation of OOPs that I've tried to indicate.

On the one hand you approach the task with a great bag of tools which contains 'depth', shall we say, with these powerful 'objects' in it and that bag of tools is your natural way of working and these 'tools' are as much a part of you as your fingers and toes.

And you'd just go to work naturally. OOPs not being a separate discipline to you but rather a natural outgrowth of your programming life, your experience. A very natural development. The logical progression of your own coding.

On the other hand you are hovering over the problem and trying to 'see it' in either or both of these two different ways: OOPs or trad. Trying from the beginning to use other people's theories, definitions, ideas, understandings.....

Pity the poor beginner, that's where they must be at...

So that's what I think.

Visual C and such killed Clipper.

I got lost in that horrible wasteland called User Support, network Support and constantly chasing understandings of Bill Gates latest release - wasting all my mental energy in that ridiculous trivia.

I never 'grew' my code to OOPs. I know nothing. I do nothing.

I am today confused by the plethora of programming languages and don't know where to start again.

Bemused by the apparent immense difficulty or even impossibility of having the control of the pc that we used to have back in those days.

Astounded by the apparent complete lack of a command language even as good as microsoft's batch language used to be far less one as beautiful as Digital's DCL was.

I retain an interest, though. Programming was the love of my life. I hope I haven't bored you all to tears and I hope I wasn't too far off the subject.

regards to all,
ab

 

[Zathras]

Glenn9999: Theory aside, here is an example that may provide a glimmer of hope that it is all worthwhile:

Environment: A collection of offices that are structured as Districts which report to Regions which report to Divisions, and a collection of people who are the Managers of each office.

At some point in the code, it is necessary to know the e-mail address of the Division manager for a given District.

Using OOP, all you would need to do is something like this:

procedure SendDivisionManagerEmail( ADistrict:TOffice );
var
  sEmailAddress: string;
begin
  sEmailAddress := ADistrict.Parent.Parent.Manager.Email;
//
//   (generate and send the e-mail to sEmailAddress)
//
end;

This assumes you have defined a couple of objects something like this (greatly simplified):

type
  TEmployee = class(TObject)
  private
    FEMail: string;
    FName: string;
 public
    property Name:string read FName;
    property EMail:string read FEMail;
  end;

  TOffice = class(TObject)
  private
    FName: string;
    FManager: TEmployee;
    FParent: TOffice;
  public
    property Name:string read FName;
    property Manager:TEmployee read FManager;
    property Parent:TOffice read FParent;
  end;

Of course, you would need more than that inside the objects. You would have to code for creating the objects and setting the links appropriately. Not a trivial task, but you only have to do it once. I have a unit for just that purpose. There are routines that load the entire office structure into memory at start-up, invoked by a simple procedure call. (There are other ways of doing it. Mine is not necessarily the best. But that's not the point.) The point is, with the data structured in that way, using the "dot" notation in code makes life much easier at that end.

 

[svanels]

I have started with OOP before Delphi existed, with Turbo Pascal 5.5. I still have the book: "Object-Oriented Programming Turbo Pascal"
To come back to the priginal problem about the housewife, there is a set of equations that can be solved various way.
The traditional way is to mount a 2 x 2 matrix, code your equations based on the given situation, supply data and run.

The object way: Mount a generic matrix with properties (the data) and funcionalities (embedded procedures, functions).

Once you have created the object, derive others objects from it (inheritance) and start using.

Once defined, it doesn't matter if the matrix is 2 x 2, (the example) or 10 x 10, just call the embedded properties to resolve your problem.

The new approach

Use objects, let the objects interact so they give the solution.

The VCL (Visual Component Library -abrogard) is just an application of OOP, and like others have stated, you don't have to worry how the mouse have to respond to a doubleclick, or how to work with an editbox to make a windows look-and-feel program.
The time gained you invest in the meat of the program, not the bells and whistles.

Steven

 

[Glenn9999]

OK, all I see again is theory.

Let's take it this way:
1) Reusability. This factor is already existent in non-OOP codes and situations. Procedures and functions. Units. In fact, I have a treasure chest of such things. And furthermore a lot of us for a lot of years called these things "objects" before I ever saw a true OOP program.

2) What if you change variables? What's stopping me from changing a typedef and recompiling a unit or copying code (which I've done for years)? I almost always tie any kind of relevant data type to a global type-def to the unit.

3) The only real advantage I see to OOP is the ability to blackbox common functions (like was mentioned with the VCL definition). Beyond that, all I really see are disadvantages given the times I've coded OOP things (Delphi and elsewhere) and what I see in the general Windows world. Longer development time, messier code, poorer quality code with a higher number of bugs, larger executables, slower run-times, and less ability to debug problems as the result of the blackboxing of code.

Evidently someone out there thinks there's enough advantages to outweigh the numerous disadvantages I've encountered (of course, I just think this is just another substandard thing Microsoft forced on everybody with VC++ getting popular) for this OOP procedure to become so widespread. So maybe we can settle it with an example so I can see what they are.

I have an array of numbers. We want to perform the median, mean, and mode on them.

To make this reusable without OOP:
1) Make mean, median, and mode functions using an array that is tied to a typedef. To make it truly portable I can stick this typedef into the unit source.
2) I can make my temporary variables local storage for each of these procedures. For the array I would need for processing the median proc I can use the array I pass to the function (since it wouldn't be a var def I could do that and not destroy the contents of the main program). Put sorting algorithm in as a procedure that operates on the typed array.
3) Return the results.

What if I want to change this?
1) Need another function against the data (std. deviation perhaps/). Add it to the unit, recompile, test, away I go.
2) Perhaps I want to work with singles instead of longints? Change the typedef, recompile. Larger array? Change the typedef, recompile.
3) If I distribute this, document the typedefs and the interface. Provide the code. (I've found it's never wise to not have anything from someone else in programming without the code itself for numerous reasons).
4) in the using program, simply put uses statement in and call code.

Now with OOP:
1) Define the object. Place array def in public var area.
2) Define passing procedure to get array into object.
3) Develop public mean, median, and mode methods to operate on the array def inside the object.
4) Develop private sort procedure.
5) Develop passing procedure to get the sorted array back to the program.

Now changing things - my main program can do that as well by revising and extending the object with my own object class...but how do I know what I am revising and extending to begin with if the original object is tucked away somewhere (that's my current nightmare with the VCL in every serious OOP attempt I make)? Nothing new or different that I'm seeing than the other process, I'm just making the changes in the main program. But a whole lot more trouble, IMO (3 steps trad versus 5 steps for OOP).

I just fail to see the advantage of OOP here. Both are reusable, both are as malleable, as far as I can see.

Now in this specific case, why would I want OOP?


* Mean is the average of a set of numbers. Median is the middle number in the set if they were sorted (in 2, 4, 7, 4 is the median). Mode is the number that occurs the most.

 

[svanels]

I make my own objects, that is the way I control it. About the VCL components, I adapt them, it is not necessary to invent the wheel. In the seventies the scientists returned to the basic concepts of programming. They argumented to make the data the focus of attention, and not the manipulation (procedures etc.) If you look around you, we are living in a world of objects, now you can argue that this theoretical stuff, but Noboddy is forced to do OOP.
Once defined your own objects with your specific requirements, use them. 15 years ago I defined my own objects of matrices, vectors, complex numbers etc.
1 year ago I had to explain the procedure of balancing a 40 kg rotor on a complex machinery, using a handheld vibration analyzer with build-in balancing module. The craft failed to visualize wath was happening, except it was press button x, then y on the analyzer.
Took out the object code of the archieve, brushed of the dust of my vibration manual and in 3 days I had a windows look program ready with, jpeg, bitmaps, movie, where they punched in the readings. If I had to make from scratch the calculations again of complex number maths, I would be busy longer then a week. Just called A.Multiply(B,C). The whole operation of setting up the meat of the application took about 30 minutes.

That is my case story of the use of OOP

If you fail to see the advantages of OOP in this, I can't help you.

The underlying message is, that you do not write programs because of the programming, but to resolve some problem. It is up to you how you will do it. If you take 2 years to resolve it, you will lose clients and credibility.

Just put in PDF funcionality in my database reports, do you think I have time to study the nuts and bolts of acrobat writer? My boss don't care if I know acrobat or delphi (even don't know what is delphi), but he understands the report I attach to the e-mail, giving production and maintenance data.

Steven

 

[Glenn9999]

OOP is a theoretical thing. Let me relate this to something I do know inside and out. In database design there are a bunch of egghead theories that are used which have an umbrella name called "normalization". There are several levels called "normal forms".

Fine in theory, but in practice there is a common saying: "You know your database is fully normalized when it stops working." Guess what? These egghead theories fly right into the brick wall when it comes to practice time. I have never seen an operating production database that follows fully the rules of normalization, with good reason, and that reason is behind that quote. When it comes down to practice it just plain don't work.

That's the point of what I'm asking here in this thread. In all the cases I've seen, I seen OOP work well in only a very few limited cases. I just don't plain see where or how OOP works well in practice. For what I've seen, OOP is flying right into the brick wall just like normalization rules for databases are.

Still waiting for enlightenment here.

 

[svanels]

I agree that this theoretical thing of database normalization is not a must. I read about the 1[sup]st[/sup] normalization rule, made it through the 2[sup]nd[/sup] normalization rule , and gave the 3[sup]rd[/sup] to the .
Maybe intuitively I follow some of the rules of normalization, but my point of view is different. If it works, oke I use it, it doesn't apply to the case, forget the rules. The bottom line is to use plain horse sense, why do difficult if it can be done easy.

Coming back to database design.
I made a database that is used in an industrial process. I read some good (delphi) books about databases. My favourite is "Delphi 3 Client/Server Developper's guide"

It is not just scraping some tables and hacking some code.
First you design a Form hierarchy. You have data-entry forms, decision support forms and interactive forms. Also a Report hierarchy.
Why, you want the database components to interact with lets say your statusbar, giving clues to the user where he is and what he is doing. When testing and troubleshooting this is a valuable tool (especially over the phone, and some at the other side).

So the forms with database components have a common ancestor where the basic funcionality interacting with the statusbar is implemented. If a special form need something more, just implement it at the appropriate place. If at a certain point you need a similar form, just clone it.

The reports (quickreports) have also a common ancestor with company name, logo, date printed, quickreport component, among others.

Now the users demand the possibility to send the printed report by email and/or store it for history. You can try to put quickreports on every computer in the company and try to learn them Delphi to do this. I suspect the most positive feedback from the users would be where they could buy the stuff you smoked when had this brilliant idea.

I used a conversion engine, put only two components on the BasicReport form. One a quickreport interface object, the second a PDF-engine object. I linked the PDF-engine with the interface object (just 1 mouse click in the object inspector) and recompiled the source. Instantly all 18 reports can be saved in PDF, and there is no rocket science , or black magic involved.
Next day distributed the new version and told the users to use the save button already present in the reports, select PDF and give a name.

Programming is a tool, not a means, just like a hammer, a 80 ton crane or a pencil.

We can theorize a lot about swimming, but if you never took a dive in the pool, the theory is useless.

Steven

 

[towerbase]

Glenn9999

Still waiting for enlightenment here.

I don't think you will get it. You seem very reluctant to take on "new" ideas. You seem resistant to OOP, Normalisation, Recursion and possibly other techniques.

Fine, you can develop business solutions without using these ideas if you want to. You may even be using these ideas but don't like putting a label on them.

This is a Delphi forum. Delphi is a very effective tool, probably the best there is, for developing Windows applications. OOP is the fundamental cornerstone of Delphi. There probably isn't a better example of OOP in practice than the VCL.

I don't know if you've ever tried to write a Windows application using the Windows API and message loops. It's difficult, requires a lot of knowledge and I found it error prone. By using OOP, Delphi provides a very easy way to develop Windows applications. By using inheritance, the complexity of producing a program that displays a form that can be resized is almost totally eliminated.

As I said before, the benefits of OOP really come from big projects not trivial problems like your median, mean and mode example.

This is why teaching OOP is difficult. A student doesn't have the time to develop a large program using non OOP techniques and then develop it again using OOP to find out the advantage of OOP. So they have to learn some theory and then practice it on small projects (like your median, mean and mode example). But as there aren't many advantages to OOP in small projects the overheads of OOP don't seem worthwhile. This seems to be the stage that you are at.

I think that if you are happy with your non OOP programming then carry on that way.

Andrew
Hampshire, UK

 

[svanels]

Andrew I thaught programming at a volunteer's group years ago.
With 3 "greedy" students we started the basis of some of the objects I mentioned. This were mech engineering students and we searched for practical objects in our related field.
It is difficult but, I would stay of a group were programing is an obligation. The average student don't like mathematics and physics, imagine programing.

Maybe the world has something against logic thinking?

Steven

 

[Stretchwickster]

I maintain and improve a product that has been on the market since 1997. Often we find that a planned new feature has similarities to something we've created in the past.

Development time is reduced significantly when a new object can inherit from an existing one but extra functionality needs to be added.

For example, in the past we have created a charting component (inherited from TChart) called TChartEx to which we have added mouseover hints for the various points in the series. We didn't need to write a brand new chart component which would have taken a bit of time to do. Instead we used the existing functionality of TChart and added our own.

Some time later, we wanted to add the ability to trace through all the points of a chart series using a cross-hair to show the current point and some sort of display for the xy coordinates of a series point.

Now, we still wanted the mouseover hint behaviour but we wanted to extend and add functionality so we inherited from TChartEx and added a TUpDown control to move through the series points and a TLabel to show the coordinates and a function to draw the cross-hair on the chart etc. Again, we didn't have to create this component from scratch - so we saved yet more time.

If code is well designed using OOP, development time can be significantly reduced. This is just one commercial advantage of using an OOP like Delphi.

Clive
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"To err is human, but to really foul things up you need a computer."
Paul Ehrlich
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To get the best answers from this forum see: faq102-5096

 

[sggaunt]

This is a Delphi forum. Delphi is a very effective tool, probably the best there is, for developing Windows applications. OOP is the fundamental cornerstone of Delphi. There probably isn't a better example of OOP in practice than the VCL.

Nonetheless it would still be possible to have a VCL even if it were not OOP'ed,(albeit a less powerful one).

Some small projects do also benefit from an OOP approach I wrote a routine to create a rain effect with animated drops which fall then splat, this was an ideal candidate as each drop is an object and therefore indpendent of the others, It would have been harder to do this in a none OOP way, and there isn't much code at all.

Generaly I belive most OOP is complexity for its own sake. You no doubt heard of software bloat. I am speaking as an ex C64 coder here.





Steve: Delphi a feersum engin indeed.