Skip to content

Form-Employee-Class-Method
Form Employee - Class Method

Last time we saw an introduction of what the OOP entails, with a quick look at its four main principles (encapsulation, abstraction, inheritance, polymorphism) and talking about the default mode to instantiate (create) an object from a class, designed or not by us, with the constructor.

So much concepts at once, indeed; and from now on we'll trying to make order in our heads.

By writing the TEmployee constructors we applied the polymorphism: because of the hierarchical system, every class in FreePascal automatically derives at least from the most abstract class, TObject, taking its default members like the constructor itself.

 

We don't want to exclude its usage from a TEmployee's object, so that we overload it with two new constructors: by overloading we simply make them the new default ones, but keeping the possibility to recall the TObject's one when required.

he instantiation occupies memory, and even if closing an application that memory is freed, nonetheless it's better to provide a method who does this efficiently.

Again, a default method is present and automatically inherited: it's so called destructor!

Here a difference with the constructors: the destructor is unique!
The one in TObject is defined as virtual: this modifier implies that every inheriting class should redefine a new destructor.

 

...continue reading "A matter of Class"

Box-Object
Box Object

You're here for two possible reasons: looking for Object Oriented Programming or wasting your time (too much oops in your life).
Even we hope for the first but it's not your case, remain here to read and see if this proposal can catch you.

By watching a picture we generally see stuffs represented, and we call them with the same name used in all days life: but as just said, they're representation. The picture conveys an information we're able to understand, but it cannot brings you the exact object it shows.
But what is an object?

Good question and so difficult the answer is: primarily we rely on our sensory perceptions, then getting a major abstraction while we grow, until we arrive at a certain point where we confuse the object with its representation we have in our mind.

...continue reading "OOP. Not oops"

Overloading
Overloading

You cannot compare apples with orange!
How many times we heard this sentence when we tried as children to do something apparently illogical?
We're here going to talk about an argument that looks like it: the overloading operation.

Despite of picture beside, the concept is indeed light: it's just a matter of definition, and programming languages usually give us all the possibility to redefine a wider set of expressions for the subject of overloading.

We surely cannot get an apple juice from only orange and vice-versa, but we surely can have one of fruit with both of them: we have just expanded the "making a juice" meaning.
So what about coding?

In this context we make the same, in the sense of a meaning addition: but which is the subject?
Generally every talk about overloading concerns a separation between the two possible macro fields of application:

i)  operators overloading;

ii) functions/procedures overloading.

While this can be useful for specific differences between them two, in reality it could bring a novice to a little confusion. Overloading is the same for both of them; this is the main point, after which we can face every other aspect involved in its particularizations. ...continue reading "To Overload or not to Overload"

Form-Employers
Form Employers

In previous two articles we talked about array management: copy by value and copy by pointer methods have been exposed to achieve same results but in different ways.
The former being direct and simply, the latter more powerful but danger (because of risks related to pointers).

If you get familiar with pointers you can understand their usefulness, so that they become sometimes necessary to ease some tasks; but we know their dangerousness!
Nothing stops us from building some construct, or data type thanks to which we can use pointers with a major security degree.

That's probably what people who writes TList types (for every programming language) thinks.
This is because the list is a so powerful and useful and commonly used data structure written for homogeneous elements.
Well... homogeneous! This surely recalls an array. And that's true!

...continue reading "TList. To improve array management"

Form-Employers
Form Employers

In previous article Array management by value we talked about one way to grant to us access to array's items: we used a by value approach, in the sense we surely took copy of items values by dereferencing a pointer to record we defined at the top of code.
Our intention was to emphasize that a copy by value can even be made with the help of a pointer.
Pointers in that context could represent an alternative way to archive or reach the documents: instead of alphabetically (array[index]), by coordinates (for example, just like in battleship).

 

Result is essentially the same:

  • we compile an original document and copy it to our file in archive;
  • we fetch documents, then copy info through pointers, manipulate them.

In other words, we prepare a new record with all data, then we store these values into an array of records; so we pass values.
On the other side we create locally a new record, where to host all fetched data from array, with pointer's dereference. ...continue reading "Array management by pointer"