Object patterns.
Abstract Factory, Builder, Factory Method, Prototype, Singleton, Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy, Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method, Visitor, RTTI Visitor, Stairway to Heaven, Polimorphic containers, Role playing.
- GOF Design Patterns
- GOF, Design Patterns: Elements of Reusable Object-Oriented Software
- Portland Pattern Repository
- Robert C. Martin's papers (Dual Interface Hierarchies, Private Interface)
- Visitor
posted by pandeypunit, 15:52 | link | comments
XP 12 Practices
Extreme Programming consists of the following 12 practices:
Essential Practices
Ken Auer and Roy Miller propose in their book ("Extreme Programming Applied", page 71), that although it is better to start with all 12 above mentioned practices, it is also feasable to start with only the following 6 practices. Ken and Roy call them essential practices.
- Planning Game
- Small Releases
- Testing
- Pair Programming
- Refactoring
- Continuous Integration
posted by pandeypunit, 13:52 | link | comments
Wednesday, November 26, 2003
Liskov Substitution Principle
Barbara Liskov first wrote the LSP as follows in 1988:
-
- What is wanted here is something like the following substitution property: If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T." - BarbaraLiskov, Data Abstraction and Hierarchy, SIGPLAN Notices, 23,5 (May, 1988).
posted by pandeypunit, 18:57 | link | comments
Principles Of XP
|
agile
|
4 October 2003
|
Every XP aficionado knows about the 4 values and 12 practices,
but how many people know about the 15 principles? I'll confess I
didn't when Kent talked about them at JAOO last week. After the talk I
asked Kent about them: "were they in the White Book". "Yes", he
replied, "cunningly hidden in a chapter called 'Basic Principles'". Fundamental Principles: - Rapid Feedback
- Assume Simplicity
- Incremental Change
- Embracing Change
- Quality Work
Further Principles: - Teach Learning
- Small Initial Investment
- Play to Win
- Concrete Experiments
- Open, honest Communication
- Work with people's
instincts - not against them - Accepted Responsibility
- Local
Adaptation - Travel Light
- Honest Measurement
At the JAOO talk, Kent talked about how principles were a step
between the universality (and vagueness) of values and the
concreteness (and dogmatism) of practices. In the White
Book he said "These principles will help us as we choose between
alternatives. We will prefer an alternative that meets the
principles more fully to one that doesn't. Each principle embodies
the values. A value may be vague. One person's simple is another
person's complex. A principle is more concrete. Either you have rapid
feedback or you don't." The principles haven't been talked about much, even by Kent. I
think that's why they aren't so well known. The values and practices
were discussed, debated, and refined on the wiki in the formative
stages of describing XP. Kent prepared the principles primarily for
the White Book. Refreshing my mind with them now, I can see why Kent wanted to
remind everyone of them at JAOO. One of the biggest issues with XP,
and indeed with any agile method, is how to do the essential local
adaptation where you alter the process to fit the local
conditions. The principles help provide some guidelines on what bits
of adaptation will work, and which go against the XP grain. They are
part of the essence of XP that every skilled XPer both knows, and
finds difficult to communicate. I'll remember to mention them
whenever I describe XP in future.
|
- www.martinfowler.com
posted by pandeypunit, 15:16 | link | comments
What is the difference between UseCases and XP's stories?
This is a common question, and not one that has a generally agreed on answer. Many people in the XP community consider stories to be a simplified form of use cases, but although I used to hold this view I see things differently now.
Use cases and stories are similar in that they are both ways to organize requirements. They are different in that they organize for different purposes. Use cases organize requirements to form a narrative of how users relate to and use a system. Hence they focus on user goals and how interacting with a system satisfies the goals. XP stories (and similar things, often called features) break requirements into chunks for planning purposes. Stories are explicitly broken down until they can be estimated as part of XP's release planning process. Because these uses of requirements are different, heuristics for good use cases and stories will differ.
The two have a complex correlation. Stories are usually more fine-grained because they have to be entirely buildable within an iteration (one or two weeks for XP). A small use case may correspond entirely to a story; however a story might be one or more scenarios in a use case, or one or more steps in a use case. A story may not even show up in a use case narrative, such as adding a new asset depreciation method to a pop up list.
Do you need to do both? As in many things, in theory you do but in practice you don't. Some teams might use use cases early on to build a narrative picture, and then break down into stories for planning. Others go direct to stories. Others might just do use cases and annotate the use case text to show what features get done when.
posted by pandeypunit, 15:03 | link | comments
Aggregation Or Composition?
aggregation (white diamond) has no semantics beyond that of a regular association. It is, as Jim Rumbaugh puts it, a modeling placebo. People can, and do, use it - but there are no standard meanings for it. So if you see it, you should inquire as to what the author means by it. I would advise not using it yourself without some form of explanation.
composition (black diamond) does carry semantics. The most particular is that an object can only be the part of one composition relationship. So even if both windows and panels can hold menu-bars, any instance of menu-bar must be only held by one whole. This isn't a constraint that you can easily express with the regular multiplicity markers.
- www.martinfowler.com
