Principle Of Least Knowledge Principle

 Principle of least knowledge - talk only to your immediate friends.

 When you are designing a system, for any object, be careful of the number of classes it interacts with and also how it comes to interact with those classes.

This principle prevents use from creating designs that have a larger number of classes coupled together so that changes in one part of the system cascade to other parts. When you build a lot of dependencies between many classes, you are building a fragile system that will be costly to maintain and complex for others to understand.

How do we do this?
The principle tells us tat we need to make sure that we only invoke methods that belong to.

• The object itself
• Objects passed in as a parameter to the method
• Any object the method creates or instantiates
• Any components of the object.

This sounds kind of stringent doesn't it? whats the harm in calling the method of an object we get back from another call? Well, if we were to do that, then we'd be making a request of another objects sub-part (an increasing the number of object we directly know). In such cases, the principle forces use to ask the object to make the request for us; that way we don't have to know about its component object (and we keep out circle of friends small). for example:

Here's a car class that demonstrates all the ways you can call methods and still adhere to the Principle of Least Knowledge;

 

Open-Closed Principle

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.

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.

Loosely Coupled Principle

Strive for loosely coupled design between objects that interact. (minimal interdependency on other objects)

Loose coupling is an approach to interconnect 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. Limiting interconnections can help isolate problems when things go wrong and simplify testing, maintenance and troubleshooting procedures.

-------------------

For example, the Observer pattern provides an object design where the subject(observable) and the observer are loosely coupled.

The only thing the subject knows about the observer is that it implements a certain interface. (the observer interface). it doesn't need to know the concrete class of the observer, what it does or anything else about it.

We can add new observers at any time, because the only thing the subject depends on is a list of objects that implement the observer interface, we can add new observers whenever we want. In face, we can replace any observer at run-time with another observer and the subject will keep purring along. Likewise, we can remove observers at any time.

We never need to modify the subject to add new types of observers. Lets say we have a new concrete class come along that needs to be an observer. We don't need to make any changes to the subject to accommodate the new class type, all we have to do is implement the observer interface in the new class and register as observer. The subject doesn't care; it will deliver notifications to any object that implements the Observer interface.

We can re-use subjects or observers independently of each other. If we have another use for a subject or an observer, we can easily reuse them because the two aren't tightly coupled.

Changes to either the subject or an observer will not affect the other. Because the two are loosely coupled, we are free to make changes to either, as long as the object still meet their obligations to implement the subject or observer interfaces.

Loosely coupled designs allow use to build flexible OO systems that can hand change because they minimize the inter-dependency between objects.

Favor Composition Over Inheritance Principe

Favor composition over inheritance. (Has-a instead of Is-a)

HAS-A can be better than IS-A
Creating systems using composition gives you more flexibility. Not only does it let you encapsulate a family of algorithms into their own set of classes, but it also lets you change behavior at run-time as long as the object you're composing with implements the correct behavior interface. 

Composition is used in many design patterns. 

Program to an interface/abstract class, not an implementation Principle

  Program to an interface/abstract class , not an implementation

The goal here is to keep things flexible, as if things are inflexible, then were going to get into trouble further down the road, especially when we try to extend the application.
The  point here is to exploit polymorphism  by programing to a super-type (interface/abstract class) so that the actual run-time object isn't locked into the code. and we could rephrase "program to a super-type" as "the declared type of the variables should be a super-type, usually an abstract class or interface, so that objects assigned to those variables can be be of any concrete implementation of the super-type,  means the class declaring them doesn't have to know about the actual object types".

 

Encapsulate what varies principle

Identify the aspects of your application that vary and separate them from what stays the same.

 In other words, if you've got some aspect of your code that is changing, say with every new requirement, then you know you've got a behavior that needs to be pulled out and separated from all the stuff that doesn't changes.

Here's another way of thinking about it, take the parts that vary and encapsulate them, so that later you can alter or extend the parts that vary without affecting those that don't

As simple as this concept is, it forms the basis of every design pattern. 

i.e if you have a car base class in a game, and notice that each cars exhaust will make a different noise.

encapsulate this behavior by extracting it out of car class, and class abstract compose an IexhaustNoise interface that exposes a ExhaustNoise() method.

The Facade Pattern

Facade Pattern

 - In this post we are going to look at a pattern that alters an interface, to simplify the interface. Its aptly named the Facade Pattern because this pattern hides all the complexity of one or more classes behind a clean, well lit facade.

Defined

-The Facade Pattern provides a unified interface to a set of interfaces in a subsystem. Facade defines a higher level interface that makes the subsystem easier to use.

Diagrams

 

Bullet Points

• When you need to simplify and unify a large interface or complex set of interfaces, use a Facade.
• A Facade decouples a client from a complex subsystem
• Implementing a Facade requires that we compose the facade with its subsystem and use delegation to perform the work of the Facade.
• You  can implement more then one Facade per subsystem

 

The Adapter Patterm

The Adapter Pattern

Defined

The Adapter Pattern converts the interface of a class into another interface the clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.

Diagrams

Despite having defined the pattern, there are actually two kinds of adapters: Object adapters and Class adapters.

 Object Adapter:

Class Adapter:
- Can only be use in multiple inheritance languages
- The only difference is that with class adapter we subclass the Target and the Adaptee, while with object adapter we use composition to pass request to an Adaptee.

Code Example

 

Bullet Points

•  When you need to use an existing class and its interface is not the one you need, use an adapter.
• An adapter changes an interface into one the client expects.
• Implementing an adapter may require little work or a great deal of work depending on the size of the target interface.
• There are two forms of the Adapter Patter: Object and class. Class adapters require multiple inheritance.
• An adapter wraps an object to change its interface.  a decorator wraps an object to add new behaviors and responsibilities and a facade wraps a set of objects to simplify.
  

 

The Command Pattern

The Command Pattern

Defined

 The Command Pattern encapsulates a request as an object, thereby letting you parametrize other objects with different requests, ques or log request and support undo-able operations.

- A command object encapsulates a request, by binding together a set of actions on a specific receiver. To achieve this, it packages the actions and the receiver up into an object that exposes just one method, execute(). When called, execute() causes the actions to be invoked on the receiver,From the outside, no other objects really know what actions get performed on what receiver, they just know that if they call the execute method their request will be serviced.

Diagrams

Code Examples

Macro Commands
- A Kind of command that can execute other commands... and more then one of them.

Bullet Points

• The Command Pattern decouples an object, making a request from the one that knows how to perform it.
• A Command object is at the center of this decoupling and encapsulates a receiver with an action (or set of actions).
• An invoker makes a request of a Command object by calling its execute() method, which invokes those actions on the receiver.
•  Invokers can be parametrized with Commands, even dynamically at run-time.
• Commands may support undo by implementing an undo method that restores the object to its previous state before the execute() method was last called.
• Macro Commands are a simple extension of Command that allow multiple commands to be invoked. likewise Macro Commands can easily support undo().
• In practice, it is not uncommon for "smart" Command Objects to implement the request themselves rather than delegating to a receiver.
• Commands may also be used to implement logging and transaction systems.

The Singleton Pattern

The Singleton Pattern

 

Defined

The Singleton Pattern ensures a class has only one instance, and provides a global point to access it.

Types of objects that we would only need one of : Drivers, registry settings. objects that handle preferences.

Ie.  A Kinect Device Manager object should be a singleton, because a Kinect application should be restricted to only having one open connection to a Kinect Device.

Diagrams

 

Code Example

CODE DISSECTION

 

                   Code Solution- to prevent two instances being created on different threads.

Bullet Points

• The Singleton Pattern ensures you have at most one instance of a class in your application
• The Singleton Pattern also provides a global access point to that instance. 
• Java's implementation of the Singleton Pattern makes use of a private constructor, a static method combined with a static variable.
• Examine your performance and resource constraints and carefully choose an appropriate Singleton implementation for multi-threaded applications (and we should consider all applications multi-threaded)

The Abstract Factory Pattern

The Abstract Factory Pattern

Defined

The Abstract Factory Pattern  provides an interface for creating families of related or dependent objects without specified their concrete classes.

Diagrams

Use whenever you have families of products you need to create and you want to make sure your clients create products that belong together.

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.
• Fa

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