--Originally published at Computer Systems Engineering
Let’s get started with this LONG chapter 5 of the book.
Software needs to change, that is innevitable, let it be because some new features need to be added, some need to be updated, some need to be added, deleted, or whatever. They tell us to be ready for the change but in reality we are all panicked about change.
In object oriented programing a way we can prepare for that change in software is using abstract classes that can act as placeholders that when we put to use we can modify to fit our needs. The abstract classes defines the behaviour and the sublcasses are the ones that implement the behaviour.
Another alternative to make software chaengable is using interfaces, which makes it more flexible and addaptable, perfect for the case that the book brings up about needing to add various instruments, by creating an interface you can be ready even for those sublcasses that doesn’t exist yet but if you try to make your code bigger they for sure will be usefull to avoid code duplication.
Joke break. On the left we see how flexible we want our code to be, on the right we see how flexible our code actually is:
Encapsulation is important to leave some parts of your code unbothered while at the same time you leave some other parts run free for every change necesary. It’s vital to know and analize your code to diferenciate which will actually stay as it is and which will need an update every hour.
Everything is about following the OO design principles, make your code more flexible and think things trough. We shouldn’t be stubborn about keeping our design as it is only because at a given moment it worked, we need to improve and better to
Something i learned in another class was “Bajo acoplamiento, alta cohesión” and that is what Object Oriented software should be.
We need to be carefull when we build software so that it can be easily escalable. This doesn’t only apply to big pieces of software or for comercial things, it is indispensable even in the pieces of code we do on our own laptops everyday. It needs to be easy to read again, to understand again, to know which variable is which and why is the order like that and basically get it all as if it was the time that we wrote it. Sometimes we are guilty of naming things with names that don’t actually represent what we are storing because we were just looking for a short name for the variable, of we leave things that were used only for debugging but doesn’t actually do anything for the program, only make it look like a mess the next time we open it to the point we rather do it from scratch than trying to recycle what we already have.
You know, every time I read a new chapter of this book i realize how much of a mess me and my code and programs are
About our project: We constantly change the design of out project, everytime one of us thinks about another possible scenario we realize our previous design lacked to take that into account so we add those things to the design, that’s why use cases are so important. For example, how we were told in class that we shouldn’t assume that making an event on facebook will be a trigger and that the api would automatically update our calendar if they are connected, but that we should add a listener to check for new events every certain time for it to stay updated.
Anyways we will keep working and learning so i’ll see you next time with more of this. Have a great day
