--Originally published at Computer Systems Engineering
In this post I’ll be talking about the first chapter of the book “Head First Object-Oriented Analysis and Design” and what were my thought about it while reading it.
There is a lot of things that may come to your mind when someone asks you what is “great software”, for me the first thing that comes to minde is that THAT is the type of software i want to write. I’d love if I wrote a program that made other say “that is great software”. But I don’t have a clear idea of what it means. In the book they point out some characteristics of great software that can be:
- It does what the customer wants it to
- It is well designed, well coded and easy to mantain, reuse and extend
So, how do we make what we write “great software”? well, we build a program to do what the customer wants while using oop principles and make it readable, reusable and extendable. As simple as that right? Just in theory really, now I realize that a lot of the OO code I have written can’t be considered “great software” #shame
Reading more of the chapter I encountered this phrase: “Don’t create problems to solve problems” and, as obvious as it sounds, i found myself remembering all the times i did just that. I just wanted to make the program do what it was supposed to and be done with it, even if it meant hard coding some parts of it, because i didn’t have to worry about using them again, i’ll pass the course anyways (what a bad way of thinking i have).
It is vital to learn to plan ahead of time before going all in and start writting the code, we need to stop and think about
The example that is given in the book is easy to understand and to follow, we start with a hard coded program that barely does what the customer wants, he can have the inventary and… thats it. To fix the searches to be able to provide a result when looking for specific data is when we realize how much of a mess the app actually is. There are a bunch of strings as attributes of the class Guitar when they actually can bbe separate objects to make the code prettier and more usefull, basically to make it “great software”. We must separate each object and make sure it does only what it is supposed to be doing, if we need a method to perform an action and you don’t know in which class to put it, you most likely need to redesign your program to make it work. You can even breake or “encapsulate” the objects you already have to make it work better (this part actually surprised me, the way they separate the guitar specs from the Guitar object itself i found quite interesting to be honest).
Something I realized while reading the first chapter of this book is that we always need to plan ahead, sometimes I make my programs for the use that I’m asked without thinking that in the future i may need to add more features and modify other ones (some of my programs im sure I would have to start from zero if i wanted to expand them). And I think the reason why this happens to me is because I rush thinkgs, i have the idea of how to make the app in my head and start coding without laying out the idea in paper and se if it actually will work in an integral way.
Well, without much else to say, I just think I have a lot to learn in the future.
Thanks for reading!
#TC2004 #HFOOAD #Chapter1 #OOP
