My exploration and experimentation with design patterns has lead to this blog post.
Learning "Design patterns" will give you a shared vocabulary which can be shared and understood across other developers in a precise manner. So start thinking at "Pattern Level".
Note: I'll be updating the content in every couple of days or so. Happy learning :)
Design Principles:
1. Identify the aspects of your application that vary and separate them from what stays the same. [ Action: Take what varies and "encapsulate" so it won't affect the rest of your code. Result: Fewer unintended consequences from code changes and more flexibility in your systems.]
2. Program to interface , not an implementation. [Result: One will end up creating a set of classes whose entire reason for living is to represent "specification or behaviors", to be implemented later based on requirements. Benefit: Provides run time polymorphism.]
Note: "Program to Interface" really means "Program to Supertype".
3. Favor composition over inheritance. [Creating systems using composition gives you lot more flexibility.It can let you encapsulate a family of algorithms into their own set of classes, but it also lets you change that behavior at runtime as long as the object you're composing with implements the correct behavior interface. There are more keep looking for it's use in other design patterns].
Note: Some basics about the arrows used in the design diagram shown below.
Straight Line (bold one with -> at end) => represents "has-a" relationship.
Straight Line (bold one with -|> at end) => represents "is-a" relationship.
Dotted Lines (dotted ones) => represents "implements".
4. The power of loose Coupling. [Action: Strive for loosely coupled design between objects that interact. Result: Loosely coupled designs allow us to build flexible OO systems that can handle changes because they minimize the interdependency between objects.] {NEW CONTENT}
Design Patterns:
{NEW CONTENT}
1. The Strategy Pattern defines a family of algorithms, encapsulates each one , makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it.
2. The Observer Pattern. A broadcast class keeps track of all the objects listening to it and anytime a new piece of data comes along it sends a message to each listener. What's cool here is the fact that listeners can register/unregister dynamically anytime to the broadcast. [One-to-Many relationship]
Learning "Design patterns" will give you a shared vocabulary which can be shared and understood across other developers in a precise manner. So start thinking at "Pattern Level".
Note: I'll be updating the content in every couple of days or so. Happy learning :)
Design Principles:
1. Identify the aspects of your application that vary and separate them from what stays the same. [ Action: Take what varies and "encapsulate" so it won't affect the rest of your code. Result: Fewer unintended consequences from code changes and more flexibility in your systems.]
2. Program to interface , not an implementation. [Result: One will end up creating a set of classes whose entire reason for living is to represent "specification or behaviors", to be implemented later based on requirements. Benefit: Provides run time polymorphism.]
Note: "Program to Interface" really means "Program to Supertype".
3. Favor composition over inheritance. [Creating systems using composition gives you lot more flexibility.It can let you encapsulate a family of algorithms into their own set of classes, but it also lets you change that behavior at runtime as long as the object you're composing with implements the correct behavior interface. There are more keep looking for it's use in other design patterns].
Note: Some basics about the arrows used in the design diagram shown below.
Straight Line (bold one with -> at end) => represents "has-a" relationship.
Straight Line (bold one with -|> at end) => represents "is-a" relationship.
Dotted Lines (dotted ones) => represents "implements".
4. The power of loose Coupling. [Action: Strive for loosely coupled design between objects that interact. Result: Loosely coupled designs allow us to build flexible OO systems that can handle changes because they minimize the interdependency between objects.] {NEW CONTENT}
Design Patterns:
{NEW CONTENT}
1. The Strategy Pattern defines a family of algorithms, encapsulates each one , makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it.
2. The Observer Pattern. A broadcast class keeps track of all the objects listening to it and anytime a new piece of data comes along it sends a message to each listener. What's cool here is the fact that listeners can register/unregister dynamically anytime to the broadcast. [One-to-Many relationship]
Comments
Post a Comment