Being a fan of DDD and Event Sourcing as I am, I'd implement your domain
using Aggregates and Events.
Basically, your aggregate (Plant?) would respond to external information
(or based on a schedule) and as a result, new events are generated ("Flower
sprung", "Plant died", ...).
If only we had properly documented our Pharo-EDA "framework"...
https://github.com/osoco/pharo-edaEl mié., 16 ene. 2019 a las 18:05, Loïc Pagès (<loic.pa...@inra.fr>) escribió: > Hi Richard, > > You are in the south hemisphere, so ! Temperatures are low here in France. > > Thank you for your comments. > I agree that development is slow if you look at the plant every day, and > in this case we perceive continuous changes. But in models, it might be > convenient to define discrete stages. If you look at a flower bud at a > given date and come back several days (or weeks) after, you can see a > flower at the bud location. This type of approximation is usual in > biological modelling and data acquisition. > > Thank you for the suggestions on the "State" design pattern. I will have a > look ! > > Loïc > > Le 16/01/2019 à 13:18, Richard O'Keefe a écrit : > > It seems to me that in the real world, a bud does not get replaced by a > flower > nor a flower by a fruit, nor is there a definite point at which a thing > stops > being a bud and starts being a flower, and so on. It's summer now, but > spring > wasn't that long ago, and I enjoyed watching the imperceptible *continuous* > changes. So anything you do is going to be imposing discontinuity on a > more- > or-less continuous process and is definitely going to be an approximation. > > You may perhaps be looking for the "State" design pattern where there is an > object with a fixed identity (*this* bud/flower/fruit) which behaves > differently at different times, and this is modelled by the "outer" object > delegating some of its behaviour to a "state" which can be replaced. > So you would have > PlantOrgan > PlantReproductiveOrgan (state) > > PlantReproductiveOrganState > Bud > Flower > DeadFlower > ImmatureFruit > MatureFruit > > You will find abundant material about the "State" design pattern on the > web. > > > On Thu, 17 Jan 2019 at 00:29, Loïc Pagès <loic.pa...@inra.fr> wrote: > >> Hi Joachim, >> >> Thank you for your reply and for your ideas. I will reply to your >> questions below. >> >> Le 16/01/2019 à 10:25, jtuc...@objektfabrik.de a écrit : >> > Loïc, >> > >> > Am I correct in assuming you are thinking about a model in which a >> > plant can have a growing and shrinking list of organs over time and >> > some of them even have (a growing list of) stages? >> >> Yes, the plant can be seen as a growing and shrinking list of organs. >> Very short list at the beginning, and becoming larger. Some organs can >> fall (leaves, roots) or even be pruned (shoots in fruit trees), so that >> shrinking can also occur. >> >> However, the list of stages for each organ is usually known at the >> beginning, for each type of organ. It depends of knowledge and level of >> detail that we include in the model. >> >> > >> > I am not an expert on the matter, but to me the stages idea sounds >> > good. It even allows for historic information (it was a bud from Date1 >> > to Date2 and since then it is a flower). So transformation would be >> > adding a new Stage and "terminate" the previous one. >> >> This can be an approach. But the conditions for passing from one stage >> to another can be more complex and involve several aspects (age, >> previous growth, pollination, etc) with a lot of code. So, if you keep >> this code into the general "reproductive organ" class, you make a "fat >> class" with a lot of tests. This was not recommended in the Pharo course >> :-) >> >> > >> > With this you can ask a plant about its current stage on the >> > reproductive front and maybe other organs as well at any point time. >> > This may be helpful if you want to build an animation of the plant's >> > development over time. You can have separate life cycles for each organ. >> This is actually an objective of such models, to be able to get the >> status of the whole plant, regarding the stages of organs. >> > >> > Does the plant transform in the real world? I mean, is a cherry tree >> > still a cherry tree, even if it's not blooming any more and carries >> > fruit instead? So why transform the object in its abstract model? >> The plant usually changes because of its development, but a cherry tree >> remains a cherry tree ! And flowers are necessary steps to get fruits >> ! The idea was not to transform the whole plant, but each individual >> organ that it carries. >> > >> > >> > Just a thought, maybe better ideas show up. >> >> OK, thank you again >> >> Loïc >> >> > >> > >> > >> > Am 16.01.19 um 10:15 schrieb Loïc Pagès: >> >> Dear Pharo users, >> >> >> >> I develop software dedicated to the simulation of plant development >> >> and 3D architecture. >> >> >> >> In the past, I used Java, but I am very interested in translating >> >> code in Pharo. I appreciated very much the language and the course. >> >> >> >> I have a question for you all : >> >> >> >> During plant development (ontogeny), new organs appear, that are >> >> gradually tranformed. For example, a bud can make a flower, and then >> >> a fruit. >> >> >> >> Organs are conveniently modelled as classes. During the course, I >> >> learned that it was better to make several classes (bud, flower, >> >> fruit) instead of a "fat class" such as "reproductive organ" with >> >> many attributes and stages (bud stage, flower stage, fruit stage). I >> >> wonder how to transform an object into another one, to represent for >> >> example the fact that the flower may become a fruit. >> >> >> >> Maybe a naive question ? >> >> >> >> Thanks for your lights ! >> >> >> >> Loïc >> >> >> >> >> >> >> >> >> > >> > >> >> >> >
