Coupling and Cohesion

As an overview, those two words are the top players in a game where you play with lots of OO cookies, if you can manage those two bad boys, you practically can get rid of all of your books about OO design. And yes, if you could compress all those book in to two little simple word it would be coupling and cohession.

it's about flexibility, reusability, extensibility, maintainability, portability, and so on, when you learn or use patterns, they all come down to these words, so what is coupling and cohession, really ?

coupling is about how much dependency between two separate module, the higher the worst it get. why is high coupling is bad ?, because when two seperate module is too dependent with one another, it would be difficult to modify them, imagine if module A depends on module B, and B on C, and C on D, if you try to modify A, you'll end up modifying most(if not all) other module, its a domino effect, one down, and everything else is just a matter of time.

While cohession is about how solid your module are, solid here means it does one thing it and it's very good at doing it, the higher the better it get, why is low cohesion is bad?, if you make a module that do stuff too much, you'll end up damping lots of logic in one place, which is bad because if any of those logic change, you might breaking other logic that sits in the same module. This is where the separation concern comes in, each module should only have one responsibility, if you have more than one reason to change a module, there is a big chance that module has low cohesion,

Ironic it is, but as you can guess, those two words are complementary, if you strive for one you'll get kick by another. for example if you want to make your module to have high cohession, you'll tend to squeeze it as much as possible, and by the end of the day that module will need to communicate to many other module to accomplish a bigger task, and then you'll realize that you had a high coupling. In other hand if you want to make less chit chat between modules, you'll end up with one big chunk of module which mean it has low cohession.

A good design is a harmonic balance between coupling and cohession.

whhatt is that? how you do "harmonic balance" ? how much is high, and how less is low? well I cant really tell as I'm still learning, but one thing I can tell is that a harmonic balance is not a 50:50 share, it depends on a dozen of variable, necessity, point of view, probability of change, difficulty, scenario of use, etc.. sometime you get to sacrifice one for another, and sometime we just can't figure it out...

State Pattern Add-on thought

Just a note from my gumball's little thought.., for the next text, I'll use gumball machine as a case study (you might wanna read headfirst design-pattern first)

assume that you already met with state pattern, or better, you've implement it!
context class:
is a class of an object that may have many different state.
state class :
is a class contains spesific behaviour for each state an object can have.

• if the transition is dynamic (depend on some condition/value), then it is more apropriate if the transition placed on the state classes, this way we have decide that we'll close the context class for modification,
  
• if the transition is static (for every spesific event, always change to some other state), then it is more apropriate to place the transition logic on context, this way we have decide that we'll close the state class for modification
  
• between state classes should dependent or coupled ?
  
  • if we decide to have transition controlled by state class(dynamic transition) then we cant avoid the coupling between state classes,
    
  • if we decide to have transition controlled in context, we can try to make those state classes more independent
    
• the way I see it, when we choose which class should be close for modification, the context or the state, is a matter of state capability(intelligence), if we decide the transition logic to be placed in state classes then we have made our state class more "intelligent", and so vice versa. Personally I'd chose the former (for now), yes we'd sacrifice the low-coupling between state classes, but it'll make the context a lot more solid, and as the definition of state pattern is to group behaviour into a spesific class based on it's internal state, my point of view is that state transition is also part of context's behaviour --CMIIW--
  
• if you do have some conditional check, make sure that the checks on each state are specific, remove all redundant checks, because every check should be done on responsible state
  for example:
  
  • there's no need to check whether gumball still available on StateHasCoin, because we are certain that the gumball is surely available in StateHasCoin, if it is not available, then our machine would have gone straight to SoldOut state, without going through NoCoin and HasCoin state (imposible paths)
    
• it is best to have exception mechanism, because for every event there can be many current state method invocation(many line), which on every line the currentstate may have change to a different state class,
  so the idea is that exception will stop execution of state method on relevant state, it help to track the system state easily when the error happens.
  for example:

<?php
//if the current state is no_coin
public function pullLeverEventHandler() {
   /*
   * we still on no_coin,
   * below line tells that we cant pull lever
   * because we havent inserted any coin
   */
   this->getState()->pullLever();
   /*
   * we still on no_coin,
   * below line tells that we cant dispense
   * because it is invalid event for current state
   */
   this->getState()->dispense();
}
?>

we have two error up there, so the question is...

• which of em should be displayed? one or all of em ?
  
• the order of the message ? ( invalid event, you haven't insert coin) or (you havent insert coin, invalid event) etc..

solutions: use exceptions, it will halt on first state method invocation, then it will make more sense, --CMIIW--

please throw me an argument :p ...

MVC

one of the most popular architecture to be used in web development is MVC, yes because the simplicity of it's design which concentrate on how to separate responsibility between each logical part of the system, makes it easy to develop a system in the scale of enterprises. There are three main part of the system that implement MVC design.

Model, why didnt they call it VCM, or CVM, or VMC, etc.. why model first? in my perspective its because the whole thing that make our application work as expected is in the Model, this is our business logic lies, most people prefer it as domain model, this is where we'd play so many entity/business objects based on it's business rules in conjunction to the model functionality. A good model is a coherent one, which concentrate on specific functionality of system. MVC doesn't say much bout statefullnes of model, but in my experiences almost all of my model is statefull, meaning that it store information about what its doing now, what it have done before, and (probably) where it'll going.. -CMIIW-

Controller, most of the time controller is smaller than model or view, why? because its sole responsibility is to do simple validation on the request, determine what model should serve that request, load up the model, and hand off everything to the presentation layer(view) to render the result. Even though, it doesn't mean it will be simpler than any other part, and if you just start learning, theres a big probability that you'll mixed up with controller concept in event-driven-programming(I'll write about it later..), this part doesnt have logic in them, but depends on its design it may have to acquire some knowledge bout list of available views and models. There are several pattern to implement a Controller, some of them are Front Controller pattern, and Page controller pattern, Front controller is widely used by most of GUI framework these days where theres only a single controller to handle every request. And Page controller is a basic concept of controller in most of web application even those that didn't use MVC architecture.

VIEW, finally this is the part where all eyes will look(literally). it can be simple, but it can be even more complicated than model, depends on what kind of application we're tryin to make. personally i get frustated with this part a lot, well I'm no designer :). The idea is factor out gui-unrelated code as much as possible from it, so the change from the view will hardly effecting the model/business model, but the change from model may still affecting the view(think about it..).

well, thats about 13minutes typing on the fly, and I'm sure there are lot of typo there. Its based on what I've done before and frankly I'm still in learning, just writing it down as is, and in the future I'd know what i've been missing :)