If a class assumes more than one responsibility, then there will be more than one reason for it to change.http://www.objectmentor.com/resources/articles/srp.pdf
Tuesday, May 29, 2012
Why SRP?
Mixins vs. OO
[M]ixins are a type of inheritance ... Inheritance is fundamentally at odds with encapsulation, the addition of capabilities to objects with a single line quickly muddle the responsibilities of classes, and mixins themselves aren’t even the best option for code reuse across classes.http://justinleitgeb.com/2012/05/moving-beyond-mixins/
Friday, May 25, 2012
DCI Presentation
"A use case is not an algorithm because a use case can be non-deterministic"
"DCI is really about capturing the algorithms in a framework that reflects the use cases"
"Good objects are dumb, not smart...and that's probably against what your professors told you"
"One of the important things about your grandfather's object-oriented programming is that you couldn't reason about the state of the system. You could only reason about the state of an object. "
"TDD is about the state of an object that has no business value"
"Keep use-cases goal driven, and use habits for these things at a lower level [i.e. the 'include's of use cases]"
"A withdrawal is a fairly complex business practice. It doesn't belong in a dumb object [e.g. savings account - re: decreaseBalance vs. withdraw]"
"Customer says, 'I want this account to pay all my bills'. Ok, well define some roles from the use-case 'pay all bills' and will inject the right parts of this use case into this class [savings account] at run time to make it do what it needs to do. And then we don't have to worry about this dumb domain class. That can remain relatively stable. Good design is about separating what is stable from what changes. "
"'transfer funds' is a use-case. How do I represent use-cases, well, as a context"
"All [the context 'execute' method] does is say source account.transfer to, and the rest just happens because all the wiring has been done here [context initialization], we just go to the first role in the use-case, initiate it with an event, and the rest just happens. This 'execute' in context is a way of stacking the context. Contexts stack. ... I can call a context. This is a way of reusing use-cases or really, re-using habits, where I can build a context that represents a habit, and call it from another use case. "
re: "chunking," " It might be nice to have this full use-case laid out before you, but you couldn't understand that anyhow. We understand things by well ... two different cognitive tools. One is divide and conquer (or partitioning) and the other is compression, and we need both; and so this notion of context is the way of doing divide and conquer, of splitting things up into units of use cases that we can understand. Roles are a further chunking of functionality ... "
"I said that an account is an object right? I lied. ... what are the objects in a bank, are they accounts? what are the objects? transaction logs, audit trails. What is the balance on your account? It's the iteration over an audit trail, adding up all the deposits and subtracting all of the withdrawals. Your balance isn't sitting on a disk somewhere, it's computed, it's a use case! An account isn't an object. The account ID might be an object, but the account is an active thing -- in your terms a business process. ... What is an account in DCI, because if it's an object, then its a domain object and has to be smart; and we don't like smart domain objects, they don't evolve well. ... It it part of the user mental model? Of course. We talk about accounts, so it must be a thing if we're doing object-oriented programming which is capturing the end-user model in the code, then it [the account] should kind of fly like an object, quack like an object, and walk like an object. Well what is it? It's a context [ see also how inbox is a context, i.e. InboxContext]. What is a context? A context is a use-case. Well can we make a context to be a collection of related scenarios that involve a certain set of roles? What is a collection of related potential scenarios between an end-user and system under construction? That's a use case. And we reflect it in DCI as a context object. "
"Roles ... have the algorithms in them but they really don't have state. Most roles in DCI are stateless. They are pure algorithm. The state has to be remembered in the domain objects. And each role works with one ore more contexts or gets injected into some domain object, so that contexts can organize their bindings and kick off new executions as events come in. But it turns out that contexts [ points to blue ball on path between role and domain object pink ball] ... can behave like domain objects, like...savings account does. It's not an object, it is a collection of interactions between roles around a set of scenarios [see 'scenario' in BDD] that we call use-cases. And so this kind of solves a very very very longstanding problem in object-orientation, 'cuz everyone wants to make an account an object, and it really isn't. And there's all kinds of problems with the lifetime of these ideas if you treat them as objects. It's the algorithms of the account that are long-lived, and the identity of the account. The account identity may be a long-lived object, but not the account. Things like the account balance are very ephemeral. So they're computations. We now have architectural home for these computations that you don't find in most object-oriented methods.
"I said that domain models should be dumb. Do I have any rules for saying what things should go there and what things don't. It has to do with this concept of shear layers [layers of maintenance frequency, see house architecture] and understanding how stable are things. And so you go to something like Eric Evans book on domain driven design, and you look for the things that are stable. Those are the things that I want in my domain model. If things are going to be part of things I sell to the business that are going to be more dynamic, I want those in the roles [above]. So ... another way of looking at it; it's a dichotomy of what the system is and what the system does. So the domain model, the dumb dumb dumb classes down there are what the system is, so a system is transaction logs, audit trails, what it does is transfer money and pay bills. ... [explains how 'domain model' or 'data model' is the D in DCI and M in MVC]... This is the programmers side of MVC MVC is the end-user's side to get their mental model lined up; [DCI] is getting the programmer's mental model lined up. Same model, same 'M'.
James O. Coplien
http://vimeo.com/8235574
"DCI is really about capturing the algorithms in a framework that reflects the use cases"
"Good objects are dumb, not smart...and that's probably against what your professors told you"
"One of the important things about your grandfather's object-oriented programming is that you couldn't reason about the state of the system. You could only reason about the state of an object. "
"TDD is about the state of an object that has no business value"
"Keep use-cases goal driven, and use habits for these things at a lower level [i.e. the 'include's of use cases]"
"A withdrawal is a fairly complex business practice. It doesn't belong in a dumb object [e.g. savings account - re: decreaseBalance vs. withdraw]"
"Customer says, 'I want this account to pay all my bills'. Ok, well define some roles from the use-case 'pay all bills' and will inject the right parts of this use case into this class [savings account] at run time to make it do what it needs to do. And then we don't have to worry about this dumb domain class. That can remain relatively stable. Good design is about separating what is stable from what changes. "
"'transfer funds' is a use-case. How do I represent use-cases, well, as a context"
"All [the context 'execute' method] does is say source account.transfer to, and the rest just happens because all the wiring has been done here [context initialization], we just go to the first role in the use-case, initiate it with an event, and the rest just happens. This 'execute' in context is a way of stacking the context. Contexts stack. ... I can call a context. This is a way of reusing use-cases or really, re-using habits, where I can build a context that represents a habit, and call it from another use case. "
re: "chunking," " It might be nice to have this full use-case laid out before you, but you couldn't understand that anyhow. We understand things by well ... two different cognitive tools. One is divide and conquer (or partitioning) and the other is compression, and we need both; and so this notion of context is the way of doing divide and conquer, of splitting things up into units of use cases that we can understand. Roles are a further chunking of functionality ... "
"I said that an account is an object right? I lied. ... what are the objects in a bank, are they accounts? what are the objects? transaction logs, audit trails. What is the balance on your account? It's the iteration over an audit trail, adding up all the deposits and subtracting all of the withdrawals. Your balance isn't sitting on a disk somewhere, it's computed, it's a use case! An account isn't an object. The account ID might be an object, but the account is an active thing -- in your terms a business process. ... What is an account in DCI, because if it's an object, then its a domain object and has to be smart; and we don't like smart domain objects, they don't evolve well. ... It it part of the user mental model? Of course. We talk about accounts, so it must be a thing if we're doing object-oriented programming which is capturing the end-user model in the code, then it [the account] should kind of fly like an object, quack like an object, and walk like an object. Well what is it? It's a context [ see also how inbox is a context, i.e. InboxContext]. What is a context? A context is a use-case. Well can we make a context to be a collection of related scenarios that involve a certain set of roles? What is a collection of related potential scenarios between an end-user and system under construction? That's a use case. And we reflect it in DCI as a context object. "
"Roles ... have the algorithms in them but they really don't have state. Most roles in DCI are stateless. They are pure algorithm. The state has to be remembered in the domain objects. And each role works with one ore more contexts or gets injected into some domain object, so that contexts can organize their bindings and kick off new executions as events come in. But it turns out that contexts [ points to blue ball on path between role and domain object pink ball] ... can behave like domain objects, like...savings account does. It's not an object, it is a collection of interactions between roles around a set of scenarios [see 'scenario' in BDD] that we call use-cases. And so this kind of solves a very very very longstanding problem in object-orientation, 'cuz everyone wants to make an account an object, and it really isn't. And there's all kinds of problems with the lifetime of these ideas if you treat them as objects. It's the algorithms of the account that are long-lived, and the identity of the account. The account identity may be a long-lived object, but not the account. Things like the account balance are very ephemeral. So they're computations. We now have architectural home for these computations that you don't find in most object-oriented methods.
"I said that domain models should be dumb. Do I have any rules for saying what things should go there and what things don't. It has to do with this concept of shear layers [layers of maintenance frequency, see house architecture] and understanding how stable are things. And so you go to something like Eric Evans book on domain driven design, and you look for the things that are stable. Those are the things that I want in my domain model. If things are going to be part of things I sell to the business that are going to be more dynamic, I want those in the roles [above]. So ... another way of looking at it; it's a dichotomy of what the system is and what the system does. So the domain model, the dumb dumb dumb classes down there are what the system is, so a system is transaction logs, audit trails, what it does is transfer money and pay bills. ... [explains how 'domain model' or 'data model' is the D in DCI and M in MVC]... This is the programmers side of MVC MVC is the end-user's side to get their mental model lined up; [DCI] is getting the programmer's mental model lined up. Same model, same 'M'.
James O. Coplien
http://vimeo.com/8235574
Algorithms in DCI
The passive objects are the Data in DCI, and the active objects are the algorithms that coordinate and manipulate the passive objects. ...
...there needs to be a few application-specific things: the trigger for a spell checking use case, the context in which the use case executes (the casting or wiring up of the actors to play different roles), and the code for the use case itself.
http://pettermahlen.com/2010/09/10/dci-architecture-good-not-great-or-both/
SRP killed OOP?
Without taking into account the basics of what an object’s responsibilities are one could follow SRP to the demise of their object oriented code and easily end up with procedural code and many do.http://codebetter.com/gregyoung/2010/03/24/the-98th-thing-every-programmer-should-know/
Thursday, May 24, 2012
Compiler vs. Unit Test Feedback
The benefit of unit testing is that it provides us with faster feedback than integration testing or systems testing would do. That's all fine, but the compiler provides even faster feedback, so why should I resort to unit testing if the compiler can give me feedback sooner?
Thursday, May 10, 2012
Use Cases - Poor Modeling Tool
Use-case driven analysis leads to poor object modelling in my experience. My position on this is that use-cases should be used to validate the object model, not to identify it.
http://blog.nakedobjects.org/2007/11/19/workflow-a-triumph-of-hope-over-experience/
Windows vs. Web Apps
The system should be responsive, with no delays between execution andhttp://hci.ucsd.edu/hollan/direct-manip.pdf
the results, except where those delays are appropriate for the knowledge
domain itself.
Linguistic Determinism
... the notion of linguistic determinism ... the way we think about something is shaped by the vocabulary we have for talking about it .... changing the users’ conception of the domain mayhttp://hci.ucsd.edu/hollan/direct-manip.pdf
prevent some intentions from arising at all.
Coarse-grained vs. Fine-grained
Coarse-grained components exhibit loose coupling, whereas fine-grained components are often tightly coupled. For example, if recompiling both the consumer and the provider resolve some problem in the interaction, then the two components were tightly coupled.http://www.ibm.com/developerworks/webservices/library/ws-soa-granularity/
Wednesday, May 9, 2012
Naked Objects or MVC
The belief that views should be independent of objects is just a self-fulfilling prophecy.http://blog.nakedobjects.org/2007/10/25/user-interfaces-the-enemy-of-domain-driven-design/
Sunday, May 6, 2012
Law of Demeter
When applied to object-oriented programs, the Law of Demeter can be more precisely called the “Law of Demeter for Functions/Methods” (LoD-F). In this case, an object A can request a service (call a method) of an object instance B, but object A cannot "reach through" object B to access yet another object, C, to request its services. Doing so would mean that object A implicitly requires greater knowledge of object B's internal structure. Instead, B's interface should be modified if necessary so it can directly serve object A's request, propagating it to any relevant subcomponents. Alternatively, A might have a direct reference to object C and make the request directly to that. If the law is followed, only object B knows its own internal structure.http://en.wikipedia.org/wiki/Law_of_Demeter
Bounded Contexts
People are talking about two entirely different things when they chat about a policy in the context of a general workflow versus a policy in the context of payroll auditing. If you use the same policy class, you're fattening the profile of that class and getting a long way from tried-and-true best practices such as the Single Responsibility Principle (SRP).
Systems that fail to isolate and insulate Bounded Contexts often slip into an architectural style (amusingly) called The Big Ball of Mud. ...
When you use modules (or namespaces) to divide up your model, you really want to question whether you're dealing with a separate context. The cost of cleaving out another context is usually much higher: now you have two models, likely in two assemblies, that you need to connect with application services, controllers, and so on.
Tuesday, May 1, 2012
Subscribe to:
Posts (Atom)