Week 26 – OOP

Weekly Learning

This week we continue learning Java. Again, it’s a week were I’m trying to battle between what I am familiar with (weakly typed languages), and what we’re learning. I really like the immediate feedback of typed and compiled languages, and it’s something I had seriously forgotten about. There are small details on the implementation that make it frustrating at time: For instance, the fact that '' signifies a character while "" signifies a string. They’re minor inconveniences for the predictability and structure that typed and compile languages offer.

I also have to work on some of the older habits that I’ve acquired. For instance, throwing outputs around all over the code. On web development this is normally ok since they go to a logger, and they serve as checks in the code itself rather than for the consumer or costumer. But in a console driven program, or an application that requires the program to communicate with the user, the placement of the output, and the structure around is actually very important. These are good habits to learn and keep.

I have used a lot of OOP in the past. It really makes up most of my experience. Functional programming is portion big enough to understand and appreciate the different paradigm. I have always liked OOP, though I think functional does solve a lot of interesting problems in a more efficient way. However, it seems to start getting overly complicated when solving large issues, where objects can maintain a simple structure that can be extended. OOP is popular because it’s both flexible, accessible and efficient at solving problems. I’ve found working with both, that code in OOP is often more readable, and while there maybe a bigger mental overhead per function, there is a lost less for the program as a whole since objects and their structure can often be blackboxed.

On the other hand, UML has always been difficult for me. I can draw simple diagrams, but I have always felt unsure on how to properly break down the structures and how each step should be represented or the depth and detail of the diagram. I think I did a decent job for my video, but I personally would like at least a small workshop on that specific topic. I feel they’re incredibly tools that when done properly can convey the entire message with little to no mental overhead. But they’re also rarely used properly.

I hope we get to work a bit more with those tools. Part of having a proper program in place is to have technical documents behind it. Writing that sort of documentation is a skill all on its own and its something schools should also work to teach students.

This entry was posted in CST-338, CSUMB. Bookmark the permalink.