"Code must be Chunkable"
in [Ruby]
|
From: James Coplien on 17 Feb 2010 12:33 Thomas Sawyer wrote: > Hi James, > > Honestly, James, I didn't even think about contacting you --I didn't > even suspect I'd be getting this deep into a conversation about it. The I'm happy to offer a revelation in your mindset. And welcome to the Internet world. > However, while your example gave me at > least something to go on, the presentation as a whole left me more > confused and thus less enthusiastic about the whole DCI idea. That is in fact probably good! That is what should be happening as you make a paradigm shift. Expect to be confused and surprised. I'll come back to this notion throughout the mail. My example didn't only extemporize on Trygve's, but went into some new territory. And I think some people got lost there. I know this sounds like rationalization, but in fact, most of my teaching the past thirty years has involved some kind of paradigm shift, and I am attentive to the need of this puzzlement. If you read "Zen and the art of motorcycle maintenance," Pirsig calls it "stuckness." Learning new things is not always a linear process. > I apologize for compacting this opinion into the one word "awful", I > suppose that is too disparaging a term, and for that I apologize. So > please accept this explanation in it's place and take it for what it's > worth. You can call me whatever you want to my face, and in this discussion, I hope you do, you ignoramous :-) I am more hurt by the fact that you might have seized an opportunity for dialog and learning but instead cast aspersions mumbling in a corner somewhere. I feel hurt on behalf of the community. We need your criticism — but in dialog. >> Words mean things, and use case is not just Swedish for scenario. > > The definition seems fine. I just don't see why logging-in can't be > viewed as a goal in itself. As most use case experts would describe it, you don't go home at the end of the day and tell your daughter, "Guess what I did today! I got logged in!" Logging in isn't essential to the value chain. The goals in goal-driven use cases drive towards such goals. To focus on things at this level is noise. Alistair Cockburn's "Effective Use Cases" offers the theory and practice of this perspective in a very satisfying way. Give it a read and come back and we can discuss it more. >> > He's splitting hairs over words and as much as he thinks DCI is >> > so cool, I'm not sure he actually "gets it" himself. >> >> Can you translate that into some delineated professional feedback? > > Ok. This is my take. DCI seems to me like an idea with a lot of > potential. But I don't think it's an all of nothing kind of thing. No one is saying that it is! There is still a place for your grandfather's object-oriented programming. There are architectures we can call event-driven architectures, where the interesting operations are all atomic. A shapes editor is a good example. It in fact has no use cases. Most operations are atomic and trivial: "Change the color of this shape." "Resize this shape." "Create this shape." Once in a great while you might have operations involving multiple methods of multiple shapes, and that's where DCI comes in. More broadly, not everything is object-oriented, whether DCI or your grandfather's object-oriented design. Procedural design still has a place. So do state machines — and that has nothing to do with objects (for example, in protocol design). So does rule-based computation. So does functional programming as in SASL or KRC. Anyone who attacks the world with one weapon alone will be defeated. I wrote a whole book on this several years ago called "Multi-paradigm design. Why did you think I felt that DCI was the only way? > get the feeling that you so badly want DCI to be a Major Paradigm > Shift that you might be pushing it's concepts too far. Given that it took me seven years to learn it, I can speak strongly for the fact that it is a paradigm shift. That it is a paradigm shift has nothing to do with its payoff — only with the mode of understanding. You may be seeing some of my pedagogical techniques that are commonly used to extemporize new ideas. There are important ways of giving emphasis in a one-hour presentation that would not arise if we were pairing at a keyboard. > For instance, to say that an account is not a not object... going all > the way back to the bad old days of COBOL, an account has always been > treated as as object, even if not coded in OOP form. I don't think so. Have you ever worked in finance or banking? I think your statement holds true only in lectures by college professors or by people outside of finance. In the latter case, the object isn't the account, but the name of the account (sometimes called its account number). Can you give me a single example in the software of a real financial institution where the balance is actually stored as a data member of an object in memory? After you answer that, we can discuss the difference between object-oriented programming and class-oriented programming. One of the major features of DCI is that it supports object-oriented programming. Very few languages support object-oriented programming directly: they support class-oriented programming instead. > That's because > banks treat accounts as objects --people have them, they have ID > numbers, etc. You are perhaps suffering from being trapped in the old paradigm, where everything must be an object. Stick with me here for a few paragraphs as I explore this. You would have been an excellent student of Kant. In fact, if you look at people's mental models of their worlds, they think of much more than objects. An ID number is not an object: it is a handle to an object. An account is not an object: it is a role that several objects together can play. Do the following experiment. Go to someone who has recently done a money transfer in their bank. Ask them to give you a general user story for it. Inevitably, I find people saying, "I decide on an amount, and then I witdraw that money from one account and put it into another account." If they speak more precisely they will use terms like "source account" and "destination account." A "source account" is not an object. It is a role that something can play (like a savings account). For the time being we can pretend that savings account is a class whose objects can play the role of "source account." That fits the simple Kantian model of the world, where most things must be objects. But if we go more deeply, to the level of that domain (in the sense of DDD) we find that it is not an object — certainly not in the "D" sense of "Data" in DCI. It is a collection of use cases, of behaviors. That makes it a DCI context. An account is a context (like an account number) in which we can carry out algorithms (like transferring money) with other concepts (like other accounts, or transaction logs, or audit trails). Where I think you are confused is that you take these elements of your mental model and call them objects. That was also what Kant does. To do so is at least not useful, and probably isn't even right. Also part of your mental model is the mapping from the roles "source account" and "destination account" onto their respective accounts (my savings account #O991540 and my investment account #393497654). Also part of your mental model is those things called accounts, and you think of them as objects. The problem is that the people who implement those systems don't implement them as objects, but as something else — the objects are at a much lower level. That's the real world of real financial software today. Really. At least in my example — which I think is representative. If you have a different example where an account can be an object in memory, I find that interesting, but I don't think it's germane to this discussion. One reason I can justify DCI as a paradigm shift is that it differently translates the mental models of end users and programmers into code. Something called object-oriented programming was one way of doing it in the 1980s. This is another way of doing it, with different elements of the model. And these elements don't come out of thin air. Rebecca Wirfs-Brock and Trygve were having a discussion on the Hurtigruten about ten years ago as I was listening, and they concluded that objects don't have responsibilities — roles do. That is the essence of CRC cards. Most people think that CRC stands for "Class, Responsibility, and Collaborator." It does not. Rebecca wanted to call them RRR cards (Roles, Responsibilities and Relationships) but the C really stuck. What it really means is "candidate object," and it's a role. (I just verified this with her when she and I went together to dinner with Trygve and Gertrud at Øredev last year.) So you have an entire industry focusing on classes because they misunderstood an acronym (or popularizers of the technique misunderstood it – I won't mention any names). Focus on roles — the roles that objects can play — not classes. There are other ideas I could bring to bear from the field of user experience, from Brenda Laurel's writings, and from other staples of object-orientation that the Java-duped public doesn't read, but take my word for it. This is not the object-orientation you learned in college. > Then please make it available! It's there (somewhere) on object-composition (are you subscribed?); it appears in its entirety in the book I have coming out in June (there are several drafts scattered here and there on the web). Part of understanding a new paradigm is going beyond a one-hour talk to do your homework. Read the Artima article. There are three or four articles you should probably read at Trygve's web site. If you're really interested, come to the next course I offer on it. Just for you, I'll give you a free seat. > Please don't feel that I am criticizing *you* --take it for what it > is, my personal critique of *your presentation*. Likewise, I am not criticising your understanding, but how you channeled the criticism. >> If you feel the Ruby style bears improvement I am open to suggestions. > > I can can certainly offer some suggestions, but I would have to > understand DCI better to go beyond the surface. I suspected as much. My guess is that your sense of distaste in the code may also owe to being stuck in the old paradigm. >> > (P.S. I also think this is much more like AOP then Coplien is willing >> > to admit.) >> >> Second, I'd like to know why; and first, I'd like to know why it's >> important. Again, I think you are making the mistake that another poster >> here warns about: confusing the language mechanisms with the design >> ideas. > > The goal of AOP is to come at a problem orthogonal to the traditional > OOP direction. In AOP you are organizing code into aspects. These > aspects are like contexts in DCI. Aspects are composed of advice, code > injected into classes/objects by wrapping other methods. > There are clear similarities. DCI goes a bit further by injecting > methods whole-clothe, and in doing so decomposes "aspects" into a > context and set of roles. (Actually that might be useful, might DCI > roles make use of AOP's concept of advice too?) No, because it makes the aspectualized code unreadable. As to why DCI is more than AOP, read my above long segment on mental models and paradigms. DCI is not just a programming trick to reflect cross-cutting. It can represent much higher dimensions of cross-cutting than AOP can and, because of the Contextual mapping of roles to objects, is much more dynamic. They are barely in the same league. I think you are confusing one of the mechanisms of Aspects with one common mechanism used to implement DCI in some programming languages. This, too, is the sign of a new paradigm: everyone tries to describe it in terms of what they know. Some people say that DCI is like mixins. Some say it is like multi-paradigm design. Some say it is like aspects, some like dependency injection, and a million other things. What gives me the most grief is that there is a tiny bit of truth in each of these claims, just enough to keep people from making the necessary mental leap. To do that requires digging into it and trying it. It is like learning a martial art: no number of PowerPoint slides will get you there. You have to feel it in your bones. Most people don't even "get" object-oriented programming in their bones. And this transition scares programmers because their identity is so tied up in understanding new technology. That leads people to do really amusing things. For example, someone may not yet understand DCI well enough even to give suggestions on how to clean up Ruby code that illustrates it, yet feels qualified to criticize one of its inventors as "not getting it." O, how human we can be... But back to the point... The real goal of AOP (I have this from Gregor Kiczales personally) is to shock people into taking reflection seriously. It was supposed to scare people from Java back into Lisp, where you can express these things cleanly. Cutpoints and wrappers and whoppers are native to CLOS, for example. The problem is that people weren't shocked: they embraced the scaffolding. I view this as one of the best examples of the sheep-like stupidity of the industry, collectively. I'm going to get back to my vacation and attacking the fjelds of Norway. Med venlig Hilsen, Cope -- Posted via http://www.ruby-forum.com/.
From: Marnen Laibow-Koser on 17 Feb 2010 14:53 James Coplien wrote: [...] >> For instance, to say that an account is not a not object... going all >> the way back to the bad old days of COBOL, an account has always been >> treated as as object, even if not coded in OOP form. > > I don't think so. Have you ever worked in finance or banking? I think > your statement holds true only in lectures by college professors or by > people outside of finance. In the latter case, the object isn't the > account, but the name of the account (sometimes called its account > number). Can you give me a single example in the software of a real > financial institution where the balance is actually stored as a data > member of an object in memory? I have yet to watch your presentation (though I am very much looking forward to doing so), and I know that you and Trygve generally know what you're talking about. So I may be a fool rushing in where angels fear to tread. But... I cannot imagine *not* representing a bank account as an object in a bank software system. The balance is part of such an object's state. > > After you answer that, we can discuss the difference between > object-oriented programming and class-oriented programming. One of the > major features of DCI is that it supports object-oriented programming. > Very few languages support object-oriented programming directly: they > support class-oriented programming instead. Often quite true. > > >> That's because >> banks treat accounts as objects --people have them, they have ID >> numbers, etc. > > You are perhaps suffering from being trapped in the old paradigm, where > everything must be an object. Stick with me here for a few paragraphs as > I explore this. You would have been an excellent student of Kant. In > fact, if you look at people's mental models of their worlds, they think > of much more than objects. An ID number is not an object: it is a handle > to an object. Agreed. > An account is not an object: it is a role that several > objects together can play. Not necessarily agreed. In the example below, you're talking about accounts as objects while claiming you're not doing so. > > Do the following experiment. Go to someone who has recently done a money > transfer in their bank. Ask them to give you a general user story for > it. Inevitably, I find people saying, "I decide on an amount, and then I > witdraw that money from one account and put it into another account." If > they speak more precisely they will use terms like "source account" and > "destination account." A "source account" is not an object. It is a role > that something can play (like a savings account). I believe that you're getting trapped by ambiguous language here. A "source account" is not an object, to be sure, but that doesn't mean an *account* isn't an object. "Source account" and "destination account" are roles, but only accounts (or objects that behave like accounts) can play those roles, it seems to me. In Ruby: def transfer(source, destination, amount) ... end peter = Account.find(:peter) paul = Account.find(:paul) Now we have handles to Peter's account and Paul's account. Of course we don't have the accounts themselves, but we have object representations of them. Now we can do transfer(peter, paul, 100) in which case peter plays the role of source account or we can do transfer(paul, peter, 100) in which case paul plays the role of source account. Where's the problem here? > > For the time being we can pretend that savings account is a class whose > objects can play the role of "source account." That fits the simple > Kantian model of the world, where most things must be objects. But if we > go more deeply, to the level of that domain (in the sense of DDD) we > find that it is not an object — certainly not in the "D" sense of "Data" > in DCI. It is a collection of use cases, of behaviors. The point of a "traditional" object, it seems to me, is that it unifies data and behavior in one package. DCI may be a valid form of analysis, orthogonal to "traditional" object analysis, but that doesn't mean that objects revealed by traditional object analysis (such as the Account instances in your example) aren't objects. Best, -- Marnen Laibow-Koser http://www.marnen.org marnen(a)marnen.org -- Posted via http://www.ruby-forum.com/.
From: James Coplien on 17 Feb 2010 17:01 Marnen Laibow-Koser wrote: > James Coplien wrote: > [...] > I cannot imagine *not* representing a bank account as an object in a > bank software system. The balance is part of such an object's state. No. In every example I've seen, financial records are kept as audit trails that track deposits, withdrawals, interest accruals, etc. There is no "balance" sitting on a disk nor sitting in memory. The balance is computed as the sum of accruals, less the sum of decreases, against some baseline. All these data are in a database — but no balance. Let me reiterate my question, which yet goes unanswered here: Can you name me one, real, concrete system in real use, in a real financial institution, where the account is an object, and its field is a balance, within a system that manages the account itself? > Not necessarily agreed. In the example below, you're talking about > accounts as objects while claiming you're not doing so. I start talking about them as objects as a way to introduce the concept. Then I move to the real design to introduce how Contexts can replace objects in some contexts. > I believe that you're getting trapped by ambiguous language here. A > "source account" is not an object, to be sure, but that doesn't mean an > *account* isn't an object. "Source account" and "destination account" > are roles, but only accounts (or objects that behave like accounts) can > play those roles, it seems to me. I agree that this is an issue of misunderstanding. Your code example has nothing to do with the point I'm making. Think of the point I'm making as having to do with the psychology of perception (which is what Dahl and Nygård viewed OO as being all about in the end). In your example, peter is a name for an identifier which contains a reference (an address, another kind of name) of something called an account. That it can be an object in Ruby doesn't mean that it properly reflects the proper mental model. For example, I can also do this in Ruby: def account (account_id, amount) . . . . end So what? And I have the same "so what" reaction to your code. I agree with your above analysis that accounts, or objects that behave like accounts, can play these roles. Can my phone bill play the role of an acccount? If it does, is it an account in the banking sense? Of course not. But I can transfer money to it — because it can play the role of a source account. So it *can* be a data object. My point is that it doesn't have to be, and that in fact, very few accounts are. They rather are Contexts than Data objects. This facet of the underpinnings of DCI is not about language expression, but of about how we think. That's the paradigm shift part. -- Posted via http://www.ruby-forum.com/.
From: Marnen Laibow-Koser on 17 Feb 2010 18:08 Thanks for replying! I've probably injected myself into a debate that's a bit over my head, but that's how learning happens. James Coplien wrote: > Marnen Laibow-Koser wrote: >> James Coplien wrote: >> [...] > >> I cannot imagine *not* representing a bank account as an object in a >> bank software system. The balance is part of such an object's state. > > No. In every example I've seen, financial records are kept as audit > trails that track deposits, withdrawals, interest accruals, etc. There > is no "balance" sitting on a disk nor sitting in memory. The balance is > computed as the sum of accruals, less the sum of decreases, against some > baseline. All these data are in a database — but no balance. That's implementation. It is irrelevant to interface, no? > > Let me reiterate my question, which yet goes unanswered here: Can you > name me one, real, concrete system in real use, in a real financial > institution, where the account is an object, and its field is a balance, > within a system that manages the account itself? First, your question probably goes unanswered because the only people who could answer it are people who've worked on the proprietary systems in question. I have the impression that not much financial software is open source. Second, it's irrelevant whether balance is a field or a calculation, at least if the uniform access principle is still to hold. As a hypothetical user of class Account, I want to be able to call Account#balance and get a balance. I don't care in the least what has to go on to get me that balance. > > >> Not necessarily agreed. In the example below, you're talking about >> accounts as objects while claiming you're not doing so. > > I start talking about them as objects as a way to introduce the concept. > Then I move to the real design to introduce how Contexts can replace > objects in some contexts. OK. > > > >> I believe that you're getting trapped by ambiguous language here. A >> "source account" is not an object, to be sure, but that doesn't mean an >> *account* isn't an object. "Source account" and "destination account" >> are roles, but only accounts (or objects that behave like accounts) can >> play those roles, it seems to me. > > > I agree that this is an issue of misunderstanding. Your code example has > nothing to do with the point I'm making. Think of the point I'm making > as having to do with the psychology of perception (which is what Dahl > and Nygård viewed OO as being all about in the end). In your example, > peter is a name for an identifier which contains a reference (an > address, another kind of name) of something called an account. So far so good. > That it > can be an object in Ruby doesn't mean that it properly reflects the > proper mental model. I think of an account as being an object. Doesn't that make it the proper mental model for me? > For example, I can also do this in Ruby: > > def account (account_id, amount) > . . . . > end > > So what? I don't get your point here at all. Please elaborate. > And I have the same "so what" reaction to your code. > Why? > I agree with your above analysis that accounts, or objects that behave > like accounts, can play these roles. Can my phone bill play the role of > an acccount? If it does, is it an account in the banking sense? Of > course not. But I can transfer money to it — because it can play the > role of a source account. So it *can* be a data object. Uh, what? You can't transfer money to your phone bill. You can transfer money to your account at the phone company -- and you can do so precisely because it is (or behaves like) an account. > My point is that > it doesn't have to be, and that in fact, very few accounts are. They > rather are Contexts than Data objects. And I really don't see where you come to that conclusion. > > This facet of the underpinnings of DCI is not about language expression, > but of about how we think. That's the paradigm shift part. Yes, but I so far do not agree with your premises here, which means I can't agree with the paradigm that develops from them. I'm certainly willing to be convinced, though. Best, -- Marnen Laibow-Koser marnen(a)marnen.org http://www.marnen.org -- Posted via http://www.ruby-forum.com/.
From: James Coplien on 19 Feb 2010 12:20
Let me respond to bits of Marnen's excellent post at a time. Marnen Laibow-Koser wrote: > Thanks for replying! I've probably injected myself into a debate that's > a bit over my head, but that's how learning happens. For all of us > James Coplien wrote: >> Marnen Laibow-Koser wrote: >>> James Coplien wrote: >>> [...] >> >>> I cannot imagine *not* representing a bank account as an object in a >>> bank software system. The balance is part of such an object's state. >> >> No. In every example I've seen, financial records are kept as audit >> trails that track deposits, withdrawals, interest accruals, etc. There >> is no "balance" sitting on a disk nor sitting in memory. The balance is >> computed as the sum of accruals, less the sum of decreases, against some >> baseline. All these data are in a database — but no balance. > > That's implementation. It is irrelevant to interface, no? It affects the internal form of the system. That form is called its architecture: the parts and their relationships. Those parts have interfaces, and the way we think about them affects the way they are implemented in the code. For example, if we implement a bank system in terms of incremental audit trails and dynamic association between those elements and roles that appear in dynamically created account Contexts, it's a much different design than if an Account is a data object. It shows through. Kent Beck has long argued that you can't hide a bad design behind a good interface. Brenda Laurel emphasizes the importance of the direct manipulation metaphor. Alan Kay talks about these objects as extensions of the images of your own mind. That is what DCI is trying to do. More to the point, the way that the market thinks about them (the stakeholders) affects their rates of change. Much of design is about eliciting change points so that frequently changing stuff is easy to change, is localized, and is separated from the stuff that doesn't change so much. That isn't all in the interface, unfortunately. In fact, it is often just the opposite. Most of the interface of a Prius car is the same as that for an ordinary gasoline-powered automobile, but the internal architecture is radically different. >> Let me reiterate my question, which yet goes unanswered here: Can you >> name me one, real, concrete system in real use, in a real financial >> institution, where the account is an object, and its field is a balance, >> within a system that manages the account itself? > > First, your question probably goes unanswered because the only people > who could answer it are people who've worked on the proprietary systems > in question. I have the impression that not much financial software is > open source. O.K., well, I can speak for what I have seen in Saxo Bank, in Swiss Bank Chicago, in Swiss Bank London, in Allianz, in a large Danish pension company and in many other discussions with financial people at conferences. Even Ron Jeffries' XP book features a user story that describes an account balance in these terms. If you have done your domain analysis, these things are obvious to someone in the business. Another obvious failure is that people designing a telecom system thinking that a phone call is an object. It isn't an object in any phone system I've seen. I've seen many inside AT&T and Western Electric, and publications from Bell Northern Research / Nortel indicate that also avoid this failure mode. The same was true at Avaya, AGCS, ... shall I go on? The problem is that objects became really popular in the industry in about 1990 and now everything that is a Thing has to be an object. The naivté was fueled by early methodologists who told us a number of silly things: everything is an object; objects should be created in isolation; objects are the nouns in your requirements document; and so forth. And so we have a claim here about accounts being objects, unsubstantiated in reality, but based in such an overwhelmingly strong mythology that it prompts multiple denials about the claim of how real systems implement this. It is a matter of maturity. It is easy to stumble into a great tool like Ruby and to look for ways to apply its class facilities to everything in site. But there are much more subtle structures at work here. What's really cool about Ruby is that rises even to this challenge. (Most languages can express DCI concepts in some degree. There's only one popular language that can't, and I'll let you figure that out. Class, that's your homework assignment for tomorrow.) The popular, naive claim doesn't work in practice — which is why you don't see it in practice. Let's contemplate your account example with a balance as a member. What is the object's scope? Its lifetime? How many of these objects exist in a banking system? How is concurrency handled (that's the killer): when the actuaries and account holder and the bank want to access it at the same time? What is the scope and duration of a transaction in terms of the object? If you have transaction semantics (and all banks do, to avoid losing money under concurrency) what is the mapping from the object model to the transactional model and the relational model that usually supports it? Remember: Ontos and its cousins were largely failures, because they tried to stay in the paradigm of your grandfather's object-oriented architecture. The complexity just got out of hand. DCI actually offers reasonable answers to all of these questions, because it's rooted in structures that can capture and express higher levels of complexity, both static and dynamic, than a POJO approach can. I think that's what got this thread started: I described a solution to a problem that is more complex than people can conceptualize using their grandfather's object-oriented programming, and understanding broke down. I think that people fail to understand it's a paradigm shift — but that's maybe a liability of taking one's understanding from a few hours of videotapes. > Second, it's irrelevant whether balance is a field or a calculation, at > least if the uniform access principle is still to hold. That claim holds only within a single contextual thread. Another set of immature foundations can be found in the Agile world where we are supposed to be focused on the customer. And most of the naive claims about accounts here come from that perspective. I can just read the user stories and use those to drive my design, using TDD or something else. Just find all the elements of all the interfaces and just organize them. The fact is that most of the computation in a bank has nothing to do with someone who has an account, but who is in the back office managing investments or doing analyses. They're called actuaries in English. Actuaries care little about the status of your bank account. They care about the transactions. There are many other sets of users who are looking at these data: auditors, tellers, ATM machines, other banks, the national bank, investors, loan officers, bank executives. All you need to do is to take all the responsibilities of all those stakeholders and divide them up into nice interfaces that give you nice objects that have nice coupling and cohesion. It's intractably complex. DDD has recently drawn attention to the importance of unearthing domain concepts that are stable over time. They have little to do with the requirements of the stakeholders. Very few people understand that. The "dumb" data objects of DCI come from this domain analysis; they are often the model objects one finds in MVC. The intelligence that serves the actuaries, the accountants, the loan officers and everyone else play out in use cases that are defined in terms of roles — roles that are mapped onto the right domain objects at the right time by the right context. The essence of an object-oriented system is that the mappings from roles to objects changes thousands or millions of times a second. Your grandfather's OO simulated a very weak version of that called inclusion polymorphism. The DCI mapping brings these dynamics to the surface. > As a > hypothetical user of class Account, I want to be able to call > Account#balance and get a balance. I don't care in the least what has > to go on to get me that balance. So you don't care about its data. It is essentially a service, a computation. We collect those services together in DCI and call them Contexts. You instead are trying to convince me that they should be objects. O.K., a Context is an object by some definition, and if that's enough for us to agree, then we agree. But it is not a domain object — that creates an architecture where the pressure points of change are all in the wrong place. A simple domain analysis of a financial application will bear that out quickly. More to the point, it is useful to distinguish between objects (as Dahl or Nygaard would recognize them) and the roles that they play. If programming language is to be about intentionality (communicating the design intent of the programmer) then we want the programming formalisms to carry this distinction forward. That's what DCI is: a set of formalisms that carry archetypical elements of human cognition and machine computation forward into the code. Calling it an object is a little like calling it a thing. I want a little more insight from these labels. > I think of an account as being an object. Doesn't that make it the > proper mental model for me? No, you're a programmer. And that's O.K.: programmers are people, too, and we need to support ehir model. But, again, object orientation is all about capturing mental models in code, and we need to be attentive to stakeholders other than the programmer. Like Raskin said: The interface is the program. A user experience person would pursue this issue using the kind of question I posed in an earlier post, leading to the description (e.g., for a money transfer) that I think about things in terms of source accounts and destination accounts. Unfortunately, my bank doesn't have source accounts. I can conceptualize a source account, but can't create one, can't open one, can't find one. They're not *objects*. They're protocols, or interfaces to objects. They're roles. Those, too, are part of our mental models. And they should be part of the code as well. If you look at where Rebecca Wirfs-Brock has taken responsibility-driven design, it is into this realm of roles. Objects don't have responsibilities; their roles do. That was the conversation that Trygve and I recall from his discussion with Rebecca on the deck of the Hurtigruten all those years ago. There are some additional concepts that we should be attentive to as well, including algorithms and the associations from roles to objects. DCI packages most of these in roles and Contexts. If all you have learned is objects, then everything to you is an object. That is whey I said you might make a good student of Kant. A good exploration of end-user mental models shows that they are much more subtle. Introducing roles provides a much better match for this model and provides a much better foundation for good software structure than the pure object approach does. Trygve published some preliminary metrics about this on object-composition, and you might have a look at them and at the surrounding discussion. > Uh, what? You can't transfer money to your phone bill. You can > transfer money to your account at the phone company -- and you can do so > precisely because it is (or behaves like) an account. No, the entity I manipulate on my web page is exactly my phone bill. (Denmark has an advanced banking system, so maybe those of you in other countries still do this with checks to the phone company and so forth — but even for one of my accounts outside Europe, I can treat the phone bill as an entity.) That's my mental model. It's not that I'm paying the phone company; I pay my phone bill. No one says at the end of the month "I need to pay my phone company." They say "I need to pay my phone bill." >> My point is that >> it doesn't have to be, and that in fact, very few accounts are. They >> rather are Contexts than Data objects. > > And I really don't see where you come to that conclusion. > >> >> This facet of the underpinnings of DCI is not about language expression, >> but of about how we think. That's the paradigm shift part. > > Yes, but I so far do not agree with your premises here, which means I > can't agree with the paradigm that develops from them. I'm certainly > willing to be convinced, though. I'm still awaiting concrete examples that are different than those banking examples that provide much of the background for my premises. In any case, it shouldn't matter if you are trying to understand. Adopt my assumptions arbitrarily if it helps you see the ideas more clearly and I can provide the documentation later. I think that if you explore the real world you'll see that my assumptions hold. I hope this helps. I really appreciate your specific and forceful questions — I think it helps me communicate my ideas more concretely. -- Posted via http://www.ruby-forum.com/. |