OOT (Object Oriented Tricks)

Hi guys, so I ended up series Clean Code articles. There are many other topics in that book which I have not yet talk about. You can read more in that book. And today, I'll also talk about one topic related in Clean Code: OOT (Object Oriented Tricks). OOT is a mini series on writing maintainable Object Oriented code without pulling your hair out. I reference it on hackernoon and here is the link trick #1, trick #2, trick #3, trick #4, trick #5 & trick #6. Thanks Arun Sasidharan a lots.

There are 6 tricks like below:

• Command Query Separation 
• Law of Demeter 
• Death By Arguments 
• Starter Pattern 
• Boy Scout Rule 
• Single Level of Abstraction Principle

Command Query Separation

• It states that every method should either be a command that performs an action, or a query that returns data to the caller, but not both. 
• Command: change the state of a system, but do not return a value. 
• Query: return a result, and do not change the state of the system.
  

Law of Demeter

• The Law of Demeter (LoD) or principle of least knowledge, can be succinctly
  summarized in each of the following ways:
  – Each unit should have only limited knowledge about other units: only units "closely" related to the current unit.
  – Each unit should only talk to its friends; don't talk to strangers.
  – Only talk to your immediate friends.

 

• The Law of Demeter (LoD) or principle of least knowledge, can be succinctly
  summarized in each of the following ways:
  – Each unit should have only limited knowledge about other units: only units "closely" related to the current unit.
  – Each unit should only talk to its friends; don't talk to strangers.
  – Only talk to your immediate friends.
• Problem: when you ask the customer to pay, the customer gives you his wallet and you get a certain amount of money from his wallet! 
• Solution: change the processing process of payment to customer.

 

Death By Arguments

• The best functions have as few arguments as possible (niladic > monadic > dyadic > triadic > polyadic).
• It also makes it all too easy to pass arguments in the wrong order with little type safety, and can reduce readability of the code.
• They are hard to read and hard to understand till you double take on the function signature every time you call it.
• It’s difficult to write all the test cases ensuring all the various combinations of arguments work properly
• Death By Booleans:
  – When you pass a boolean into a function, you are declaring that you’ve written a function that does two things: one thing for the true case and another for the false case.
  – Instead, you should have written two functions, one for each case. 

Starter Pattern

• We usually construct our objects in one place. It could be a constructor, builder, static factory method, abstract factory or any of the other Creational Patterns.
• There are times when objects created by a framework need some additional state that we need to set. Once such example, in Android, is the Activity class. The Activity is created by the Android framework and we can only add attributes via an Intent.

• To start this TargetActivity from various entry-points across many classes and had startActivity(intent) written everywhere >> This violated DRY: Don’t Repeat Yourself.
• To avoid disappointment at run time, it’s nice to define a contract within the target class itself. Use a static starter method for this:

Boy Scout Rule

• Leave the campground cleaner than you found it.
• The Broken Window Theory

 

• Software rot starts with one broken window.
  – One broken window, if left unrepaired for a substantial amount of time, so another window gets broken.
  – Serious structural damage begins.
  – In a relatively short time, the building becomes damaged beyond the owner’s desire to fix it, and the sense of abandonment becomes reality.
• Don’t leave “broken windows” unrepaired. Fix each one as soon as it is discovered.
• Leave the code cleaner than you found it. 

Single Level of Abstraction Principle

• Functions should do just one thing, and they should do it well.
• Code within a given segment/block should be at the same level of abstraction.

• If the line of codes does not directly implement the single responsibility of the
  function, it is another level of abstraction.
• For example, if function name is saveChangedCustomers() and takes a list of ALL customers as a parameter, and the single responsibility is to save any customers in the list that have been changed.

• The logic to determine if the customer has changed embedded in the foreach loop.
• Determining if the customer record has changed is NOT the responsibility of this function.
• It is a different level of abstraction.

 

See you in next topic about SOLID principles...