Hello World?

Hello World,

Is that a pun? I’ll let you figure that one out. This blog was actually created 6 years ago and required some renaming and tidying up but now it’s purpose is to track my progression through the Computer Science curriculum. Starting now, as I enter my Junior year at the local state University. This blog will hopefully be revived, not only as instructed by my professor, but to be continued on my own to learn more about the subject.

Advertisements

Liskov Substitution Principle

Source: https://www.tomdalling.com/blog/software-design/solid-class-design-the-liskov-substitution-principle/

SOLID Class Design: The Liskov Substitution Principle written by Tom Dalling on Tomdalling.com is a five part series about the SOLID class design principles in OOP. He starts off with a problem about inheritance. For instance, if you had a penguin which is a bird that falls under an “is a” relationship. However, when the penguin inherits from the bird class, it will also inherit the fly method. As soon, as you set the fly function to do nothing, then it violates the LSP. Then Tom explains that from applying the Open Closed Principle, subclasses must follow the interface of the abstract base class. If the class has to be altered in such a way to account for certain classes then it also violates the Open Closed Principle of being able to extend a classes behavior without modifying it. In conclusion, two solutions are presented, one is adding a method to check for a flying bird or non-flying bird. The other which, he states as a better solution, would be to create separate classes to account for a flightless type, that way the fly method is not inherited from the superclass.

After doing assignments for CS-343 revolving around refactoring a pre-existing poorly implemented code by applying design patterns. I did not realize that we touched upon the Liskov Substitution Principle before reading the blog post. However, choosing this post, serves as a great source of review material upon topics covered in class. The assignment that incorporated multiple design patterns started off with a clear application of the LSP, as the original design had two instances of overriding to do nothing. However, the criteria for our first refactor requires the LSP and other inheritance reworks.  Since we were working with Ducks, you can imagine a QuackBehavior and a FlyBehavior, that incorporated real and inanimate ducks. So, the LSP application is similar to the second solution presented earlier, in which the fly and quack methods aren’t inherited from a superclass but rather an interface later implemented by the duck class. But even though the method still does nothing, it isn’t an override method, so it does not violate the LSP.

Like other OOP principles, these exist to help achieve code that is maintainable and reusable. By acknowledging the existence of these SOLID class design principles, it will hopefully prevent future projects from projecting these type of code smells. Also, by understanding them and utilizing them wherever they suit best, my code will be cleaner, easier to maintain and add new features.

Don’t be an Outlaw

Source: https://haacked.com/archive/2009/07/14/law-of-demeter-dot-counting.aspx/

The Law of Demeter Is Not A Dot Counting Exercise by Phil Haack on hacked.com is a great read on the applications of the Law of Demeter. Phil starts off by analysis of a code snippit to see if it violates the “sacred Law of Demeter”. Then proceeds to give a short briefing of the Law by referencing a paper by David Bock. He then proceeds to clear up a misunderstanding or usage of the Law of Demeter by people who do not know it well, hence the title of his post. “Dot counting” does not necessarily tell you that there is a violation of the law. He closes out with an example by Alex Blabs that when you apply a fix to multiple dots in one call, you effectively lose out on code maintainability. Lastly, he explains that digging deeper into new concepts is all and well, but being able to explain disadvantages alongside the advantages will show a better understanding of the topic.

Encapsulation as a concept introduced to me, is about encapsulating what varies. However, different applications like the Law of Demeter which is specific to methods. It is formally written as “Each unit should have only limited knowledge about other units: only units “closely” related to the current unit”. The example in the paper by David Bock makes it easy to understand where this is coming from with the Paperboy and the Wallet example. Having methods that have access to more information is unnecessary and should be left out. Also, letting the method have direct access to changes made by another method is a bad idea. By applying the Law of Demeter, you encapsulate this information which simplifies the code in one class but increases the complexity of the class. Overall, you end up with a product that is easily maintainable in a sense where if you change values in one place, it will apply across the board to where it’s used.

Although encapsulation is not a new topic, knowing how to properly apply encapsulation for methods through knowing the Law of Demeter should be a good practice. This would be remembering that “a method of an object may only call methods of the object itself, an argument of the method, any object created within the method, and any direct properties/fields of the object”. For example, knowing that applying the Law of Demeter to a chained get statements is a good idea. Also, the importation of many classes that you won’t use is a bad idea. With this understanding, although incomplete, I will hopefully avoid violating the Law of Demeter and share it with my fellow colleagues.

What is C4?

Source: http://codermike.com/starting-c4

Getting Started with C4 by Mike Minutillo on Coder Mike is a blog post introducing the C4 Model. The C4 model is a way of allowing users to communicate and describe software architecture. This model is composed like a software system that is made up of containers, that each have components that are then implemented by classes. Lastly, context which is basically a description of the parts of the system or their relationships between each other. These four, context, containers, components, and classes is what makes up C4. Furthermore, Mike goes in-depth in explaining how it helped his situation from starting from a blank white board. By starting with a context diagram, he is able to map out the different problems of their design and revise it for the next version. This process would be repeated until they are satisfied and can continue down the right path.

Tools are developed over time to solve common issues faced in society today, by not utilizing existing tools provided by to us today would be a waste. Learning about UML Diagrams, would eventually lead into learning C4 Model. This model also utilizes UML diagrams in the classes section for its intended use. The idea of being able to clearly represent and describe parts of a software system like the UML diagrams purpose for classes makes this a worthwhile read. The various models within the model such as System context is extremely valuable to me because it allows me to explain how everything pieces together from a higher-level view.

Much like UML diagrams, the author stated that it your initial diagram doesn’t have to be perfect, it’s going to change over time. The value of being able to show, explain, and revise is much better than time spent working out a grandeur solution. Utilizing the different diagrams will grant a much better time spent on projects certainly when there is no clear starting point like Mike pointed out. First starting with Context diagram will explain what things do and their relationships to each other. Then we can go into the container diagram, where you separate important bits into parts like a database or an app. From there I can then start grouping related functions into components which is then accompanied by classes explained using UML diagrams. These four diagrams will provide a nice guide for myself and group members during implementation and provides proper documentation.

Leaving a trail…

Source: https://blog.codinghorror.com/if-it-isnt-documented-it-doesnt-exist/

“If It Isn’t Documented, It Doesn’t Exist” are probably some words to live by, written by Jeff Atwood. Jeff expresses his thoughts on proper documentation based on his personal experience while working on open source projects. This can be summarized into a single sentence “Good Documentation is hard to find” as stated in the blog. However, he agrees on a couple of key points made by James Bennett who wrote the blog post Choosing a JavaScript Library. These can be summarized to having a proper overview of each section of your project/design, having proper examples of usage when needed, documentation on everything, and your regular comments throughout the code itself. Although it was specifically written for his javascript explanation, I attempted to apply it to regular java coding as well. Ultimately leading up to another great statement “most treat documentation like an afterthought” made by Mr. Bennett.

Truthfully, upon finishing and reviewing my own code for Assignment 1 in my CS-343 class, I realized that documentation or comments within the code is non-existent. Leading up to relearning the importance of proper documentation, as once taught in my CS-140 class. Currently, I can see that it is not a requirement and has not been a big factor in assignments even in other previous CS courses I have taken between CS-140 and CS-343. However, it’s important to remember that a properly documented project can be easily benefit yourself and others in many ways. For example, it can be used to assist in explanations or allow others to understand what is done at a certain point. Also, it can be used to help yourself pick up where you left off after reading up on what you have written. Simply stated as “…if you’re the only one who understands it, it doesn’t do any good” by Nicholas Zakas.

Practicing proper documentation techniques early on will help develop proper skills for determining how much is necessary to document. Too much unnecessary documentation will hurt more than documenting only what is needed, which is a problem I had when I actually applied documentation within projects. This also includes being able to understand when and where to use comments, javadocs, etc. throughout a project. Currently, I do treat documentation like an afterthought, to the point that it isn’t applied. In the future, I hope to apply this skill and use it to my advantage, not only for myself but for others as well.

Ouch, that’s sharp!

Source: https://blog.codinghorror.com/flattening-arrow-code/

Stumbling across this week’s blog post Flattening Arrow Code by Jeff Atwood, I found myself reading about arrow code, which is self-explanatory. Basically, Jeff explains how he deals with Arrow Code, which is considered an Anti-pattern that is deemed a bad practice and should promptly be avoided wherever possible. The main benefit from refactoring is to reduce the cyclomatic complexity value, this value being used to determine how complex a piece of code is. The larger the value, the higher the complexity, the lower the value, the lower complexity. Another would be, from Jeff’s words “…to have code that scrolls vertically a lot… but not so much horizontally.”

When I look at code, I never suspect that there would be distinct patterns that are deemed as a bad practice. By reading about arrow code, I first thought, “Hey, I’ve seen that before” but left with “Oh, that is probably not the way to go about writing code”. In other words, I should probably learn this now. Anti-patterns, although the only one focused on in this blog is the arrow pattern is a great way to help avoid certain practices in the future. Even though, as of right now, I don’t understand most of what he said about converting negative checks into positive checks or decomposing conditional blocks into separate functions. Other things like guard clauses, being a conditional statement at the top of a function that bails out as soon as it can. Which I assume contributes to reducing time spent/resources spent running that function. Also, includes the idea of not sticking to the idea that there should only one exit point at the bottom of the function. Sometimes, it can be possible to exit at a different point rather than the very bottom. These two points, are good information as standalone practices.

Using this simple example, I can see that it is like YAGNI, KISS, Code Smells, etc., which means by understanding or being introduced to the bad practices early on. One, I am able to identify and solve the problems using common strategies already developed and tested. Two, I will be able to avoid putting myself into those situations where I would need to refactor the sections to be easily modifiable and maintainable. Although cyclomatic complexity is mentioned scarcely in the blog post, it reminded me of time complexity in algorithm analysis. Even though they are two different concepts, understanding that aiming for a smaller cyclomatic complexity value should result in a less extensive testing phase for the code. Which should save time, for future reference of course.

Acronyms to Remember

Source: https://blog.codinghorror.com/kiss-and-yagni/

This week’s reading is on KISS and YAGNI by Jeff Atwood on Coding Horror. Jeff touches upon and shows enthusiasm towards effective practices of KISS (Keep it simple, stupid!) and YAGNI (You Aren’t Gonna Need It). He mentions that just because you learned something complex that could be applied to your current project, it doesn’t mean that you should implement it when there is a more simpler option available. That is the idea of KISS. Lastly, he mentions that developers should follow YAGNI to combat the mindset of implementing solutions that you don’t need currently.

These two topics about KISS and YAGNI are very interesting because of how people are usually taught to think but when applied to programming, it doesn’t help but make things worse. Choosing to read up on this blog, allows me to see how more experienced developers feel about those who do not understand or value the two practices. Also, this is related to smelly code as it will help fight against dead code! In this case, I can feel that it is indeed a wise choice to pick-up KISS and YAGNI early on. Although, I have yet to write much programs that needed complex solutions. I do remember situations where my implementations were much longer when compared to other students, which could be a result of lesser understanding upon certain fundamental topics or lack of experience. Example being, the other student’s implementation of a loop for a solution is much shorter but does the same thing as my longer loop. It’s not exactly KISS, but it does show that sometimes things can be done in a simpler way.

Overall, understanding or knowing either practice will help save time when it comes down to getting things done. By knowing YAGNI, I will not implement things I don’t need until it is needed. By polluting the code with unused implementations, it will most likely create complications for later functions when it is used. However, if I don’t need it by then, the time spent creating the implementation for the future would be wasted time and not saved time. Then we have KISS which is rather straightforward, but should be a clear reminder that it’s when you can keep it simple, not always keep it simple. These two concepts will help me keep the code clean, and maintainable to a point where implementing newer features will not be as frustrating as when you work with smelly code.

Diagram Dependence

The blog that caught my interest this week is Good Programmers Get Off Their Butts by Jeff Atwood on Coding Horror. This post was centered around the author’s experience with UML diagrams and his overall view about its practicality in the field. Jeff finds that spending too much time on the design results in very little time for implementation. Then if there is very little planning, there is also a drag in the time for implementation. Which leads to his overall idea that, even if the design is vague, it is better to write some code than furthering the designing process in UML. His experience with proper designing procedures is a great read for many of us, that have recently learned about UML diagrams.

I chose this blog post because after reviewing countless articles, it seems to conclude that UML diagrams are useful in certain environments/situations and not a definite approach to design. These include being used as documentation or to explain specific code to people. Jeff explains a couple that are concerns of mine. One would be repeatedly updating the UML diagram to keep the design up to date or coming across a large problem in the design during the implementation process and having to scrap the design because of it. I would consider these to be time-consuming tasks and would stall development.

However, his message wasn’t all bleak as he does believe that it is useful from his comment that “Coding without planning is just as futile as coding with too much planning”. This comes back around to having a short design plan, perform the implementation, and then pan out the rest of the design as you go. I do see this as a future tool I could use, as time is a valuable asset. Relying on completing a full UML diagram will show what you need to do in theory, but when it comes down to implementation, not everything will go according to plan. This will result in turning back to the diagram, in attempt to solve the various issues that could arise later. However, if you have a rough idea of what the direction the design should go in, during implementation the process of editing the diagram won’t be so painful as there is little to change. Overall, grasping the concept of UML diagrams and understanding that it is a useful tool in general, but can work against you if you are overdependent on them is great to know for future projects.