DRY – Don’t Repeat Yourself is a software development principle that tries to achieve “better” software from a coder and programmer point of view. It is arranging the programming code, separating the functionalities in files, folders, abstract layers, modules, libraries so to achieve some other better metrics – again deeply technical and coder related – change-ability, extensibility, testability, adaptability, speed, size, portability [to other software or platforms], readability [again – the code is changed by developer and how fast a new coder will understand it – is of high importance].
Most of my life I’ve coded with Object Oriented Languages so – this is what I’m gonna focus.
Design patterns – the core theory about code organization in the object oriented world can be found in the gang of four design patterns book – with Creational, Structural and Behavioral abstraction types.
Separation of concerns – it is high cohesion and loose coupling, but on a little bit higher level. It may include several files, several folders and even a whole library. It is software layer that performs only small number (maybe like 1) specific task and executes it/them well – fast and efficiently.
High cohesion – the idea is a method, a class, or a package to have minimal, specific functionality.
Loose coupling – When a software package does a job it needs some resources and other functionalities beyond itself. Having a unit not depending on any other units – you can call it is loosely coupled. Doing this is hard, many times even impossible, especially when the client requirements are high – you will need mixing up code. Our task is, having all above (and below) stuff – to make it as better as we can.
Coding with interfaces/APIs – a lot of design patterns and libraries try to abstract functionalities by making public and widespread what are the Input and what are the Output values of the class/library/service/whatever. Making it such creates a lot of responsibility to the developer to make expose sufficient number of input and output parameters, so any future requirements to not change and break the whole system. Coding with Interfaces helps hide the implementation specifics when a software module is required to integrate with others. Fixing bugs in the implementation or even changing it entirely – while not changing the API – will require just simple update, not whole system rewrite.
Dependency injection – DI is a development approach during compile time or even sometimes in run-time system – to couple modules together, many times with the help of being mixed with the interface that they expose and as such – making modules replace-able.
Semaphore. I’m seeing this design pattern a lot. It is wrapped around with different APIs, names or concepts – publish -> subscribe pattern, event/futures/callback driven development, Stream, Reactive APIs, listener design pattern. Kafka is an implementation of the pattern, also the Broadcast Receiver in Android. I’ve noticed it also in C# named there as Commands, The Plugin systems in the Cross Platform Frameworks are in many cases the same thing. Having functionalities bind together by a name/topic/very much like the URL address, and then the possibilities to pass in both directions stuff possibility to create very decoupled code, but also a mess of course.
User Interface and Business Logic separation – having the business logic in a service – not bound to the user interface or business logic consumer – opens the door for re-usability, by adding another user interface platform or other software system plugged without logic change. It also adds test-ability and separation of concerns.
Business Logic Code repeated between apps – Libraries exist for creating higher code reuse for common functionalities applied in a lot of places – is Internet Connection Available, Calling a Network Service, Encryption Libraries, and other stuff including:
User interface components repeated between apps – That is a thing that I’m noticing in every major app – even if the underlying implementation is different (web, native component or library). Its the material design components, the layouts, the repeating gesture concepts – like pull to refresh, swipe left/right (view pager), the drawer component and so on.
I also see – type of logic repeated between apps. CRUD operations on whatever data models you bring in – are repeated over and over again. You have a new programming language, newer framework, newer programming concept or paradigm, here is how to Read it with it. The same thing is with visual libraries – with newer frameworks and different target platforms popping up every day.
Even – If you stick to being a developer, there will be no escape of repeating. If you code for yourself, you could try to achieve some non-repetition thanks to owning the code between different applications and this way – nothing is stopping you to package the code into libraries and reuse them. And, if you code for a corporation – in every place there is different code owner – the corporation, or even the client of the corporation – and that will stop you from using the code – maybe the ideas, the abstractions, but most probably not the code. And this is repetition – targeting different private back-end systems.
And if you go outside – the smart thing is to try new things, until something, using the right approach – succeeds. And then – you should repeat it – applying it to new area. I’ll give one no-code repetition that has shown success by several companies – searching client satisfaction (and owning the back-end that they use). Amazon started with Books, they’ve collected a massive database of the purchases and made the recommend other books section – based on previous client experience. Similar approach is translated to music, videos and more. Focusing on what the client wants and needs – they made AWS – with Netflix as the biggest feedback giver and now they have a cloud package/container/virtual machine for whatever software functionality – including block-chain. The implemented repetition of focus on the client made them buy Zapos shoes company. And this is an example where the repeating thing is actually good.