OOP | Hardware To Software

Inheritance. A first insight

adminFebruary 19, 2012May 20, 2015

The principle of inheritance involves the encapsulation mechanism too; so that we must pay attention to its usage.

In facts when we design a class and decide which items must be public or not, we bind them to precise ranges of action.

But now we add another degree in decision, because of the hypothetical necessity to design a class which at least to derive another one from.
This means that the inheriting classes receive all the parent's features exactly as they're written: private stuff to private, public stuff to public.

A last choice exists, under the protected zone (see in any class code we publish); but we'll see it next time.

But... why to inherit a class?

Certainly not to have just a copy, because it would be useless.

Surely to specialize the original class, called father, into a new one, called child.

A common example is the human being, which can become man and woman, for example.

...continue reading "Inheritance. A first insight"

Pages: 12345

Aggregation of Classes

adminFebruary 8, 2012May 20, 2015

By discovering the beauty of OOP world, in the essential view here offered, we always have underlined how the classes are designed as objects prototypes which implicitly include the possibility to communicate among them, with precise mechanisms.

For the sake of precision, some classes can be written only as general model, without the goal to be transposed in reality as objects.
While this is true, for now let's concentrate only on the fact that a class implies an instantiation, at least.

So the class design at this level requires the knowledge of the relations that its objects must set.

Previous time we saw the composition, between the two involved classes Employee and Document.

To summarize: while an employee object can exist by itself and can have one or more documents, the document object cannot exist by itself and can only belong to an employee.

...continue reading "Aggregation of Classes"

Pages: 1234

Composition of Classes

adminJanuary 31, 2012March 18, 2012

A golden rule in coding is the modularization: the bigger your project is, the more difficult it's to keep it in a mono structure. You're naturally brought to separate logically and even in different files the code portions which are separable.

When you start to design your software in the OOP vision you surely must face these situations, in a different way: to get order inside an initial nebulous idea it's so important to recognize the who/what!

Easy to say, but only the practice and a good eyes can help you: in a big series of data your job is to assign roles and hierarchies, connections and relationships. In facts, as we said in the OOP introduction, over the who/what boxes there are the intercommunications, which are essential parts of them.

Here we show one kind, the so called composition.

Generally a composition means a concurrence of factors bound one each other, whose result is given by the factors themselves and the proportions they express: a typical example is a music composition.
In some contexts a composition defines the manner in which something is composed; not the result but the process behind.
Every meaning you find it includes the concept of relationship between two "actors", at least.

This is the point: which kind of hierarchy does the composition imply?

...continue reading "Composition of Classes"

Pages: 1234

A matter of Class

adminJanuary 21, 2012May 20, 2015

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"

Pages: 1234

OOP. Not oops

adminJanuary 11, 2012March 18, 2012

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"

Pages: 123