[Lazarus] OOP - where do you start?

[Frederic Da Vitoria]

2015-06-26 13:30 GMT+02:00 Graeme Geldenhuys <mailinglists at geldenhuys.co.uk>
:

> Hi,
>

Hello,



> Last night I was working on a relatively new project. This got me
> thinking... How do others tackle such a task?
>
> So here is my question:
>
>   When faced with a new database related project, where do you start? Do
> you first design the database schema, then build the BOM (Business
> Objects) accordingly? Or, do you first design the BOM, then design the
> database schema to fit.
>
> Personally, most of my project were started by first creating the
> database schema. Don't ask me why, that is just what I did. Maybe it was
> because many of the tools I use, can write much of the boiler plate code
> for me, and they do that by querying a database structure. But I've been
> thinking that with my next project, I'm going to start with the BOM
> first, and see how it goes. I'm assuming the end result should be the
> same, no matter which part I tackled first.
>
> What's your thoughts?
>

IMO, it depends on the complexity of the project. In simple projects (a few
tables), usually the BOM maps exactly to the database, so I do both at the
same time. But in complex projects, BOM can be significantly different from
the database structure. For example, the BOM could include things which
would actually map to aggregated views. Usually I first design the BOM
according to the requirements, then I rework the database structure,
including for example things which were not requested but which I feel will
be useful later (timestamps, history tables, intermediate calculation
steps, future developments...).

One classical example: if I am asked to create a table with name and
address, I actually create a table with the name and a separate table with
the addresses, so that when (this always happens) the client discovers that
people have more than one address, the database structure is ready, but
also the code using that structure is ready too, or at least the
modifications to that code are going to be simpler. In my example, the BOM
still has the address included in the same object as the name, and the UI
can behave as if this was physically true.

In a way, separating BOM from physical structure brings the same kind of
advantages that structured programming does. Just as I can look at a piece
of code from a higher level or right at the deepest code in the deepest
routine, depending on my needs, I can look at the data from a wide point
(usually using views or complex queries) or break the data in smaller parts
and look at the physical data directly in the tables.

-- 
Frederic Da Vitoria
(davitof)

Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20150626/117a82c7/attachment-0003.html>