Hi! I'm back again, with another off-the-top-shelf software principles to recite before bed - literally. Introduction Throughout the software engineering lifecycle, practices have come and gone. Those that have stuck and those that have withstood the test of time have been the building blocks of what we have today. They've pushed teams and developers alike to better code bases and practices. Here we discuss a few of the most notable ones. 1. YAGNI (You Ain't Gonna Need It) In the , we discussed the endless stream of libraries and our need to know them all. last article Are you going to use it really? Another dead end? The libraries you are actually going to use are those that you stumble upon while looking for a specific need and problem to solve, not those that you blindly go online and scroll. 2. SOLID Not a state of matter. Coined by Robert C. Martin, SOLID is a software engineering acronym, broken down to: - Single-responsibility Principle S - Open-closed Principle O - Liskov Substitution Principle L - Interface Segregation Principle I - Dependency Inversion Principle D The goal of this is to make whatever that project you, as the engineer, is working on, be maintainable and extendable. Elaborate this. Single-responsibility principle A class or module should have one and only one function. For instance, we have a class that renders a GUI application, say a PyQt program. Lots of things are happening within this. Our program, in this case, streams our favorite music streams from source ABC, a video player of sorts. What about creating just one class for this? Seems simple enough, right? Well no. Beyond that corner of 'the program worked! ' lies a wet mop willing and ready to slap you in the face. As with any other program, we expect downtimes, a stream not found, and additional functionality. You get this gist. So break it down. Our single class cannot have all this all at once, make modules to work on error logging, make modules specific for the video player, a class-specific to listing our feed, and another to show history. If it can be small, make it smaller. Just do not overdo it and clear out the whole point of it. Open-closed Principle Objects or entities should be open for extension but closed for modification. A function, class, or module can be extended but not modified by an external entity. All notification services show a notification, but do all of them show an error notification? . Utilize polymorphism. Break it off All my error service needs to do is pass ABC to XYZ. The rest should be none of its concern. Pass it relevant info and let the rest be handled. Liskov Substitution Principle Derived classes must be substitutable for their base classes. Objects in a program should be replaceable with instances of their subtypes without changing the correctness of the program. Let's simplify this: what we mean is . if S is a T subtype, then Type T objects can be replaced with Type S objects Bear with me; A school application. We have a class that houses all the staff of an institution. As well, we have two subclasses - and , both of whom are still staff members. Staff Instructor Support staff As usual, we have our assumptions as to what properties and methods belong to what object. Following the same principle, we state the below: Do not enforce stricter rules in the subclass Using the example; we break the programming principle by stating, as a property that , must not only be an instructor, but also be an instructor of a specific institution. Pause a little and reason this out. class Instructor We are modifying the parent class from within the child. This is similar to saying a dog species class, say , modifies a parent class , , to have color red. We just break everything else that depends on that single class . We have, essentially, stated that all dogs are red, even though it is just this one species. Grayhound Dog Dog Interface Segregation Principle Make fine grained interfaces that are client-specific. We have a class, that helps manage our books. Creating an instance of this class is the same as interfacing with it. Library Take, as another example, an e-commerce platform. We lean towards microservices at this point. We have a database that houses our stall, an admin panel for the store owner, and the user navigation section, where our buyers get to see and hopefully purchase our products. As microservices, at the top level of this becomes: Admin panel microservice Client microservice(we assume our buyers are the users) Why should the buyer interface with the admin panel when they are not using it in the first place? Why would all that code be with them at that specific instance? Dependency Inversion Principle Depend upon abstractions, [not] concretions A higher class should always depend upon the abstraction of the class rather than the detail. A good example of this is the implementation of abstract classes in Django models, the Abstractuser model. In our application models, we would, upon migration, have models from classes inherited from it but have no table within the database to represent the abstract model itself because it's, well, abstract. You may note how: . High-level modules do not depend on low-level modules. Both should depend on the abstraction Details should depend on abstractions. Abstractions should not depend on details. A high-level module in any program is one that depends on others. We specify, I repeat, abstraction, an interface upon which we build. 3. DRY (Do not Repeat Yourself) Oh, duplicate code, where have you been? You have a piece of code from A that is exactly familiar to the one in C. You have a , (a  little web development for a while), across multiple pages. Repeating the same CSS styles and methods across those multiple pages. Why not make it a component in itself? Then tag it and write one CSS file and so forth and change data based on props? div 4. KISS (Keep It Simple, Stupid) Often engineers find themselves getting lost in algorithms and data flow other than the value the application will bring to the table. We focus more on 'features' as opposed to what the user will actually want our program to do. Conclusion Follow the software principles and remember to install libraries you actually need. No bloatware! Even on your current device. Do you need that app, or is it there for that one time you thought about it? Also published on . https://thegreencodes.com/software-engineering-principles-to-live-by

Flow

2022 - HackerNoon Contributor of the Year - Project Management

2022 - HackerNoon Contributor of the Year - Software Architecture

Portfolio

Buy Me a Coffee

Nominated for 2022 - HackerNoon Contributor of the Year - Project Management

Nominated for 2022 - HackerNoon Contributor of the Year - Software Architecture

Too Long; Didn't Read

In your car, at home, or at work — Bosch technology shapes many areas of life.

4 Software Engineering Principles You Should Know

Too Long; Didn't Read

Company Mentioned

Coin Mentioned

Marvin

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

4 Software Engineering Principles You Should Know

Too Long; Didn't Read

Company Mentioned

Coin Mentioned

Marvin

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES