Design Patterns and Anti-Patterns - RoR - Models

By Gowthamvel Palanivel

Elevator Pitch

Anti- what? probably sounds a lot more complicated than it is. Programmers were able to identify a useful selection of “design” patterns that frequently occurred throughout their code solutions. While solving similar problems, classifying solutions prevented from reinventing the wheel all the time.

Description

In this session, I’m gonna brief out on what software design, patterns, and anti-patterns can happen in the RoR applications. Followed by mostly identifiable anti-patterns in the Models and how to make use of the design patterns to eradicate such anti-patterns and have the code loosely coupled, futuristic, and easy to change.

The moto of this session is to have this style of coding as a practice for all the RoR developers community so that the code you write forces the others to follow the same principles to have it healthy.

So, there are no intended audiences, I’d say this should be practiced by each and everyone building, architecting, designing, or developing RoR applications. So it starts with the freshers to any experienced candidate who can attend the session and can inculcate and use them in their day to day development.

Notes

In recent trends, it’s been so easy to find anti-patterns in the code due to various factors.

So, I’ve planned to take this as a session to the community to emphasize the importance of Design Patterns in RoR application development and the benefits we get from using them.

In my point of view, that’d be one of the musts to be learned for an RoR developer. This will pave a way for them to write well-designed and clean code which is modularized and easy to understand.

I see myself as a good candidate to take over this session as I follow this in my day-to-day development and reviews thereby not only theoretical but practical implementations of all design pattern usages in the code and I’ve understood the importance of designing it right at the first time which helps us to have the code extendible further without having to modify the artifact.

I’d like to have this practiced all over the developers’ community to have the code clean and well designed.