Data Type Should Not Be Considered As a Source of Its Behaviour

/* In JavaScript we can use different types 
of elements in array as it's dynamic language */
const array = [ 1, '2', 3, true ]
// Pseudo code
array = []
array.add(1)
array.add(true)
array.get(0) // is 1

Behavioural Dualism in Data Types

array.add(5)
5.addToArray(array)
// Simple variation of List from JDK (just for Object)
public interface List {
int size();
boolean isEmpty();
boolean contains(Object obj);
Object[] toArray();
Object get(int index);
Object set(int index);
void add(Object obj);
void remove(Object o);
void sort(Comparator<? super E> c);
void clear();
/** many many other methods... **/
}
public interface Teacher {
void giveInformation(Student student, Information information);
}
public interface Student {
Assessment studyInformation(Information information);
}
public interface Student {
Information getInformation(Teacher teacher);
}
public interface Information {
Assessment processBy(Student student);
}
public interface Information {
void transfer(Teacher teacher, Student student);
Assessment processBy(Student student);
}
public interface Assessment {
void give(Teacher teacher, Student student, Information information);
}
// Pseudo code
Assessment assessment = givenAssessment(
fromTeacher, toStudent, forInformation
)

Behaviour does not belong to a data type

array.add(element)
array = arrayWithNewElement(array, element)
db.save(user)
user = savedUserIntoDatabase(db, user)
  1. We have only one single point of behaviour, which is a some function that can do the whole work.
  2. We don’t have to build (or implement) types from their behaviour, the only thing we need is data. And when it’s needed we can add functions that can process certain types of our data.
  3. We don’t have so called behavioural dualism in data types, where it’s not clear why certain types are attached to certain methods, because it’s no longer possible as we separate data from behaviour. It’s really important, because sometimes when we mix them, we often create meaningless types, which are not even in our business logic.
  4. Our code is decomposed. If we create proper functions, the only thing we need to do is just to pass arguments and to get result by invoking them.
  5. Our code becomes more declarative if we use proper naming of functions. And by proper naming I mean that we express the whole idea of behaviour behind the function, the result that we get from it and maybe even sometimes arguments which are required for the function. So, instead of thinking about how we build result, we actually see the result. For example,
List<User> users = filteredUsersFromDatabaseByAgeAndGenderAndWhoIsFriendWithSpecifiedUser(db, 25, 'women', someUser)

--

--

--

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Checking in at the Golden Gate

What is monitoring and why should we care

Evaluating a new Software Solution

Docker-compose for React, changes reflect real-time inside a container

Sharing State Between Cucumber Step Definitions Using Java and Spring

READ/DOWNLOAD$% Introduction to Programming with C

Debugging using WinDbg

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Guseyn Ismayylov

Guseyn Ismayylov

More from Medium

Why NRI Gotta Stop Pushing Foreign Values In India

From Teacher to Software Engineer

6 Lessons I’ve learned in the past 5 years as a software engineer

Where Are The Women?