See Design Patterns, part one; Introduction to get the definitions and the laws of design patterns.

Creational Patterns are used to isolate the details of object creation. They will help us stay under the law of low coupling. App controllers will be decoupled of object types and they will not change as new types arrived. Creational Patterns are about how an object can be created.

There are identified six patterns (more or less an exact number, they have not yet standardized the patterns):

  • Singleton – only one instance can exist;
  • Factory Method – creates an instance of several derived classes;
  • Abstract Factory – creates an instance of several families of classes;
  • Builder – to separate the construction from the representation to allow multiple different representations;
  • Object Prototyping – creates objects based on a fully initialized instance (copy or clone);
  • Object Pool – avoid expensive acquisition and recycle.

 

Singleton

You may use Singletons when your application needs one, and only one, instance of an object. The first intent is to prevent the client programmer from having any way to create an object except the ways you provide.

There are many examples of Singleton usage:

  • any Factories as they are a global need;
  • logging points;
  • configuration classes;
  • lookup service;
  • accessing resources in shared mode.

There are several implementations of this pattern, but all make all constructors private and create at least one constructor to prevent the compiler from synthesizing a default constructor. Some of the theorists ask for lazy initialization, but I do not consider it a must. The Singleton design pattern is one of the most inappropriately used patterns. Singletons are intended to be used when a class must have exactly one instance, no more, no less. Programmers frequently use Singletons in a misguided attempt to replace global variables, why the hell are you using global data?

Object Pool

Sometimes objects are expensive (eg. db connections) and you can think about recycling them. This is a technique to create a limited pool of objects.

As a Factory Design it is a Singleton. Factories create the objects and then forget about them, but The Pool manages objects lifetime and keeps track of them.

Factory Method

The new operator is considered harmful and this pattern makes the difference between requesting an object and creating one. The new operator always creates an object and fails to encapsulate object creation. Factory Method enforces that encapsulation and allows an object to be requested without inextricable coupling to the act of creation.

When you need to add new types to the system the first idea is to use polymorphism as new types may be added without disturbing existing code. If the code that creates objects is distributed throughout your application, you must chase down all the points of your code where type matters and you will broke the night compilation. The solution is to force the creation in one place through a common Factory. As you get experience I suspect that Factories will be the most universally useful kinds of design patterns.

Often, designs start out using Factory Method (less complicated, more customizable, subclasses proliferate) and evolve toward more abstract as the designer needs more flexibility.

As OOD has two fundamental ways to relate classes – inheritance and composition here you may also think as two ways to create objects – Factory Method use creation through inheritance and Prototyping creation through delegation. Prototype doesn’t require subclassing, but it does require an Initialize operation. Factory Method requires subclassing, but doesn’t require Initialize.

The most used example is the injection mold press. Manufacturers of plastic toys process plastic molding powder and inject the plastic into molds of the desired shapes. The class of toy (car, action figure etc.) is determined by the mold.

Abstract Factory

Provide an interface for creating families of related or dependent objects without specifying their concrete classes. It is a natural evolution of Factories as modern applications can run on different platforms. If an application is to be portable, it needs to encapsulate platform dependencies (including UI, OS, DBs etc). The application must replace the entire family of products simply by instantiating a different concrete instance of the abstract factory. In other words, The Abstract Factory is a super-factory which creates other factories (Factory of factories).

Follow the law of simplicity and do not consider platform independency if not needed. To get one more abstraction layer just because you do not choose what DB to build on it is a very bad design. First to do is a Pro-Cons matrix of “platforms” versus “products”, sometimes it is easier and cheaper to build products on platforms.

Builder

The goal of Builder is to separate the construction from the representation to allow multiple different representations. The construction process stays the same, but the resulting object has different possible representations. The differentia of Builder in Factories is that it has multiple steps in creating an object and those steps are accessed externally to the Builder object.

An old lady thought me that McDonalds is using a builder process. Whether a customer orders a hamburger, cheeseburger or chicken the process is the same. The employee at the counter directs the crew to assemble a main item, side item and toy. These items and the drink are then placed in a bag.

Prototyping

The mitotic division of a cell – resulting in two identical cells – is an example of a prototype. The new operator is considered harmful and then we can consider build our own Factory that cache prototypical objects for use as breeders of all future instances. javascript is the common object-oriented language that relays on Prototyping.

A problem with the other Factory designs above is that they require a central location where all the types of the objects must be known: inside the factory( ) method. If new types are regularly being added to the system, the factory( ) method must be changed for each new type. When you discover something like this, it is useful to try to go one step further and move all of the information about the type, including its creation, into the class representing that type. This way, the only thing you need to do to add a new type to the system is to inherit a single class.

 

At the end I must emphasize that sometimes Creational Patterns are competitors: there are cases when either Prototype or Abstract Factory could be used properly. At other times they are complementary: Abstract Factory might store a set of Prototypes from which to clone and return product objects.

G.

 

  • On average, each employee uses 17 cloud apps, but many organizations don’t know what is in use, or whether these apps meet security, privacy and compliance requirements
  • In 91% of organizations, employees grant their personal accounts access to the organization’s cloud storage
  • 70% of the organizations allow cloud admin activity from non-corporate, unsecured networks
  • 75% of privileged cloud accounts are not in use. These accounts might be eating up the cost of a license, or worse, increasing the attack surface of the organization
  • On average, an organization shares 13% of its files externally, of which 25% are shared publicly

Vremuri bune să te-apuci de furat secrete comerciale!

G.

Ce mai citește nea Georgică pe un blog tehnic.

iar spre surprinderea programatorilor, va include sistemul de linii de comandă Bash specific platformei Linux, disponibil până la această oră pe Windows doar prin intermediul unei mașini virtuale.

Du-te, mă, la vaci!
G.

PS.
MS face o mișcare îndrăzneață – pune o interfață grafică user friendly (nicio interfață în *nix world nu e cît de cît utilizabilă, exceptînd MacOS, dar MAC e în sine un world) peste toate uneltele Linux care s-au impus overthetime. Nu pariez pe ea, dar îi dau ceva șanse la succes. Va avea cu adevărat succes dacă aplicațiile Linux vor avea de cîștigat din acest joint (da! în ambele sensuri ale acestui cuvînt). Windows are cîteva puncte tari care lipsesc pe Linux – WMI, suport real pentru copy/paste, management console, registry (cam controversat acum, dar la vremea lor o chestie tare), UI și UX unitare. Dacă vor prinde! Dar mă îndoiesc pentru că singurul fapt certificabil pe Linux comunitar este că programatorii sunt leneși și superiori (nu-i de mine să fac o interfață intuitivă și utilizabilă, ia de-aici șapte mii de opțiuni și bate-ți capul cu ele).

Am citit pe blogul lui Steve Blank  „De ce avocații nu sînt buni antreprenori”. Plus „de ce întreprinzătorii urăsc avocații”.

Cică

  1. Nu vorbesc clar și concis, doar avocățeasca;
  2. Nu te țin la curent cu mersul lucrurilor;
  3. Te supra-încarcă cu toate *ăcaturile avocățești;
  4. Nu sînt capabili să te asculte și să-ți înțeleagă problema;
  5. Întotdeauna novicii vor face toată treaba, deși tu ai angajat o firmă mare;
  6. Se leagă te toate amănuntele pierzînd din vedere problemele importante;
  7. Nu le pasă de problema clienților;
  8. Costurile lor te cocoșează;
  9. Sînt de negăsit atunci cînd ai nevoie de ei;
  10. Pentru că sînt „deal-killers”.

G.

Am aflat că în sistemul sanitar american nu există scuze pentru doctori sau ceilalți din sistem dacă se întîmplă una din situațiile de mai jos:

  • înseminarea artificială de la un donor greșit (fie că e spermatozoidul greșit, fie că e ovulul greeșit)
  • uitarea/lăsarea/introducerea în pacient a unor obiecte care nu fac obiectul procedurii (chirurgicale sau de altă natură)
  • cît timp ești în spital sînt răspunzători pentru ce ți se-ntîmplă
    • medicație eronată (au greșit medicamentul, au greșit pacientul, au greșit administrarea, au greșit cantitatea șamd)
    • transfuzie eronată (au greșit grupa de sînge sau HLA sau te-au infectat cu HIV)
    • embolie (astuparea unui vas sanguin cu o bulă de aer)
    • moartea sau rănirea gravă în urma unui șoc electric (exitsă o procedură în care inimii i se aplică un șoc pentru reglarea ritmului)
    • arsuri
    • alte ulcerații de gradul 3 sau 4 (răni grave legate de chimicale, temperatură, frecare șamd)
    • moartea sau rănirea gravă în urma unei căderi (cam birocratică acestă idee)
    • sinuciderea pacientului (cam stupidă)
    • agresiune fizică sau sexuală
    • dispariția sau răpirea pacientului
  • greșeli chirurcicale
    • au greșit pacientul!
    • au greșit operația (fie au greșit piciorul, fie au făcut altă operație, fie nu au respectat protocolul)
    • moartea intraoperatorie sau post operatorie după o operație simplă (avem un caz cu unul care s-a dus cu mîna ruptă și n-a mai ieșit viu din spital)
  • moartea sau rănirea gravă în urma contaminării din spital, legată de unelte, medicamente sau oricealtceva
  • folosirea uneltelor în alt scop decît au fost create
  • ți-au dat alt copil sau l-au dat p-al tău altuia
  • moartea mamei la o naștere low-risk
  • moartea sau rănirea gravă asociată hipoglicemiei (măcar o perfuzie cu glucoză pot să-ți facă!)
  • moartea sau rănirea gravă a fătului legate de hyperbilirubinemia (ceva legat de icter la copii)
  • moarte sau rănirea gravă în urma spinal manipulative therapy
  • îți bagă pe gît alt gaz decît cel prescris (la anestezie încurcă gazul)
  • moartea sau rănirea gravă a pacientului legat de pat
  • orice incident legat de un fals doctor (sau orice alt rol din sistem)

Par de bun simț, de ce nu avem și noi astfel de reguli în sistemul sanitar? Sau măcar să fie considerate de bun simț la judacată?

G.

These days I’ve been asked to teach these junior software developers several advanced features of Object Oriented Programming and I’ve started this class of Design Patterns. This is a drought, a skeleton, to develop the course.

What are Design Patterns? I don’t know, ;). Can be thought as grounded best practices to solve a class of problems, to have the most general and flexible solution for them. To define what patterns are we have to think about advanced application design. The advanced practice in software developing is to separate the thinks that change from the ones that stay the same. We introduce this abstraction layer into our applications to isolate changes and keep them to propagate other changes throughout the code (of course, the difficult part is to identify what change). Once you have isolated the changes in your code you have some kind of a pattern. Is it a Design Pattern? Nope, you will achieve it when you go with the most general solution.

Four problem solving techniques:

  • language specific – when use language features to get the problem solved;
  • specific design – when use the described technique to solve specific problem;
  • standard design – to solve some kind of problems (repetitive reusable pieces of codes);
  • design patterns – the most general and flexible solution for a class of problems.

Do not let them fool you with words – generalizing is not a goal, is a means. Do not waste your time looking for patterns, start thinking about your problem and in time they will be revealed.

Classifying patterns:

  • Creational – how objects are created; used to isolate the details of object creation;
  • Structural – the way objects are connected with other objects so changes in the system do not affect these connections;
  • Behavioral – objects that handle particular actions.

The laws of application design:

  • the simplest solution is the best; of course you have to consider full application life-cycle, but simplicity is the base;
  • avoid duplication;
  • isomorphism – one abstraction per class, one class per abstraction;
  • consistency – keep your ideas in place;
  • low coupling, high cohesion – coupling refers to the degree to which the objects depend on each other, cohesion refers to the degree to which the objects belong together;
  • keep your code readable (my first choice);
  • keep surprises out;
  • make common things easy and rare things possible;
  • use YAGNI – the design is finished when anything cannot be removed;
  • keep your unit testing updated.

G

These days I’m in process for selecting a framework for an application. An easy task several years ago when only Windows and Visual Studio were giving the pace. Now, on anything on web days, you have more than plenty good frameworks (and far to many shitsJS) to choose from. Here are some points you must keep eyes on:

  • YOUR APPLICATION

    I have encountered people that chosen a framework because everybody else used it and also must they. Your app will give you the most important criteria to weight a system.

  • What is framework capable of?

    Do not lay your ear on internet hearsay. There are more vaporware than facts. Test it.

  • Who support the framework

    One is Microsoft, Tweeter, Facebook and other ACME ltd who wants to get framework tested for free. Do not put your money on Google. They have made history on laying down projects (and not carrying about clients).

  • Is the framework mature? Can you see it on production?

    My experience says “use only framework versioned 3.x or about to be 3.x”. They change a lot on v1 through v2 to be stable on v3.

  • Does the framework have a comprehensive set of documentation?

    This is the most important criteria to eliminate a framework. Run away from a framework (or anything in computer area) with bad support. If the producer disconsider this part their only meaning is to get free testing.

  • your application

    I cannot emphasize enough how important is the application in the process of selecting the framework to be built on. Do not chose flexibility on flexibility only, do not chose performance on performance only, do not chose web-like on anything is on web only, do not chose scale for scale only, do not chose the popular on popularity only.

G.

I found a PM position advertised as this:

To apply, please send us a link to your linkedIn profile and a 200 word email (in English). You can write anything you wish in that email, provided that it shows us:
1) How you’d handle a situation where the client is angry because someone made an error
2) How you’d handle a situation where the client thinks they know more than you do, but they’re obviously wrong
3) How you’d share negative and positive feedback with your team

You cannot get better text for this job. Compare it with this corporate language:
– Strong written and verbal communication skills
– Strong ability to proactively identify and resolve issues
– Strong analytical skills
– Good time management skills

How can you get from any CV that he has good communication skills? Wth Strong analytical skills are? If you waste the time to apply to this job will still they consider that you have Good time management skills?

G.

ps. as it is a blog to remember me several ideas, here are the answers for the three questions

  1. The client is angry not on error, but on impact of the error on his business. There are two categories of clients – those who can manage themselves the negative impact and who will fire you and the ones that have their asses wet. For the last you can bring help. First thing to say is to assure them that you will work with them to control the facts. Second is to roll up the sleeves to find out where the problem is. Third (only after you know the problem), start to work on the problem AND mitigate the impact on the business. DO NOT begin working with the material impact until you clarify the facts.
  2. This is a tricked question. The client ALWAYS knows better than you everything about HIS business. Obviously wrong from your point of view is a very very narrow point of view and you must trust your client knows better what’s good for him. First thing to do is to try to understand his point of view. Then you can work together to bring it to live. If you still are in uncertainty you can ask him for guidance and close assistance. Or you can resign (this is the best thing to do if you still feel the client thinks they know more than you do…).
  3. There are not positive or negative attributes of feedback. The feedback is always valuable and must be transmitted as is. The most important thing about feedback is not the manner you share it, but how you use it. First you must keep it impersonal and focus on the facts. Second, USE IT, there is not better information than feedback. Even if you use it as lesson learned it is always an added value to your enterprise.

I found that mysql supports stored procedures and start working on them. Bad idea!

On php site (http://php.net/manual/en/pdo.prepared-statements.php) you get this piece of code:
Example #4 Calling a stored procedure with an output parameter
<?php
$stmt = $dbh->prepare("CALL sp_returns_string(?)");
$stmt->bindParam(1, $return_value, PDO::PARAM_STR, 4000); 
$stmt->execute();
print "procedure returned $return_value\n";
?>

After spending a couple of hours on trial-error coding different solutions I compiled this workaround:
<?php
$stmt = $dbh->prepare("CALL sp_returns_string(@out_param)");
$stmt->execute();
$result =  dbh->query("SELECT @out_param")->fetch();
print "procedure returned ". $result['@out_param'] ."\n";
?>

To conclude: do not use mysql and php on any serious apps.
G.

MySQL are un mod dubios de autentificare.

Dacă atunci cînd primiți mesajul Access Denied pentru un user@% (any host) care are toate drepturile necesare și suficiente simțiți că trebuie să-i transmiteți numai bine mamei designerului modului de autentificare nu înseamnă că sunteți o persoană rea.

Un user care se conectează la mysql pe protocolul socket connection este considerat user@localhost și este diferit de user@%. Doar pentru conexiuni via TCP user@% este alias pentru user@localhost. Dacă Bulă care a desenat mysql a considerat că modul de autentificare poate fi dependent de protocolul de conectare la aplicație noi nu putem decît să tragem concluzia că nu e bine, să-i mulțumim pentru efortul la care ne-a supus materia cenușie căutînd trei ore ce dracu înseamnă acest access denied (îndepărtîndu-ne astfel ziua debutului Altzheimmerului) și să nu mai folosim MySQL data viitoare.

G.