Tuesday, January 16, 2018

Better Code


http://letstalkaboutjava.blogspot.com/2016/02/constructor-or-setter.html
Why do we have so many constructors? Because some dependencies are optional, their presence depends on external conditions.
what’s the purpose of the constructor?

We should create an object in a valid state. We should not allow to create an instance if there is something more that hasto be done to make an object usable. That’s why all required dependencies should be placed in a constructor.
On the other hand, we should place in the constructor only the required dependencies. Constructor is not a place for anything optional. If something is optional, this means we don’t need it to create a valid object. 

If we would like to use other dependencies that are nice to have we should inject them in different way. And this is where setters come into play. We are not forced to invoke setter method. We may have a need, but this is not required. You should use setters when dependency is an option.

From the first moment you know what is required and what just might be used.
Well, we will not avoid those methods. Or to be more precise - we need their functionality. There is a need to let the customer enable the functionality. In a given example mutators needs to stay because they’re needed. However, we can always make the code better. More domain-related. How? We just need to show this relation with the domain:
?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
public class SomeHandler {
   public SomeHandler(Repository repository, Trigger trigger) {
       // some code
   }
 
   public void enable(SnapshotTaker snapshotTaker) {
       // some code
   }
 
   public void enable(Notifier notifier) {
       // some code
   }
 
   public void handle(SomeEvent event) {
       // some code
   }
}
remember to name a method in a way that will show domain connotation.

Too many options

Sometimes too many options also pose a problem. It can be a sign that you’re violating Single Responsibility Principle
If there are too many options it might mean that there are too many responsibilities and it is worth re-thinking your current solution. 
Be very careful whenever adding another optional part into the code of the class. Maybe this class is doing too much?

You should know now that you ought to place only required dependencies in your constructors . Any optional dependencies require other well-named methods.
http://letstalkaboutjava.blogspot.com/2016/02/methods-name-change-lot.html
To make my thinking clear, I don’t have a problem with mutator methods, I just don’t like all of those setX/getX methods. Why? I believe that each method is about behavior and it name should tell something about this behavior. Setters tell us nothing about behaviour and make implementation details leaking.

public void enable(SnapshotTaker snapshotTaker) {
   // some code
}
 
public void enable(Notifier notifier) {
   // some code
}

But with different name we know what’s the purpose of those methods. We didn’t create them to set a field, we introduced them to make it possible to enable some optional functionality. 
The same functionality with different name gives us more valuable information. Explains the Why, not How.
https://dzone.com/articles/silly-code-can-we-try-to-do-a-bit-better-in-2018
Example #3: Hard-Coding in a Sea of Constants
if (type == TYPE.ACCOUNT) {
    // handle account-related tasks
} else if (type == TYPE.CONTACT || type == "customer") {
    // handle contact or customer tasks
}
Rule of thumb: Follow the established pattern, even if it means taking a couple extra steps to complete the task.

Example #5: Querying the World When You Only Need a Small Village
When introducing new program code as a part of a feature, I asked the team lead how I would gain access to the data I was developing. I noticed that I was going to use the same API call that was used in several other aspects of the application. When I called the API and reviewed the source data, I noticed the size of the payload that was returned. It was huge!
What was worse is that the expectation is that I would POST this payload back to the API, even if I only modified a few of the objects in the payload. When I viewed this design from a production-support perspective, I could not imagine the impact of performance and save conflicts that could occur with this model once deployed to a large user base.
Rule of thumb: Try to keep your payloads focused on meeting the needs of functionality being addressed.

Maybe some of you at this moment recognize an anti-pattern that is known as anemic domain model?
refactoring.started();
refactoring.accepted();
refactoring.applied();
I believe that some of you at this moment thought “Wait, but know I will have three methods that underneath will do exactly the same?”
The answer is yes, all of those method will set the value of the state attribute. But does it really matter? Are we interested in the attribute value? Are we interested in the attribute at all? No, we just want to be sure that refactoring was started/accepted/applied. We don’t care about the way how it was implemented at all.
Thanks to such design we may changing implementation in any way we want as long as the contract conditions are met. Information about implementation are unknown at this moment. We know what we have to know and nothing except this. The functionality that is using the object is not so tightly coupled with its implementation details anymore.







Labels

Review (554) System Design (293) System Design - Review (189) Java (179) Coding (75) Interview-System Design (65) Interview (60) Book Notes (59) Coding - Review (59) to-do (45) Knowledge (39) Linux (39) Interview-Java (35) Knowledge - Review (32) Database (30) Design Patterns (29) Product Architecture (28) Big Data (27) Soft Skills (27) MultiThread (26) Miscs (25) Concurrency (24) Cracking Code Interview (24) Career (22) Interview - Review (21) Java - Code (21) Operating System (21) Distributed (20) Interview Q&A (20) OOD Design (20) System Design - Practice (19) Security (17) Algorithm (15) How to Ace Interview (15) Brain Teaser (14) Google (13) Linux - Shell (13) Spark (13) Spring (13) Code Quality (12) How to (12) Interview-Database (12) Interview-Operating System (12) Redis (12) Tools (12) Architecture Principles (11) Company - LinkedIn (11) Testing (11) Resource (10) Solr (10) Amazon (9) Cache (9) Search (9) Web Dev (9) Architecture Model (8) Better Programmer (8) Company - Uber (8) Interview - MultiThread (8) Java67 (8) Math (8) OO Design principles (8) SOLID (8) Scalability (8) Cassandra (7) Design (7) Git (7) Interview Corner (7) JVM (7) Java Basics (7) Machine Learning (7) NoSQL (7) C++ (6) File System (6) Highscalability (6) How to Better (6) Kafka (6) Network (6) Restful (6) Trouble Shooting (6) CareerCup (5) Code Review (5) Company - Facebook (5) Hash (5) How to Interview (5) JDK Source Code (5) JavaScript (5) Leetcode (5) Must Known (5) API Design (4) Be Architect (4) Big Fata (4) C (4) Company Product Architecture (4) Data structures (4) Design Principles (4) Facebook (4) GeeksforGeeks (4) Generics (4) Google Interview (4) Hardware (4) JDK8 (4) Optimization (4) Product + Framework (4) Shopping System (4) Source Code (4) Web Service (4) node.js (4) Back-of-Envelope (3) Company - Pinterest (3) Company - Twiiter (3) Company - Twitter (3) Consistent Hash (3) GOF (3) Game Design (3) GeoHash (3) Growth (3) Guava (3) Interview-Big Data (3) Interview-Linux (3) Interview-Network (3) Java EE Patterns (3) Javarevisited (3) Map Reduce (3) Math - Probabilities (3) Performance (3) Puzzles (3) Python (3) Resource-System Desgin (3) Scala (3) UML (3) ZooKeeper (3) geeksquiz (3) AI (2) AngularJS (2) Behavior Question (2) Bugs (2) Coding Interview (2) Company - Netflix (2) Crawler (2) Cross Data Center (2) Data Structure Design (2) Database-Shard (2) Debugging (2) Docker (2) Elasticsearch (2) Garbage Collection (2) Go (2) Hadoop (2) Html (2) Interview - Soft Skills (2) Interview-Miscs (2) Interview-Web (2) JDK (2) Logging (2) POI (2) Papers (2) Programming (2) Project Practice (2) Random (2) Software Desgin (2) System Design - Feed (2) Thread Synchronization (2) Video (2) reddit (2) Ads (1) Advanced data structures (1) Algorithm - Review (1) Android (1) Approximate Algorithms (1) Base X (1) Bash (1) Books (1) C# (1) CSS (1) Chrome (1) Client-Side (1) Cloud (1) CodingHorror (1) Company - Yelp (1) Counter (1) DSL (1) Dead Lock (1) Difficult Puzzles (1) Distributed ALgorithm (1) Eclipse (1) Facebook Interview (1) Function Design (1) Functional (1) GoLang (1) How to Solve Problems (1) ID Generation (1) IO (1) Important (1) Internals (1) Interview - Dropbox (1) Interview - Project Experience (1) Interview Stories (1) Interview Tips (1) Interview-Brain Teaser (1) Interview-How (1) Interview-Mics (1) Interview-Process (1) Jeff Dean (1) Joda (1) LeetCode - Review (1) Library (1) LinkedIn (1) LintCode (1) Mac (1) Micro-Services (1) Mini System (1) MySQL (1) Nigix (1) NonBlock (1) Process (1) Productivity (1) Program Output (1) Programcreek (1) Quora (1) RPC (1) Raft (1) RateLimiter (1) Reactive (1) Reading (1) Reading Code (1) Refactoring (1) Resource-Java (1) Resource-System Design (1) Resume (1) SQL (1) Sampling (1) Shuffle (1) Slide Window (1) Spotify (1) Stability (1) Storm (1) Summary (1) System Design - TODO (1) Tic Tac Toe (1) Time Management (1) Web Tools (1) algolist (1) corejavainterviewquestions (1) martin fowler (1) mitbbs (1)

Popular Posts