Do you still use JavaScript?!

Do you use JavaScript and still write your CODE in Javascript?

There are 3 answers really..

  • “yes I code in JavaScript, I’m not aware of CoffeeScript yet..”
    …so now you know, go and try next answer
  • “yes I code in JavaScript, though I am aware of CoffeeScript”
    • … maybe you “fear of the unknown“? I was for few months and regret now. Do not hesitate and learn CoffeeScript now, try it, spike, really.. use it
    • or you think JavaScript is still better…
      do you?.. really? .. but are you sure?
      … good luck! Because it’s only luck that you need now
  • “no, JavaScript is unmaintainable, I love CoffeeScript”
    .. and that’s good…
    .. CoffeeScript code is clean and elegant ..
    .. you can at last do Object Oriented programming without hacks…
    .. your code is readable
    .. and hence prone to less bugs.. or bugs are easier to find..
    .. and you can run it in the browser the same way as plain old javascript..

View is thin, dumb and a servant of domain model.. not the other way

I’ve came across this twice lately…

Two independent developers were trying to explain to me why their model is not readable (and maintenable) and doesn’t reflect real domain. Objects were wrongly associated together, and real world classes – were missing and not defined!

The wrong explanation of a dev was:

..because, a user using “admin UI” selects a card text and assigns bunch of NUMBERS (cell ids) it appears on .. No need for “board cell class”

Who cares how an user is using an app.. It should not have any, or minimal impact on how business domain is modelled, even db is designed..
Should it be a browser, a console app, fully dynamic Ajax website or an iPad app.. It’s only how the app looks, and how presents its information about data.

Views change, user preference change. View is a thin layer, only a presenter. Should not drive the design of domain layer.

An app was…

…I was looking at how some game was designed, a board game, and it was missing representation of a BoardCell

In this small OO world:

  • a game has a board
  • a board contains many board cells (hexes)
  • a board cell contains many cards, of which some give special powers

So I was expecting at least this below: (you can copy&run example)..
…But what I found something different


I need real world model, close to business, close to the domain. I want ALL THE REAL CLASSES BE THERE. So I can touch them and work on them.

So, try to cut any class from above code. It will make no sense, as all the objects make sense there. It’s the pure model.

Now, based on this code you CAN start building views. Views may or may not present all the data. May only show final bonus of a player, of a whole board.. who cares.. that is what is view for.. to present, not to define!

Try to imagine your view changes, what then.. would you really want to have model not being a mirror of a real world, and change both: the view, the model … thought so :-) So don’t



My Law #2: Business Logic .. and forming Use Cases

As far as I remember I was always very eager on trying to transform natural world – it’s behaviour and information – into a computer. I always wanted to achieve two things:

  • tell the computer how real world is modelled
  • tell it in a way that a human can read and understand it

So the effect is

Implementing Business Logic of a domain is the most important and funny part to do

It has many impacts

  • what is the model?
  • what are the classes and how they look?
  • how to persist data to a storage?
  • how to deliver data to an app user and how to interact with the code
  • where business logic should be implemented
So I always wanted to be closer to the model part more than to other. It looked easy at first to create a Player class, it’s behaviour and data. And I was implementing high level business operations into the model, not the controllers layer nor the view.
class Player
  constructor: (@name, @age) ->

  throw_a_dice: () =>

  pick_a_card: () =>
.. but something was missing.. I discovered it just lately thanks to friends and possibly by waking up from a long 4-year hibernation that I was missing a representation of use cases in the system. TA daAA!

It is very important to split your models into at least 2 parts, maybe even 3.

  • “use cases”: a part where high level use cases, scenarios, algorithms, business logic is implemented (SelectingFirstPlayer, RollingADice, MakingAMove, PlayingMonopolyGame, ..)
  • “base models”: a part where base classes are implemented with their basic methods attributes that can be reused in use cases (Game, Board, Player, Pawn, Dice, Move, ..)
  • “storage”: a storage part (maybe, if it’s configuration would be too tight into base model classes, that it needs a separation)
It’s so obvious a use case must have a shape in the system somehow

I’m not yet sure what should be the scope of a use case. Using an example of a popular Monopoly board game, should a use case be “playing monopoly board game”, or only “throwing a dice and making a move”..

But I’m pretty sure all use cases must have a form in the system by being at least a class, that has this single responsibility: telling the whole algorithm of a use case in one place.