Transparency is one of the Object Oriented Design Principles that helps developers keep the code readable and understandable.
When you look at the class or methods it should be very obvious immediately what it does, within the next 1 minute it should be obvious how it does what it does. You as a programmer should be able to understand the piece of code that you have written after several months even years when you look at it. Moreover, others too, should take the same amount of time that you took after 6 years to understand the code that you have written. For Example, when anyone looks at the name of a class and its member variables and methods they should understand what they do and how, without any effort.
The name of the class should explain what it does or what it stands for.
The name of the variable should say what it is used for.
The name of a method should explain the action that is performed when the method is called.
A method name should have a verb to make that happen.
The same goes for the name of the objects, they should say what they are used for and in which context.
Normally a class is named as a noun example Employee class.
As an example, an Employee class can have variables, to maintain the state of an employee object. When the task of the Employee class is to keep age, salary, name, department details of an employee then the variable names should be like age, salary, name, department. We should use the easiest name that identifies what the variables are for.
Here is another example for the methods. When a method increments the salary of an employee then name it like incrementSalary(). You can increment salary by providing an increment percentage or an adding a float amount to the existing salary. Then name them differently like
incrementSalaryByPercentage(double percentage)
incrementSalaryByAmount(long additionalAmount)
Now assume a department consists of 5 employees. and one of them is an IT manager, another is an accountant, another human resource manager and two programmers. You will create 5 objects of the same Employee class in the Department class. but name the name of each Employee object should explain their role like ITManager etc.
When you start creating classes, start from top to bottom. That means write the user interfaces first to provide transparency. Things like services, databases etc. should be at the bottom of the structure and written later. It should be done this way so that, even if there are changes in the technical layer like how to access the database it should not affect the upper layer.
This way just by following a good naming convention we can make our code easy to understand and transparent.
For the original post please refer to my blog
You can see similar posts in Object Oriented Design here
Top comments (0)