The Dependency Inversion Principle

The Dependency Inversion Principle

it should be pretty clean that reducing dependencies to concrete classes in our code is a good thing. In Face, we've got an OO design principle that formalizes this nothing; it even has a big formal name for it.. 'the Dependency Inversion Principle'.

At first, this principle sounds a lot like " program to an interface, not a implementation" right?. it is similar; however, the Dependency Inversion Principle makes an even strong statement about abstraction. It suggests that our high level components should not depend on our low level components; rather they should bother depend on abstractions.

But what the heck does that mean?

Well, let's start by looking again at the first pizza store diagram. Pizza store is our "high-level component" and the pizza implementations are our "low-level components",  and clearly the Pizza Store is dependent on the concrete pizza classes.

Now this principle tells us we should instead write our code so that we are depending on abstractions, not concrete classes. That goes for both our high level models and our low-level modules.

But how do we do this? lets think about how we'd apply this principle to our very dependent Pizza-store implementation.



Applying the principle

Now the main problem with the Very Dependent PizzaStore is that it depends on every type of pizza because it actually instantiates concrete types in its orderPizza() method.


When you directly instantiate an object, you are depending on its concrete class.
While  we've created an abstraction, Pizza we're never-less creating concrete pizzas in the code, so we don't get a lot of leverage out of this abstraction.

How can we get those instantiations out of the orderPizza method? well, as we know, the Factory Method allows us to do just that.

So after we've applied the Factory Method, our 2nd diagram looks like this:


After applying the Factory Method, you'll notice that our high-level component, the PizzaStore, and our low-level components, the pizzas, both depend on Pizza, the abstraction. Factory Method is not the only technique for adhering to the Dependency Inversion Principle, but it is one of the more powerful ones.


Where is the "inversion" in Dependency Inversion Principle?
The "inversion" in the name Dependency Inversion Principle is there because it inverts the way you typically might think about your OO design. Look at the diagram on the previous page, notice that the low-level components now depend on a higher level abstraction. Likewise, the high level component is also tied to the same abstraction. So, the top-to-bottom dependency chart we drew first,  has inverted itself, with both high level and low-levels now depending on the abstraction.




A few guidelines to help you avoid violating the principle.

• No variable should hold a reference to a concrete class.
• No class should derive from a concrete class.
• No method should override an implemented method of any of its base classes.

The Factory Method Pattern

The Factory Method Pattern

 Defined

The factory  method pattern defines an interface for creating an object, but lets subclasses decide which class to instantiate. Factory method lets a class defer instantiation to subclasses.

As with every factory, the Factory Method Pattern gives us a way to encapsulate the instantiations of concrete types. Looking at the class diagram below, you can see that the abstract Creator gives you an interface with a method for creating objects, also known as the "Factory Method". Any other methods implemented in the abstract Creator are written to operate on products produced by the the factory method. Only subscribers actually implement factory method and create products.

As in the official definition, you'll often hear developers say that Factory Method lets subclasses decide which class to instantiate. They say "decides" not because the pattern allows subclasses themselves to decide at run-time, but because the creator class in written without knowledge of the actual products that will be create, which is decided purely by the choice of the subclass that us used.

- There is more to making objects than just using the new Operator.
- Seen a similar design where a factory is defined in a static method (Static factory).  whats the difference.  advantage of static method is you don't need to instantiate an object to make use of the create method. disadvantage that you cant subclass and change the behavior of the create method.

Factories handle the details of object creation.


Use me to decouple your client code from the concrete classes you need to instantiate, or if you don't know ahead of time, all the concrete classes you are going to need. To use me just subclass me and implement factory method.

Diagrams

Bullet Points

• All factories encapsulate object creation.
• Simple Factory, while not a bonafide design pattern, is a simple way to decouple your clients from concrete classes.
• Factory Method relies on inheritance: object creation is delegated to subclasses which implement the the factory method to create objects.
• Abstract factory relies on object composition. object creation is implemented in methods exposed in the factory interface.
• All Factory Patterns promote, loose coupling by reducing the dependency of your application on  concrete classes.
• The intent of Factory Method is to allow a class to defer instantiation to subclasses.
• The intent of Abstract Factory is to create families of related objects without having to depend on concrete classes.
• Factories are a powerful technique for coding to abstractions, not concrete classes.

Decorator/Wrapper Pattern

Decorator/Wrapper Pattern

DEFINED

The decorator pattern attaches additional responsibilities to an object dynamically. Decorators provide a flexible alternative to sub-classing for extending functionality.

Problems to be solved.- the over use of inheritance, equals class explosion
- When you inherit behavior by sub classing, that behavior is set statically at compile time. in addition all subclasses must inherit the same behavior.

Extension - extends an object behavior dynamically at run time by using composition,


When learned - allow you to be able to give your (or someone else) objects new responsibilities with making code changes to the underlying classes.

Decorates your classes at run time using a form of object composition.
- extension at run-time rather then at compile time.
-While inheritance is powerful it doesn't lead to the most powerful designs.
 -

Open-Closed principle
-Goal is to allow classes to be easily extended to incorporate new behavior without modifying existing code. 

- There are ways of "inheriting" behavior at run-time through composition and
-IT is possible to add multiple new responsibility to objects, through this technique, including responsibilities that were not even thought of by the designer of the super class. and you don't have to touch their code.
-Code should be closed for modification, yet open for extension
-  Takes time and effort to make code this flexible

- must be careful when choosing the areas of code that need to be extend; applying the open-closed principle EVERYWHERE is wasteful and unnecessary and can lead to complex hard to understand code.

Diagrams

 

 Code Example

 

Bullet Points

•   Inheritance is one for of extension, but not necessarily the the way way yo achieve flexibility in out designs.
• In our designs we should allow behavior to be extended without the need to modify existing code.
• Composition and delegation can often be used to add new behaviors at run time.
• The Decorator pattern provides an alternative to sub-classing for extending behavior.
• The Decorator patten involves a set of decorator classes that are used to wrap in concrete components.
• Decorator classes mirror the type of the components they decorate. (in fact they're same type)
• Decorators change the behavior of their components by adding new functionality before and/or  after (or even place of ) method calls to the component.
• You can wrap a component with any number of decorators.
• Decorators are typically transparent to the client of the component; that is, unless the client is relying on the component’s concrete type.
• Decorators can result in many small objects in our design, and overuse can be complex

Augmented Reality

Blender character creation
Reference images
Modeling ->  Texturing ->  Rigging -> Animation

5 - toggles between orthographic mode and perspective mode
n - to bring up properties panel
t - to bring up tools panel
shift c - centre 3d cursor
shift a - add object
tab - go into edit mode (when object selected)
ctrl r - loop cut (when object selected)
z - wire frame mode (when object selected)
b - box select
a - select all
g - allows you to move object, and resize it with mouse (when object selected)
enter - confirm change
esc - cancel change

Textures -

uv mapping - flatterning object into 2d object for texturing
select edges  ( to create seams)
ctr -e - mark seams
u - unwrap



Hacking Augmented Reality with kinect
Perspective - is important - if your in the right position - to make the illusion.
Projection mapping,

roomalive tool kit - projection mapping   toolkit
-has a sample
- http://github.com/kinect/roomalivetoolkit
using projectors and Kinect - can be  many to many ...
https://www.youtube.com/watch?v=hUAyZP5MA3Y

Observer Pattern

 Observer pattern

 

Defined

The Observer Pattern defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.

When you're trying to picture the Observer Pattern, a newspaper subscription service with its publishers and subscribers is a good way to visualize the pattern.

In the real world however, you'll typically see the Observer Pattern defined like this.

The subject (the observed object) and the observers define the one to many relationship.
The observers are dependent on the subject such that when the subjects state changes, the observers are updated with new values.

 Strive for Loose coupled design between objects that interact.

Loose coupling is an approach to interconnecting the components in a system or network so that those components, also called elements, depend on each other to the least extent practicable. Coupling refers to the degree of direct knowledge that one element has of another.

The goal of a loose coupling architecture is to reduce the risk that a change made within one element will create unanticipated changes within other elements.Don't wish to code concrete update method implementations, as we have to way of add or remove without making changes to the program.

Diagrams

 

Code Example

 




 

 

Bullet Points

• The Observer Pattern defines a one to many relationship between objects.
• Subjects, or as we also know them, Observables, update Observers using common interface.
• Observers are loosely coupled in that the Observable knows nothing about them, other than that they implement the observer Interface.
• You can push or pull data from the Observable when using the pattern (pull us considered correct)
• Dont depend on a specific order of notification for your observers.

Deisgn Patterns Principles

Design Patterns Principles

Design Principles List

• Identify the aspects of your application that vary and separate them from what stays the same.
• Program to an interface, not an implementation
• Favor composition over inheritance. (Has-a instead of Is-a)
• Strive for loosely coupled design between objects that interact. (minimal interdependency on other objects)
• Classes should be open for extension, but closed for modification. that is, such an entity can allow its behavior to be extended without modifying its source code.
• Depend upon abstractions. Do not depend on concrete classes.
•  Principle of least knowledge - talk only to your immediate friends.

 Bullet Points

• Knowing the OO basics does not make you a good OO designer 
• Good OO designs are reusable, Extensible and maintainable.
• Patterns re proven object orientated experience.
• Patterns don't give you code, they give you general solutions to design problems.
• Patterns aren't invented, they are discovered 
• Most patterns principles address issues of change in software
• Most patterns allow some part of a system to vary interdependently of all other parts.
• We often try to take what varies and encapsulate it
• Patterns provide a shared language that can maximize the value of your communication with other developers.

Strategy pattern

Strategy pattern 

Defined

Defines a family of algorithms, encapsulates each one, and makes them interchangeable.
The Strategy Pattern lets the algorithm vary independently from clients that use it,

Use when client of inherited base class may have varying behaviors and dependent of scenario you may want to use one or the other interchangeably.

Identify the aspects of your application that vary and separate them from what stays the same.
Take what varies and "encapsulate" it so it wont affect the rest of your code.

Diagrams

Code Example

i.e a CARs Exhaust Noise varys dependent of what type of Car your driving



interface IExhaustNoiseBehavior()
{
   private string noise;

    public string Noise()
}

class SportsCarExhaustNoiseBehavior :  IExhaustNoise
{
    private string noise = "brrrrm"
 
    public string Noise
    {
      return noise;
     }
}


public class Car
{
    IExhaustNoiseBehavior exhaustNoiseBehavior
      public performExhaustNoise() {  return ExhaustNoiseBehavior.Noise };

}

public class  Ferrari : Car
{

     IExhaustNoise ExhaustNoise
 
      public Ferrari ( IExhaustNoise exhaustNoiseBehavior)
      {
         ExhaustNoise =  new SportsCarExhaustNoiseBehavior();
       }
}

Bullet Points

defines a family of algorithms,

encapsulates each algorithm, and

makes the algorithms interchangeable within that family