Clean code & design patterns
Upcoming SlideShare
Loading in...5
×
 

Clean code & design patterns

on

  • 865 views

Review of Uncle Bob's Clean Code and applying common design patterns

Review of Uncle Bob's Clean Code and applying common design patterns

Statistics

Views

Total Views
865
Views on SlideShare
865
Embed Views
0

Actions

Likes
2
Downloads
5
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-ShareAlike LicenseCC Attribution-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Clean code & design patterns Clean code & design patterns Presentation Transcript

  • Pascal Larocque ● TrustCharge Team ● Behat guy ● Testing guy ● SOLID guy ● Pattern guy ● Father of 3 ● Star Wars Geek @pascallarocque
  • Bad Code ● Singletons ● Tight Coupling ● Untestable ● Premature Optimization ● Indescriptive name ● Duplication
  • Cost of Bad Code ● Very hard / Impossible to estimate ● Slows down team velocity ● High Learning curve ● Brings down team moral ● Increases cost of development
  • The Primal Conundrum Programmers face a conundrum of basic values. All developers with more than a few years experience know that previous messes slow them down. And yet all developers feel the pressure to make messes in order to meet deadlines. In short, they don’t take the time to go fast!
  • True professionals know that the second part of the conundrum is wrong. You will not make the deadline by making the mess. Indeed, the mess will slow you down instantly, and will force you to miss the deadline. The only way to make the deadline—the only way to go fast—is to keep the code as clean as possible at all times.
  • How do I write Clean Code?
  • What is Clean Code? “Clean code can be read, and enhanced by a developer other than its original author. It has unit and acceptance tests. It has meaningful names. It provides one way rather than many ways for doing one thing. It has minimal dependencies, which are explicitly defined, and provides a clear and minimal API. Code should be literate since depending on the language, not all necessary information can be expressed clearly in code alone.” - Dave Thomas “Clean code is simple and direct. Clean code reads like well-written prose. Clean code never obscures the designer’s intent but rather is full of crisp abstractions and straightforward lines of control.” - Grady Booch “I like my code to be elegant and efficient. The logic should be straightforward to make it hard for bugs to hide, the dependencies minimal to ease maintenance, error handling complete according to an articulated strategy, and performance close to optimal so as not to tempt people to make the code messy with unprincipled optimizations. Clean code does one thing well.” - Bjarne Stroustrup You know you are working on clean code when each routine you read turns out to be pretty much what you expected. You can call it beautiful code when the code also makes it look like the language was made for the problem. - Ward Cunningham
  • What is Clean Code?
  • The Boy Scout Rule “Leave the campground cleaner than you found it” Code Rots and Degrades as time passes The Code has to be kept clean over time. We must take an active role in preventing the degradation.
  • Naming ● Use intention revealing names ○ Why it exists ○ What it does ○ How it’s used ● Classes should have nouns or noun phrases ○ Don’t use Manager, Processor, Data or Info ● Methods should have verbs or verb phrases ● Accessor, Mutators or predicates should have get, set or is ● Use solution domain name ○ Factory, Visitor, Queue
  • Functions ● Small ● Smaller than that!!! ● Does ONE THING ● Does ONLY ONE THING ● Blocks and Indentation ○ IF, While, For ● One level of abstraction per function ○ getHTML() ○ $parsed = Parser::render($url) ○ $xml->append($node)
  • Functions ● Reads like a Top Down Narrative ○ To render the page we get all the content ○ To get all the content we extract it from the DB ○ To extract it from the DB we need to connect
  • Function Arguments The ideal number of arguments for a function is zero (niladic). Next comes one (monadic), followed closely by two (dyadic). Three arguments (triadic) should be avoided where possible. More than three (polyadic) requires very special justification—and then shouldn’t be used anyway.
  • Function Arguments - Flags Flag Arguments should be avoided. It does 1 thing if true and another thing when it’s false. render(true): renderForScreen() renderForTest()
  • Function Argument - Objects It’s easier to pass Objects instead of a long argument list or array Rectangle makeRectangle(Double x1, Double y1, Double x2, Double y2) Rectangle makeRectangle(Point point1, Point point2)
  • checkPassword(username, password) { user = $this->dataAccessor->findByUsername (username) valid= md5($user->getPassword()) === password if(valid) { Session.init(user) } else { Session.clear() } return valid } Have no side effect Sides effects are lies. BAD
  • Enforce Temporal Coupling class ACL { function login(username, password) { this->user = this->findUser(username, password) this->getPermissions() this->startACLSession() } } BAD class ACL { function login(username, password) { this->user = this->findUser(username, password) this->permissions = this->getPermissions($this->user) this->startACLSession(this->permissions) } } BETTER
  • if ($this->_sortBySet() === true) { ... } else if ($this->_sortByActor() === true) { ... } else if ($this->_sortByClip() === true) { ... } else { … } Make Conditions clear if (true === $bySetId && (true === empty($photoCollection) || true === empty($photoSet))) { ... } else if (true === $byActorId && (true === empty($photoCollection) || true === empty($actor))) { ... } else if (true === $byClipId && (true === empty($photoCollection) || true === empty($scene))) { ... } else { … } BAD BETTER
  • sortingAlgorithmInterface = phosetSortingFactory->findSorter(sortBy) sorted list = sortingAlgorithmInterface ->sort(photosetList) Replace Conditions with Factory if ($this->_sortBySet() === true) { ... } else if ($this->_sortByActor() === true { ... } else if ($this->_sortByClip() === true) { ... } else { … } POLYMORPHISM GOODNESS
  • Abstract Factory Pattern
  • Encapsulate Change Class UserRepository { function findById(id) { return Doctrine::getTable('Users')->createQuery(‘u’) ->where(‘u.id = ?’, id) ->fetchOne(); } } ORM MY GOD Class UserRepository { function findById(id) { userData = this->dataAccessor->findById(id) user = userFactory->create(userData) return user } } The only constant is Change.
  • Strategy Pattern
  • The Law of Demeter method f of a class C should only call the methods of these: ● C ● An object created by f ● An object passed as an argument to f ● An object held in an instance variable of C
  • Class ACL { protected user function hasAccessToAdmin() { return this->user ->isAdmin() } } The Law of Demeter Class ACL { function hasAccessToAdmin() { return getUserManager() ->getUser(123) ->getProfile() ->isAdmin() } } BAD Class ACL { protected user protected aclVisitor function setVisitor(visitor) { … } function hasAccessToAdmin() { return this->aclVisitor ->isAdmin(this->user-getProfile()) } } Class AclVisitor { function isAdmin(profile) { return profile->isadmin() } } MEH PATTERNS!!!
  • Visitor Pattern
  • Don’t pass NULL, Don’t return NULL Throw an exception Return a NullObject findUser(ID) { user = this->dataAccessor->findById(ID) if(user == null) { user = new NullUser(); } return user } Class NullUser { function getName { return ‘’ //DO NOTHING } }
  • NullObject Pattern
  • Observer Pattern
  • Singleton Pattern
  • Singleton Pattern "Singletons are the path of the dark side. Singletons lead to implicit dependencies. Implicit dependencies lead to global state. Global state leads to suffering."
  • As events arrive from the outside world at a port, a technology-specific adapter converts it into a usable procedure call or message and passes it to the application. CreditCardService Hexagonal Architecture CreditCardService HTTP REST PHPUnit SOCKET ADAPTER
  • When the application has something to send out, it sends it out through a port to an adapter, which creates the appropriate signals needed by the receiving technology (human or automated). CreditCardService Hexagonal Architecture CreditCardService HTML XML PHPUnit JSONP ADAPTER
  • Class CreditCardService __construct(InputInterface, OutputInterface) { this->input = InputInterface this->output = OutputInterface } function process() { input = this->input->getInput() output = this->doProcessing(input) return this->ouput ->sendOutput(output) } } CreditCardService Hexagonal Architecture CreditCardService class CreditCardHTTPInputAdapter implements InputInterface{ function getInput() {..} } class CreditCardJSONPOutputAdapter implements OutputInterface{ function sendOutput(output) {..} }
  • More stuff Command Query Separation Functions should either do something or answer something, but not both. DRY Don’t repeat yourself. Duplication may be the root of all evil in software. SOLID Single Responsibility, Open/Closed Principle, Liskov substitution principle, Interface segregation, Dependency Inversion Structured Programming Every function and every block has one Entry and one Exit Use Exceptions and Error Handling Functions should do one thing. Error handling is one thing. Thus, a function that handles errors should do nothing else.
  • SHARE KNOWLEDGE KNOWLEDGE DECAYS FAST SLOW DOWN TO GO FAST NEVER ASK PERMISSION TO DO YOUR JOB CORRECTLY
  • QUESTIONS?