On Mon, 17 Jan 2011, Marcos Douglas wrote:
2011/1/17 <michael.vancann...@wisa.be>:
I don't have to. But 80% of the functionality returns.
This 80% is taken care of. The rest is business logic.
Business logic in the Form class?
We work 3 tier.
Most important business logic is on the application server.
Clients contain mostly presentation logic.
That's it. 95% of all forms descend from TDBappform. The rest descends from
TAppForm.
Never happen to you have a child form (inherited of TDBAppForm) but
with special features such that it did not fit well with the routines
of TDBAppForm? So what did you do? Maybe you skipped some TDBAppForm's
methods having to implement them again, otherwise, only for this
particular Form, no?
No. The 'extra' functionality is just never used in such a case.
(in 3000 forms, there are 2 such cases)
And remember: I do not try to foresee all possible situations.
I try to make sure that 99% of all cases are covered.
The remaining 1%, the programmer is free to use his imagination.
That depends on your definition of big.
The form class together with all it's 8 auxiliary classes takes 2300 lines.
I don't think this is big.
Well... 2300 is not so big.
And you make a common mistake: you try to do everything in OOP in the parent
class.
Just when I use OOP.
I have Forms RAD and Forms OOP (but just in Delphi... in FPC, I'm a
newbie for now).
What is more, if now we need a new functionality in all our forms,
I introduce it in the form class, and all our forms now automagically have
this functionality. This has happened numerous times in our application.
If your application has only 20 forms, all this is not worth it.
But when I started, I knew that there would be lots of forms, and an
application that would evolve over 10 years.
I did as I described here, and this has saved us huge amounts of time. The
whole team and management here agree on that.
(one of the few things management and developers agree on ;-) )
I believe, sure. But my point is that can be done with code/classes
without RAD approach too.
I know that, I do not dispute this.
I just want to point out that RAD does not mean one has to make compromises.
It is a good concept, which really allows to work fast.
Michael.
--
_______________________________________________
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
