On 07/10/2016 16:12 μμ, Marcos Douglas wrote:
The team shouldn't know about the hierarchy; about how was implemented
these classes.
They can use TDataStream directly or as a contained object.
But as I understood, we need to use TContainedObject or
TAggregatedObject only in these "special cases"
You are correct the TContainedObject can only be used with a root
object, now what? Is this a block for you?
It is not the library's responsibility to solve your problems only to
assist. TContainedObject is a basic solution which is generic enough to
accommodate 90% (assumed number just to emphasize its usefulness) of the
use cases.
Now why is your use case special enough to be included in the library it
self?
I didn't test yet. I will. But if I'm right, ie, if TDataStream is
inherited from TContainedObject and, because that, I can not use
TDataStream as a simple instance, without a "root" object... well,
this design is wrong.
well let me see....
You failed to clean up properly after your code (a simple fValue := nil
in TMyApp.Destroy method should solve all your problems), you did not
knew the basic mechanisms provided for the exact problem you are having
and you attached your design sort comings to a language feature that has
nothing to do with it. All in all, you have failed to do your homework.
I should listen to your opinion about design ..... why exactly?
If somebody says: "You should know these classes..." or "you should
know what you're doing..."
I will answer: this is not about OOP, just procedural. OOP is about
encapsulation. If I need to see the class' code, this means that it
was not well done.
No! Any object solves a single problem. If it does not fit in your own
design then you either have the wrong design or you need to customize
the object to include your use case. In both cases you need to read up
and understand which use cases is solving, how it does it and how you
can extend it to support your own use cases. It is not responsible to
accommodate your assumptions.
Can things get better? Sure every change no matter of its size, moves
the library forward but if that change is appropriate for the library
can only be decided by the library maintainers and you (or me for that
matter) crying wolf does not help.
For me extending the TContainedObject to support both contained and
stand alone use is trivial I bet you can do it as well now that you know
where to look. I'm against adding that kind of functionality to
TContainedObject as it is outside of its designed goal.
If a new object adds more value or more bloat to the library is up to
the maintainers to decide.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
