The Type Hint Tight Couple

Anybody who does object oriented development quickly learns about type hinting - the process by which you can indicate to one object another object it should expect. Remember this example from the last post?

<?php
class MyClass() {
  public function __construct(MyObject $mobj) {
    $this->myObject = $mobj;
  }
}

But type hinting alone is not sufficient to loosely couple our objects. In fact, even though we are injecting our dependency in the initial example, we're type hinting on a concrete object, meaning that we are tied to that specific object for all future iterations. Sure, we can mock it for testing (which is an advantage), but we can't easily subclass it and use it elsewhere.

Fixing the Type Hint Tight Couple
It's easy to fix this particular tight coupling problem. To do so, we can draw back on our knowledge of SOLID principles, namely the Dependency Inversion Principle, which states:

Objects should rely upon abstractions, not concretions.

Fixing this tight couple requires only that we abstract the creation of the interface from the implementation of the object, and then type hint on it. For example:

<?php
interface MyObjectInterface {
  // some methods to define interface in here
}
class MyObject implements MyObjectInterface{
  // The implementation of the interface
}
class MyClass{
  public function __construct(MyObjectInterface $mobj){
    $this->myObject = $mobj;
  }
}

So, here instead of relying solely upon MyObject to type hint, we can now type hint on the interface, MyObjectInterface. This loosely couples our objects, because MyClass no longer cares about the implementation of MyObject; it only cares about knowing the right interface!

So, do all my objects need interfaces?
In short, no, they don't. The illustration I've provided is for objects that might have reuse potential later on, or are part of a library; when you're working with specific objects that are unlikely to change, there may not be a need for this level of decoupling.

Remember, the principles of object oriented design (like loose coupling) are about offering best case solutions, not final solutions or absolute hard-and-fast rules. It's up to you, the designer, to make good choices.

Tight coupling in OOP

What Is Tight Coupling?
It would help to define exactly what the problem is, in order to solve it.

Tight coupling, in object oriented application, is an abnormal dependency between two unrelated objects. This usually manifests itself in a few different ways; today we're going to talk about the first type: the object creation tight couple.

The Object Creation Tight Couple
Have you ever seen or written code like this?

<?php
class MyClass(){
  public function __construct(){
    $this->myObject = new MyObject();
  }
}

We've all probably observed this. Even if it's in another method besides the constructor, we've all seen code that creates other objects. The culprit here is the new keyword. This keyword creates an object, but the creation of an object tightly couples one object to another. It's impossible to easily swap one object for another.

Solving The Object Creation Tight Couple
There are a few easy ways to solve this particular type of problem. The first is with dependency injection. Dependency injection is the process of inserting an object at runtime, rather than creating it in an object, and looks like this:

<?php
class MyClass(){
  public function __construct(MyObject $mobj){
    $this->myObject = $mobj;
  }
}

With this approach, we are injecting the object, which makes it possible to swap the object out with a mock object for testing or another object to modify the application. But this isn't the only way we can solve this problem.

We can also use a factory to create the object we need at run time, but abstract the creation to another object or group of objects (like the Abstract Factory pattern). Using a factory looks like this:

<?php
class MyClass(){
  public function __construct(MyObjectFactory $mobj){
    $this->myObject = $mobj->getInstance();
  }
}

Now, the real power of this isn't shown in the constructor; it's shown when the getInstance() method is used in a method that requires it. But, you can easily see the power of the factory here to create an object on demand, yet still follow the best practices of dependency injection and testability.

5 Ecommerce Metrics You Should Be Tracking

When it comes to ecommerce analytics, business owners and marketing managers typically focus on metrics like conversion rates, number of transactions, and average order value.

These are valuable, and should be monitored. After all, measuring such outcomes is what directly impacts revenue and the bottom line.

Thanks to Google Analytics as well as Mixpanel, Flurry, Site Catalyst, and other analytics platforms, these ecommerce metrics are readily available to site owners.

While focusing on the outcomes is key, close attention to tracking user behavior and interaction with the site or mobile app will also yield significant incremental improvements. Here are five interactions you don’t see a lot of people measuring, when they really should be.

Product Categories
You can easily report on top products, what’s selling, and what’s not selling on your website. However, go beyond that and consider rolling up your reports to the product category level. Some categories can be driving more revenue than others..

Product Comparison
Many ecommerce sites allow shoppers to list products next to each other for ease of comparison — dimensions, features, pricing, and other features — and also for an opportunity to upsell the higher value products.

Live Chat Tracking
You have probably seen live chat features on sites more often than not. You come to a site to check out a service or a product and you’ll see an invitation — sometimes a pop-up — asking if you would like to chat with a customer support agent. I’ve seen ecommerce businesses where the average order value is 25 to 30 percent higher when a purchase included a live chat.

Shopping Cart Removes

While it’s common to measure “Add to Cart” clicks to track which products are added to the online shopping cart and track based on where that action occurred — whether they are on the product page, promo page, or a product modal — it’s also useful to also track cart removes, or the products that visitors added to cart and then later removed.

Know Your User Segments

Real gems are found in zooming in on a segment of users along with the purpose of their visits. If you are new to the concept of segmentation, write down the various types of customers that buy from you.

For example, you might be primarily a consumer product store, but also have a reseller or a distribution channel. These resellers are identified upon login and your system will present the pricing and discounts that are unique to them. When tracking transactions and revenue, it’s important to segment your reports by these user types. Otherwise a large order at a highly discounted price for one of your resellers will skew your revenue and conversion data.

Source: http://www.practicalecommerce.com/articles/4137-5-Ecommerce-Metrics-You-Should-Be-Tracking