robbield / patterns Goto Github PK

I like your Bike example but it doesn't follow my understanding of the State pattern.

I think the Add and Remove components is a good concept since adding some shocks to a road bike makes it a hybrid, so the state would update from RoadBikeState to HybridBikeState.

I think the example could go one step further and have a method called "NegotiatePothole()" or something that internally calls state.NegotiatePothole(). The outcome (behaviour) of this would then vary depending on the current state of the bike. E.g. if it's a mountain bike, it would ride over it, but if it was a road bike, it would crash or buckle. I think this would make the State example clearer - the Bike remains a Bike but it can be in different states and the behaviour of the bike changes depending on what state it's in.

My understanding of Flyweight is that it reuses heavy/expensive objects across multiple other objects. For example, in the bike race scenario, I think a better example of the flyweight pattern would be something like:

Competitor: A competitor has a race number, height, weight, name, and a Bike (abstract class). There will be one type of each Bike instantiated and used across the application via the Flyweight pattern.

Bike has methods like Accelerate, NegotiatePothole, Brake, etc, and properties like TopSpeed and Weight. So you could then interact with any competitor using competitor.Bike.Brake() and the braking speed would be defined by the Bike's weight and brake types.

The one part of this that I can't figure out is how the Bike is then added to the Competitor - maybe the competitor constructor has a Bike parameter?

You've already covered the immutability of the Flyweight object by using protected for the speed - would readonly be helpful here too?

There are a lot of interesting and more complex patterns listed here which might be fun to add. https://en.wikipedia.org/wiki/Software_design_pattern