How should a container class "know" its contained objects?
in [OOP]
|
From: Veloz on 16 Jan 2008 15:15 I've done some more digging and found a couple other nuggets out there, mostly from Martin. Here's one: "We [should] create objects of the things that have behavior, not the things that carry data.." This makes sense to me on a bunch of different angles. But, then, where does that leave the modeling of the data? Does the data not deserve some representation in our application? The obvious answer is "yes", that data needs to be modeled in some way. For example, for some apps, a relational database model (and the associated classes around the database tables and entities) suffice to model the data, store it, and enforce business rules around it. But in my case, we have lots of "weird" data entities in our domain model that really don't fit well in a database. So how am I to represent this data, enforce validation and relationship rules for it, etc, except by creating classes to do so? Michael
From: Dmitry A. Kazakov on 16 Jan 2008 16:19 On Wed, 16 Jan 2008 12:15:05 -0800 (PST), Veloz wrote: > But, then, where does that leave the modeling of the data? Does the > data not deserve some representation in our application? Data are fully described/determined by the behavior of. 312 behaves as integer and is nothing beyond that. You can create such object in your head, on paper or in a program. > The obvious answer is "yes", that data needs to be modeled in some > way. The answer is "no". Data is already a model. A certain confusion may arise when that model exists outside the computational space. Like integers do. They belong to mathematics. So the type int models mathematical objects integers which in turn model something else. Data in the program are ints, not integers. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Daniel T. on 16 Jan 2008 18:47 Veloz <michaelveloz(a)gmail.com> wrote: > I've done some more digging and found a couple other nuggets out > there, mostly from Martin. > > Here's one: > > "We [should] create objects of the things that have behavior, not the > things that carry data.." > > This makes sense to me on a bunch of different angles. > > But, then, where does that leave the modeling of the data? Does the > data not deserve some representation in our application? > > The obvious answer is "yes", that data needs to be modeled in some > way. Joe has a robot with type A arms, a robot with type B arms, and a robot with type C arms. Mary has a robot that can do job X, a robot that can do job Y, and a robot that can do job Z. Now, if Joe wants to sell you a robot, you have to ask him, "but what jobs are these robots good for?" Whereas if Mary tries to sell you a robot, you don't really worry about what kind of arms they have... The data is less important than what job the class does. > So how am I to represent this data, enforce validation and > relationship rules for it, etc, except by creating classes to do so? Unfortunately, I don't know enough about your system to say...
From: Veloz on 16 Jan 2008 19:53 On Jan 16, 6:47 pm, "Daniel T." <danie...(a)earthlink.net> wrote: > Veloz <michaelve...(a)gmail.com> wrote: > > I've done some more digging and found a couple other nuggets out > > there, mostly from Martin. > > > Here's one: > > > "We [should] create objects of the things that have behavior, not the > > things that carry data.." > > > This makes sense to me on a bunch of different angles. > > > But, then, where does that leave the modeling of the data? Does the > > data not deserve some representation in our application? > > > The obvious answer is "yes", that data needs to be modeled in some > > way. > > Joe has a robot with type A arms, a robot with type B arms, and a robot > with type C arms. > > Mary has a robot that can do job X, a robot that can do job Y, and a > robot that can do job Z. > > Now, if Joe wants to sell you a robot, you have to ask him, "but what > jobs are these robots good for?" Whereas if Mary tries to sell you a > robot, you don't really worry about what kind of arms they have... > > The data is less important than what job the class does. Agreed overall. Let's say one of the functions Mary's robots know how to do is to perform some custom analysis on something known as a ZippyBook. The ZippyBook is a domain concept that somewhat mimics a real book. It can contain chapters, an index and so on. Now, it's pretty easy to conclude from past conversations that the most interesting/useful modeling will revolve around the custom analysis, because that's where the most interesting/important behaviors are. But what about modeling the ZippyBook? Mary's Robot needs to get content for ZippyBooks through a UI it must create. As it does this, it needs to enforce certain business rules about how many chapters there must be, what kind of duplicate information is allowed, certain requirements related to the items in the table of contents, validation of hyperlinks, etc. For the sake of discussion, let's say the UI is smart enough to understand what can go into a ZippyBook, and to enforce (ignoring what the UI should/shouldn't know regarding business rules). But then how are you going to store the ZippyBook in your software so that you know which chapters, table of contents, etc, go with which ZippyBook, ? That is, at some point the user of the Robot is going to want to see ZippyBooks in an expected format... and the software must know how to correctly "assemble one" And furthermore, let's say we have some code that needs to create ZippyBooks dynamically.. Who is going to validate that the ZippyBook rules are followed when creating it or populating it? And lastly, let's say some other processes need to access parts of a ZippyBook.. should these parts (chapters, table of contents) just be global variables?? It seems to me that you need an entity class known as ZippyBook which can house chapters, tables of contents, hyperlinks, whatever. And this class, having the knowledge of its own data, would also enforce the business rules as someone adds items to it, such as more chapters etc. And as other code needs items (say a chapter from a ZIppyBook) it should access the chapter through the ZippyBook. Based on this I would say that we would end up with "entity" classes in our design, which have behavior of the own (related to enforcing rules, storing the data in a representationally useful way, etc) and we would end up with objects that are more focused on algorithms and other behaviors. Yes???? :-) M > > > So how am I to represent this data, enforce validation and > > relationship rules for it, etc, except by creating classes to do so? > > Unfortunately, I don't know enough about your system to say...
From: Daniel T. on 17 Jan 2008 07:44
Veloz <michaelveloz(a)gmail.com> wrote: > "Daniel T." <danie...(a)earthlink.net> wrote: > > Veloz <michaelve...(a)gmail.com> wrote: > > > I've done some more digging and found a couple other nuggets > > > out there, mostly from Martin. > > > > > Here's one: > > > > > "We [should] create objects of the things that have behavior, > > > not the things that carry data.." > > > > > This makes sense to me on a bunch of different angles. > > > > > But, then, where does that leave the modeling of the data? > > > Does the data not deserve some representation in our > > > application? > > > > > The obvious answer is "yes", that data needs to be modeled in > > > some way. > > > > Joe has a robot with type A arms, a robot with type B arms, and a > > robot with type C arms. > > > > Mary has a robot that can do job X, a robot that can do job Y, > > and a robot that can do job Z. > > > > Now, if Joe wants to sell you a robot, you have to ask him, "but > > what jobs are these robots good for?" Whereas if Mary tries to > > sell you a robot, you don't really worry about what kind of arms > > they have... > > > > The data is less important than what job the class does. > > Agreed overall. > > Let's say one of the functions Mary's robots know how to do is to > perform some custom analysis on something known as a ZippyBook. > The ZippyBook is a domain concept that somewhat mimics a real book. > It can contain chapters, an index and so on. Now, it's pretty easy > to conclude from past conversations that the most > interesting/useful modeling will revolve around the custom > analysis, because that's where the most interesting/important > behaviors are. > [Structural analysis snipped] You have animated the robot, but not the zippy book. What does the ZippyBook do? You have expressed the entire problem as what the robot (and UI) does to/with ZippyBooks but left ZippyBooks completely inanimate. As I said before, if all you are doing is taking data, transforming it, then presenting it, then you will come up with a representational model, not an OO one. Importantly, as part of such a process you will end up with a monolithic "You" in the program. The thing that does all the data manipulation. In this case, you call it the "robot", before you called it the "application". You haven't yet undergone the paradigm shift, you haven't decentralized your thinking... The newcomer to object technology will face suggestions such as "Before you can truly be an object-oriented developer, you will have to undergo a paradigm shift." While this sounds a bit dramatic, there is a kernel of truth to the notion of a paradigm shift. The software developer needs to think in a decentralized fashion, rather than follow the typical centralized control of the structural approach. (Riel, "Object-Oriented Design Heuristics") I must say it is easier for me, I write video games for a living, lots of animated things interacting... |