Monthly recap

I have talked about how every week went, here I’ll write about what was my path when preparing for the interview phase.

The first thing I did was to do a review about the topics I already know, like some Computer Science concepts, Registers, Memory, Data Structures, Big O notation, Programming Paradigms, Algorithms.

Sorting algorithms such as Quicksort, Merge sort, and even Bubble sort are the basic algorithms taught in college as well as the search algorithms like Linear Search and Binary search, actually it was mandatory in every career in my college.

It’s easy to talk about what I know but the purpose of the essays it’s to show what we learned.

There are 2 topics that even though I heard about them this is the first time I have properly studied it, the first one is the SOLID principle. I heard about those principles when I started practicing with the python framework, Django, when using this framework you can use functions or classes to write the MVC design. I started using the function way but as a project grown up the number of functions start to grow as well. Instead, using Classes allow us to use its properties like inheritance to reuse code. The SOLID principles establish a set of practices when developing software with consideration for maintaining and extending. To me the first three makes sense but the last two were a bit hard to wrap my head around.

The principles are

Single responsibility principle — A class should have only one responsibility. This is for example a class that accesses a database shouldn’t not modify it at the same time.

Open/Closed principle — Classes should be open for extension, but closed for modification. A class that changes it behavior will affect the system that uses that class

Liskov substitution principle— This may sound confusing at the beginning but it’s not, let’s say we have an object of type T and S that is a subtype of T. Then objects of type T can be replaced with objects of type S, without altering any of the properties of that program. For example if we have a Class created from another class, the new class should be able to do the same as the parent class otherwise the abstraction is wrong.

Interface segregation principle — Clients should not be forced to depend on methods that they don’t use. This was a bit hard to understand at the beginning due to how it’s paraphrased on some sources but maybe with this example it can be clear. If a class is required to do something that is not useful or even worse the class is not able to do that then there is no reason for that class to do that. Every class should only fulfil its role.

Dependency Inversion Principle — High-level modules should not depend on low-level modules. They should depend on the abstraction. Abstraction should not depend on details. Details should depend on abstractions. To understand this, maybe knowing what a high-level and a low-level module are. A high-level module is a class or module that executes an action with a tool. A low-level module is a class or module is the tool to execute the action.

This principle says that a class should not be fused with the tool it uses to execute an action, it should be fused to the interface that allows the tool to connect to a class.

The second topic is design patterns. When I first heard about this topic I thought it was about doing and reviewing a lot of code to be able to recognize a problem but it is more than that. Design patterns are categorized into 3 classes, Creational patterns , Structural patterns and Behavioral.

Creational patterns provide a way to create objects while hiding the creation logic, rather than instantiating objects directly. This gives the program more flexibility in deciding which object needs to be created for a given use case.

Structural Patterns: This concerns class and object composition. Concept of inheritance is used to compose interfaces and define ways to compose objects to obtain new functionalities
Behavioral patterns: Are specifically concerned with communication between objects.

There are advantages of design patterns:

• They are reusable in multiple projects.
• They provide the solutions that help to define the system architecture.
• They capture the software engineering experiences.
• They provide transparency to the design of an application.
• They are well-proved and testified solutions since they have been built upon the knowledge and experience of expert software developers.

Using design patterns can make code more flexible, reusable and maintainable.

Aside from the described above, every class has its subclasses which also require its time to learn and be aware that there is not a right design pattern for a problem and that it is possible to create a pattern for a specified problem.

Lastly I want to talk about Functional programming, to be honest it was more than I thought it was, I liked how they explained it, because more than just showing code, it went to the very concept of functions, pure functions, and the lambda calculus and the math behind those problem. It was just an introduction but is enough to start using this paradigm and get more involved with other paradigms.