Is Data Abstraction and Encapsulation a fancy term of Information Hiding?

I have seen many developer/Architect use the term interchangeably and has the reason for it but yes there are differences-- a huge difference in terms of hiding information. I try to explain it in a Simple way.
Let’s start by the definition.
Encapsulation: binds data and behaviors together in a Single unit and behaviors acts on the data.
Abstraction: Hiding the implementation details and expose the functionality to the world.

According to both definition, both try to hide data from rest of the world and expose some behaviors/method so other System/API can use it.

At this point Both are same so If someone uses those term Interchangeably they are correct.
But hold why then Two fancy concepts are side by side in OOP why they are not merged into a one and called it “Information hiding

To understand the same take a look Suppose you have to implement a car.
So when you rotate the steering lots of thing happening inside and eventually car is moving to the direction you rotate the steering.
Now let explain the Action in details
Input: Steering rotation direction.
Output: car moves in the Direction steering rotated.
but what is happening inside is a black box to the user—That is called Abstraction
So technically it says What to abstract from User?
Abstraction is a functionality which helps the developer to identify what is the functionality that should be abstracted and exposed as a function/method which takes User input and returns desired result what User wants.
In a car Steering functionality, Braking functionality, Auto parking --these are the functionalities has to be abstracted from User— User less interested How it works but what they interested is What should I do(Input) and What will be the Outcome. So according to me Abstraction is

Abstraction:  By Abstraction, developers identify the functions what should be published in API and what input it takes and What Output it returns.

So, another point of view is, Abstraction helps us to the generalization of a functionality-- So When you design a function’s input or output you should be very careful about the data type you used-- It should be supported all possible combination on which function can be applied.

Now come to Encapsulation It tells about How to achieve the functionality-- which has been identified by Abstraction.

So it tells us about the packaging the data and behaviors.
Take the same example use steering to move the car.
Encapsulation: identifies the different parts associate to move the car using user instruction like steering, Wheel, Engine.Petrol . Also, it identifies the algorithm/behaviors which will be applied to these data(wheel, steering, engine, petrol) to move the car, and help to binds or packaging as one single unit. In my perspective Encapsulation definition is.

Encapsulation:Encapsulation Helps to understand what are the data and functions, that should be bundled as a Single Unit so User can act on them without knowing internal details and get the job done.
Information Hiding
Explanation of the figure: When you design an API/Class always there is two perspective one is Developers View and one is API User view. From Developers View Abstraction is to identify the features to be provided and Encapsulation is the process to communicate with internals things and provide the functionality. So it makes sense to have two distinct terminology Abstraction and Encapsulation.

But for User of the API/Class, It is like what functionality is exposed and what is the input and what will be the output so functionality an API provides nothing but Opaque things to them they provide input and got Output --API or Class is a barrier or Facade for them So for them it is just an Information hiding so Abstraction and Encapsulation has no meaning for them. It can be used alternatively to mention information hiding.

Conclusion :  Abstraction and Encapsulation both are used for hiding information context but their purpose is different.  Abstraction helps to understand the functionality User interested for and providing the same to the user as a black box. Encapsulation is about the gathers the required data and algorithm to solve the purpose for the user and tied them in a single Unit so the user of the API  doesn't have to collects the data and apply the algorithm by itself to get the job done.

3 wise men on Tell Don't ask

A story on Tell Don't ask Principle


John, Doe, and Marcus are three good friends. They have over 20 years of experience Java/JEE stack and working in IBM, Cognizant and TCS respectively. They have immense experience in design pattern and all the new technologies and respected by their colleague for Exceptional insight on the Technology Stack.
They are planning to go for a vacation in the upcoming weekend to enjoy their spare time with lots of Burger, whiskey, and cooking. John has an Outhouse in a village so they planned to go there by driving.
At last, the day came they pack their Beer, Whiskey, and Burger and headed towards John outhouse it was far away from Town. At evening they reached the outhouse and prepare some snacks for their whiskey and sit together in a round table to enjoy Chicken roast and Whiskey.
Suddenly the power cut happens, The room is so dark that no one can see anything, from outside they can hear the Call of Cricket, Marcus put on his mobile flashlight, now they can see each other.
Doe breaking the silence by saying,
“Oh well, this ambiance is perfect for a horror story can anyone share any real life experience?”
Marcus replied in a witty way
“Umm No, I believe all we are from town and busy with IT industry so sorry can not share any horror experience but can share some Java experience which still frightened me”
John and Doe’s Architect instinct flashed with this proposal.
They said, “ Oh yes what would be more good to discuss about something which frightened us an Architect in this ambiance, it is same as Horror Story :).”

Marcus slowly demonstrated the problem.
Marcus: As an Architect when I design a solution for a problem it always frightened me what we encapsulate and what portion we expose to our client program?
John and Doe Nodded their head.
Marcas Continue with his speech,
There are lots of OOPs principle which says how judiciously you can encapsulate your classes or API from outside world.
Take an Example, The  Tell Don’t Ask principle, It says us always tell to Object, in a layman term instruct Object what to do never query for an internal state and take a decision based on that because then you loose control over the object.
Take a simple example suppose I want to write a Parcel Delivery Service and there are two domain Objects Parcel and Customer so how should we design it.
If I write following code fragments

package com.example.basic;

* @author Shamik Mitra
public class PercelDeliveryService {
    public void deliverPercel(Long customerId){
        Customer cust = customerDao.findById(customerId);
        List<Percel> percelList = percelDao.findByCustomerId(customerId);
        for(Percel percel : percelList){
            System.out.println("Delivering percel to " + cust.getCustomerAddress());
            //do all the stuff for delivery


According to Tell Don’t Ask it is a violation and should be avoided. In Parcel Delivery Service I try to fetch or ask Customer Address so I can perform the delivery operation so here I query the internal state of the Customer.
And why it is dangerous?
If later if the delivery functionality change says now it also include an email address or mobile so I have to expose these details so exposing more and more internal state think about the other services they may also use the same email address or Customer address. Now If I want to change the Customer Address return type String to Address Object then I need to change all services where it has been used, so a gigantic task to perform and increases risk factor of breaking functionality. Another point is as internal state is exposed to many services there is always a risk to pollute the internal state by a service and it is hard to detect which service changed the state. In one word I loose the control over my object as I don’t know which services use/modify my Object internal state. Now if my object is used by the Internal services of a monolith application I can search the usage in IDE and refactor them but If the Object is exposed through an API and This API used by other organization then I am gone, It really hurts our company reputation and as an architect, I would be fired.
So I can say

Action: More you Expose Internal state
Outcome:  Increase coupling, Increases Risk, Increase Rigidity.

Now again look the solution I provided,
Doe chuckled and guess which point Marcus trying to make so he interrupted him and start saying.
Doe: So Marcus you want to tell if we follow Tell Don’t Ask principle then there are couple of ways we can refactor the problem
1. make an association between Customer and Parcel . and it would be lazy loaded and deliver method should be in Customer Object so from the service we call deliver then deliver method fetch parcel list and deliver it, so if the Internal return type change from String to Address only “deliver” method should be affected.
Like this,
package com.example.basic;

* @author Shamik Mitra
public class ParcelDeliveryService {
    public void deliverParcel(Long customerId){
        Customer cust = customerDao.findById(customerId);


public class Customer{

    public void deliver(){
        List<Percel> percelList = getPercelList();
      for(Percel percel : percelList){
            System.out.println("Delivering percel to " + this.getCustomerAddress());
            //do all the stuff for delivery

By doing this I maintain Tell Don’t Ask principle properly and decreases the risk of exposing internal state and free to modify my class attributes as all behaviors are tied locally with attributes a nice way to achieve encapsulation.
2. We can create a command Object where we pass the Parcel details and pass the command object to Customer Model, the delivery method extracts the Parcel list and deliver it to the respective customer.
But both policy breaks another principle that is Single Responsibility Principle, SRP(Single Responsibility Principle) says A class has only one reason to change.
But If I think in a reverse way, why we write Services? Because each service does one job like Person Delivery Service responsible for “delivery parcel related “ operations so it maintains SRP and this service only change if there are any changes in Parcel Delivery mechanism and if it breaks other services will not be affected unless other services depend on it.
But according to Tell Don’t Ask all Customer related behaviors should be moved into Customer class so we can tell /Instruct/command Customer class to do a task. So Now Customer class has much responsibility because all Customer-related service code now goes into Customer Model. So Customer has more reason to change so increase the risk factor of failing.
So Now we are back in the same problem risk factor.
If exposing internal state then the risk for modifying attribute if move all behavior into a class then the risk of modifying functionality break the system.
So SRP and Tell Don’t Ask principle contradict in this context.

John: John nodded his head and started with his husky voice, Yes this is really a problem
not only this, If we want to implement a cache in a service or want to implement Aggregation function like Percell delivery rate charge according to distance or Account type, Find most parcels sent to a locality we use Aggregator service where we ask for internal state and compute the result. So often we break Tell Don’t Ask principle. Even as per current trend, Model Object should be lightweight and should not be coupled with each other. If the business needs an information which distributes over multiple models we can write an aggregator service and query each model and compute the result , so we querying internal state. Think about Spring data.
Now If we look in another perspective, according to the Domain-driven Design, In a Parcel Delivery Context (Bounded context) is Customer responsible for delivering the parcel?
Absolutely not, In that context Delivery Boy is responsible for delivering the parcel to the customer. For that Delivery boy needs Parcel and Customer Model, and in that context only Customer name and Address details required and for parcel Id, parcel name will be required so as per DDD we create an Aggregate Model DeliveryBoy where we have two slick Model Customer and Percell because in this context we don’t need customer other details and parcel other details like customer account details, Customer birthdate etc, Context wise model is changed so no one big model for customer where all attribute and behaviour resides rather small slick models based on bounded context and an Aggregate model querying these slick model and perform the work.
By doing this we can mix and match SRP and Tell Don’t ask. For a service perspective we only tell /command DeliveryBoy Aggregate model to do something, so Service maintains SRP and Tell don’t ask, Our Aggregate model also maintain SRP but querying Customer and Parcel Model to do the operation.


package com.example.basic;

* @author Shamik Mitra
public class ParcelDeliveryService {
    public void deliverParcel(Long customerId){
        DeliveryBoy boy = new DeliveryBoy();


public class DeliveryBoy{
    Customer cust;// Context driven model
    Percel percel;
    public void deliver(Long id){
        //do stuff
//load customer slick model
//load Percel slick model
//Deliver the same by quering


Marcus joined and says let's take one step further as DDD insists  Microservice, so in Microservice we try to break a monolith using functional decomposition( A function is a Bounded context in DDD) so one service doing one task maintains SRP principle and if we needed and information which distributes over multiple services we create an Aggregator service and querying individual service and do the task so Microservice often breaks Tell Don’t Ask
Doe joined and says So there is no silver bullet and not all principles are good in all context, Based on the context you have to judge which principles you follow sometimes you need to compromise, may for a specific principle viewpoint your code is bad but for a given context it is optimum.

Principles are generic and they are context free but real life solution are based on context so fit principles based on context not the reverse.

In the meantime Light comes, so John said here we are for fun let stop the discussion and concentrate on Whiskey and Roast !!!!
Everyone agreed and change the topic.
Conclusion : As a Narrator, My question to all viewers, what do you think about the talk they did, is there are any points they left off which needs attention while designing?

The confusing RegEx

Regular Expression


Teacher: Today we will learn regex and how to use it in Java.
Jonny & Alice screaming with fear, they said in chorus, sir it is the most confusing thing which makes our life miserable as a programmer.
Teacher: Smiled!!! And replied yes I also used to think in this way when I am student :), But it is not hard as you think, Just need some key points to remember, Yes you have to remember key points like you remember History and Geography.
I try to point out those keys which will break your fear.
Before that tell me why you are saying regex confusing and also share the confusion to me.
Alice: Sir, The common problem is, it is hard to read and write, What we mean by that is , If we have a string to validate with a complex pattern, say email validation if you look the regex for that, it is a one liner with multiple backslashes, third brackets, first bracket etc. so we often perplex how to understand what it says. In simple word just seeing a regex solution, we don’t understand what it tries to say.
Teacher: So you mean readability right, you prefer to write more code to avoid RegEx, so code increases readability but lets me tell you regex is a Holy Grail if you unleash its power you can write concise and readable code.

Jonny: Sir another problem is there is no fix solution for a problem let takes the example of email validation if you search it in google you can see a ton of different solutions to validate email. So it is hard to take the right one?
Teacher: This is because you are not understood the crux of regex. Any other problem??
Students: Pin drop silence there.
Teacher slowly takes a step towards board and start his lesson.

What is Regex?
The teacher said Regular Expression is a technique  for search a pattern in a String, This search pattern can be very simple to very complex, a word to a sentence, or an expression made by different meta-characters or symbol used in the regex.
To understand regex correctly we need to know metacharacters/symbols and it’s meaning, This is the only thing you need to remember.
We found regex hard because we are not able to understand the usage of symbols.
Let take a look what are the different symbols used in the regex.
We can classify regex symbols in 3 brackets.

  1. Meta-Characters.
  2. Ranges & reserved symbols.
  3. Quantifiers.

Meta-Characters : In regex, there are some reserved metacharacters which have
pre-defined meanings to express some common patterns like the digit, whitespace etc in a compact way.

Meta Character
Alternate Expr.
To Express digit
[0-9] or [^\D]
By this we represent a digit character
To Express anything but not digit
[^0-9] or [^\d]
By this we represent a non-digit character
To Express a word
[a-zA-Z_0-9] or [^\W]
By this we represent a word character
To Express anything but not a  word
[^a-zA-Z_0-9] or [^\w]
By this we represent a non-word character
To Express a whitespace
[\t\n\x0b\r\f] or [^\S]
By this we represent any whitespace like \r,\t,\n etc
To Express anything but not a whitespace
[^\t\n\x0b\r\f] or [^\s]
By this we represent any non whitespace
To Express a boundary
By this we represent a boundary

Ranges & reserved symbols :  In regex when we try to match pattern, some information has to mention like how many times a pattern will be matched or you want to match the beginning of the string or end of the string or more complex pattern like maximum how many times a pattern can be a String or minimum etc. we defined them using ranges and reserved symbols.

Example Definition
Any character
Start with any character followed by ha then any character -- sham match:  gyan: not match
Check beginning of the line
If line starts with sha matched else false
sham : match :Aha “ not match
Check end of the line
If line ends with tra matched else false
Mitra: match :Chakra “ not match
Match either x or y or z
ax : Matched
aa : not matched
Match x,y or z followed by a or b or c
sha : Matched
sou : Not matched
Exactly X followed by A
sm: Matched
Sa : Not Matched

X or A
sX: Matched
sZ: Not Matched
Remember : When ^ uses in side third braces act as Negate.
sam:Not Matched
Match between a to c and digit 1 to 10 remember 
sb : Not Matched
Used for Grouping
sab1: Matched
shac: Matched
syab: Not Matched
sabb: Matched

Quantifiers: Quantifiers say how many times a pattern can be found in a String.

Example Definition
Pattern can occurs zero to many times
s    m : Matched
s:m:Not Matched
Pattern can occurs one to many times
s    m : Matched
sm:Not Matched

Pattern can occur no or one time
shha:Not Matched
Pattern must occurs exactly X times
s1234:Not Matched
s1:Not Matched
Pattern must occurs at least X and at maximum Y
s1:Not Matched
s12345:Not Matched

Email Validation :

Teacher : So Jonny earlier you said that Email validation is  confusing, Now can you guys tell us what below email validation says,


Jonny: Yes sir, first part says ^[A-Za-z0-9-\\+]+, email must start with any characters and there must be one occurrence,^ denotes the start of the line and + says one or more, so email can start with any characters with any length.
Sir: Very good, Alice you tell me the second part.
Alice : (\\.[A-Za-z0-9-]+)*, this says that after first part it followed by a dot then again any length of characters but at least one and this part is optional as * is in the last.
Sir: Impressive.
Jonny: @[A-Za-z0-9-]+  Then it strictly matches @ and then at least one character. As + is there.
Alice : (\\.[A-Za-z0-9]+)* again it follows by the dot and at least one character and it is optional again.
Jonny : (\\.[A-Za-z]{2,})$ then email ends($) with a dot and any character in a-z or A-z and length between two to any.
Sir: Great, Now Alice, tell me a Valid Email according to this regex.
Alice: or
Sir: good, Jonny tell me an invalid one
Jonny: shamik.mitra@co.i or
Sir: Well it seems you are learning regex very quickly. So before finish today's lesson I give you one tip, stick above tables in your desk so every day you can go through the regex symbols then easily you will remember the Regex.