On Jan 1, 2008 1:48 PM, Francis Hwang <[EMAIL PROTECTED]> wrote: > > On Dec 31, 2007, at 1:10 PM, Zach Dennis wrote: > > I don't think it is "designing less" either. It's designing better > > and doing it smarter, knowing that you'll never fully comprehend > > the domain of your problem upfront, so you discover it, > > iteratively. As you discover more about the domain the design of > > your program changes (during refactoring) to support a domain model > > to which it is representing. > > > > This is a concept from Domain Driven Design. > > > > It Francis is referring to doing less upfront design to try to > > master it all from the outset, then I agree that less of that is > > better. But that is entirely different then just doing less design. > > I'm not certain how much we're genuinely disagreeing here and how > much we're talking past each other -- I'm certainly feeling like I'm > not communicating my amorphous ideas very well.
I think I understand what you are trying to get across. That is why I've communicated back what I think you have said (or at least what I think you mean) in each of my responses, hopefully clarifying my position (in both agreement and disagreement) to something more specific, since phrases like "designing less" can be taken in several ways and carry several different meanings. I'd much rather discuss a particular aspect of "designing less" where it is advantageous or not. > One thing that seems fuzzy to me is the implied time frames here. Let > me ask you this, Zach: Is it your aim that your released code always > contains a set of classes whose interactions with other classes is > well-structured and defined, through mocks, and other tools? It is my aim that objects, their responsibilities and their interactions are purposefully structured and defined. For me, this is through the iterative process of adding features to the system in a TDD/BDD manner. Since I test drive feature implementation I have explicitly made a decision to create a new object, add a new responsibility to an existing object, or move responsibilities from one object to another. Mocks are simply a tool that I use to help me discover interfaces and objects. They also help me express the coordination and interaction between objects which fulfill an application requirement, and they provide the added benefit of testing objects in isolation without the unnecessary complexity of testing objects throughout the test suite (which I believe strict state based testing of everything does). I do not use any tool primarily for the sake of designing a well-structured class taxonomy or detailed system design. No all encompassing UML diagrams or oodles of documentation. I strive for the domain driven design principle of having the domain model in the code accurately reflect the domain you are solving a problem for. > And is > it your belief that you can always seek to release code which > embodies a precise understanding of the domain in question? I believe you can always seek to release code which is an accurate reflection of the domain you are solving a problem for. I do not believe that the code itself will be a precise understanding of the domain in question. The features you implement will be solving a specific problem in a given domain. What is required to implement those features are only part of the domain. Ideally, what is implemented is only "precise" enough to satisfy the feature requirement. A lot of parts of the domain will be missing. Initially, the understanding of the domain may be fuzzy at best. But you start with a single feature to implement and you begin modeling the domain within your codebase for only what is required to implement that feature. You may only end up with a couple of objects; hardly a "precise" or perfect understanding of the domain at large, but as more features are added and time passes you get a better grasp of the domain. As you implement more features you will most likely discover new objects and responsibilities. This may entail extracting behavior from existing objects onto a new object because it better reflects what is required in the domain or it may promote single responsibility or separation of concerns and the concept of simple objects. The whole process though is something that is learned, continually and incrementally. I don't stop development of a feature because I am not an expert of the domain I am working in. I have to understand what is required to implement a particular feature or solve a particular problem anyways -- so I try to understand how the business expert or customer understands it and I try to keep that understanding consistent within the codebase. Specifically the domain objects in the application. I agree with a lot of the concepts behind domain driven design and how it works with agile (specifically XP in my case) development. It has created simpler code, easier to understand and maintain code and better test suites for apps that I've worked on. > I suppose part of what I'm saying is that sometimes, for non- > programmer reasons, the domain itself is too fuzzy or too quickly > shifting to try to nail down with a well-structured design. Sometimes > you just release code that amorphously hints at a future design -- > and in those cases, a strong test suite is what prevents you from > shooting yourself in the foot. > I agree that the domains in which we are implementing features and solving problems for are largely fuzzy. This is why it is so important to have business experts and real users apart of the development process. Sometimes it's not always possible to have direct access when you need it or your customer is venturing into new territory and they are trying to figure things out as they go as well. This is why it's so important to have a clean code base which reflects the domain because when that shifts we know what has to shift in our code. For me well-structured is a relative term. It shifts with each feature I add, remove or change in the system. After I complete a feature I want the codebase to be a coherent reflection of the features it includes. Over time the system is going to change and evolve, and parts and pieces are going to be added or thrown away. My implementation may not always be the best possible but it will be the best I could do at a given time. And it will always strive for simplicity over complexity and it will have a strong test suite. This is probably a longer reply then you were looking for.. hopefully thats alright. ;) -- Zach Dennis http://www.continuousthinking.com _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
