Bigger is not Better – Small interfaces (coupling)

Sunday, April 27, 2014

Hi, As part of my work, not a litte part of it, is the APIs. What we want to reveal? the way we going to do so, the encapsulation and all other things that will describe the functionality we give. But, more than once I found out that the bad experience is not  by the way the API is written but by what it revealing. I’m taking about “The road to hell is paved with good intentions”. For example you have a developer that got a mission to create an API for “Account Management”; Create account Find account by name Delete account by Id Now’ your...

Visitor Pattern

Monday, April 21, 2014

After I wrote the previous post I understand that must of the time by accident we couple the logic to the model too much, and that all in the name of capsulation. Let’s take for example the next Classes: We can see here 3 concrete Classes that diverted from SmartDevice Class. Tables, Phones & Watches. As you can see I reviled 4 methods here (I you can imagine there are more than that), By from my point of view under 2 categories: Close Method: No change on the logic, no extension required Support3G: By the device spec, or it’s supported of  not MemorySize: The same...

The S.O.L.I.D way: When it’s a Class and when it’s NOT???

Thursday, April 17, 2014

Actually at first it's seems a very dumb question, because for sure we know when we declaring a new class. But I found that it's not so true!!! Let's take the next scenario. You are creating a new website for "Games how to???" For example: Soccer​ 2 teams, 11 players on each team 1.5 hours with one breaks Cannot touch with the hand Ball cannot get out from the field borders Need soccer field Basketball 2 teams, 5 players on each team 1 hour game, with 4 breaks Cannot walk with the without dribble Ball cannot get out from the field borders Need basketball field Cheese 2 players Each move can/or not...
no comments