Hello everyone, this is my introductory blog post for CS-343.
For the last couple of weeks, I’ve revisited a couple of the most important concepts of Object Oriented Programming, Polymorphism and Encapsulation. This is my final post for my CS-343 blog entries, and I have decided to continue in this trend. Today’s topic is Abstraction. This week I’ve gone to a favorite resource of mine, geeksforgeeks. Their article on Abstraction covers almost every question that comes up with Abstraction.
I feel it is best to first specify what an abstract class is, and how to make use of one. In Java, an abstract class is defined with the abstract keyword. An abstract class cannot be directly instantiated because of the abstract methods inside the class. An abstract method, is a method that does not have an implementation but must be present in all children classes. This is done via overriding the method(s) in the children classes. Only one method has to be abstract, meaning that there may be other methods that have complete implementations that are reused in their entirety by children classes. Similar to how we implement an interface, we extend abstract classes.
Like my other blog posts, I feel that the best way to learn a concept, is through examples. More importantly, the examples need to be practical, and ones we can relate to. For abstraction, the article on geeksforgeeks uses the classic Shape example that we’re all familiar with.
Our abstract class is the Shape, with three methods and one variable, or attribute. Each Shape has a color, getColor method and two abstract methods, area and toString. A Shape fits exactly into what an abstract class should have, and shows exactly what we can know, based on the object simply being a Shape. A Shape has to have a color, but the formulas for finding the area are different depending on the type of Shape, and the same goes with the toString method.
The children classes presented in the example are the Circle and the Rectangle. The UML from the original article even shows the extends declarator for the children classes. It’s important to note that the abstract methods are not rewritten in each of the children classes. This is because we have to implement them, and thus, they are carried over when we apply the extends declarator. The only new pieces of information in the UML are the attributes we can use for our abstract methods, radius for Circle, and length and width for Rectangle. As seen in the code blocks below the UML, these are used to calculate the area and then the toString.
Abstraction is one of the most important tools that any object oriented developer must have in their toolbox of concepts. This is used in almost every full scale application and often numerous times throughout. A lack of understanding of abstraction will lead to failure to excel in the software engineering world.
Original post here:
For my last blog, I revisited the important concept of polymorphism. For this post, I decided to revisit another important concept, encapsulation. I wanted to find a similarly formatted article/blog post to the one I found for polymorphism, but wanted to get a different perspective from a different resource. I wanted a source that still mixes in code examples,
Let’s start with the definition of encapsulation. Encapsulation is the ability to package data and related behaviors, in an object. This also includes the access permissions for the behaviors within the object. Encapsulation is often used a synonym for data hiding, but it’s important to acknowledge that while encapsulation includes data hiding, this isn’t all that encapsulation is. Everyone thinks of encapsulation as the concept of public versus private variable types. The concept of encapsulation does include this concept, but this is only one area that relates to encapsulation. When creating a new class, encapsulation should be a top priority. This is because with encapsulation, maintainability is drastically increased.
To further explain that encapsulation is not only data hiding, the article uses a classic coding example, an animal class. The class contains several attributes (name, type, height, color) and behaviors (hunt, run, mate, getName). Encapsulation is more than just making sure the attributes are private, it is about bundling the attributes and the related behaviors within one class. We could have the hunt, run, mate, and getName behaviors all in separate classes theoretically, but this would just be poor design. The article also notes that encapsulation is not about getters and setters. While these behaviors are related to the attributes, the authors wanted to make sure readers didn’t confuse encapsulation with this concept. Encapsulation does include getters and setters, but they are not the focus, instead we should focus on the behaviors that return a different value depending on the attribute, instead of just returning the attribute or setting a new value for the attribute.
To explain how I would use this in the future, why not explain how I would expand upon the code example used in the article? This code example in the article only includes hunt, run, mate, and getName for behaviors. If we wanted to add a speak functionality to our animal, we would use encapsulation. This might mean adding a new private variable, but also would include adding a new method that depends on an attribute or several. This behavior and additional attribute(s) would be added to our animal class to encapsulate the data and behaviors, and ensure the best maintainability for our codebase.
I found this article to be simple but powerful. It’s easy to forget that encapsulation is more than data hiding. Encapsulation is one of the major concepts of object oriented programming and complete understanding is necessary for success. I’m sure I’ll get interview questions regarding this topic in the future.
The original article: https://javapapers.com/core-java/java-encapsulation/
This week I found this article on JavaWorld by Jeff Friesen that is entirely about polymorphism. Polymorphism is a core concept for all software development and a lack of strong understand will lead to weak applications and poorly written code. One can never revisit topics like polymorphism too much. This article discussing the four types of polymorphism, upcasting and late binding, abstraction, downcasting, and runtime type identification (RTTI). The article presents everything in the form of a code example and constantly revisits in the explanation process, which I find incredibly useful.
The first part of the article is an overview of the four types of polymorphism, coercion, overloading, parametric and subtype.. Of these four there are some bits that stuck out more to me than others. For coercion the obvious example is when you pass a subclass type to a method’s superclass parameter. At compilation, the subclass object is treated as the superclass to restrict operation. The simple example that is forgotten is when you perform math operations on different “number” data types like int’s and floats. The compiler converts the int’s to float’s for the same reason as the subclass to superclass object. Another piece in this first section that stood out to me was the overloading type of polymorphism. The obvious example here is overloading methods. In a class, you can have different method signatures for the same method name and each will be called depending on the context. Again, there is a simple example that is overlooked in the operators like “+”. For example, this operator can be used to add int’s, float’s, and concatenate Strings depending on the types of the operands.
The upcasting section uses our favorite example, different types of shapes and is almost entirely written in reference to one line of code, Shape s = new Circle(); This upcasts from Circle to Shape. After this happens, the object has no knowledge about the Circle specific methods and only knows about the superclass, Shape methods. When a shared method (implemented in both Shape & Circle), the object is going to use the Shape implementation as well unless it is clear through context to use Circle’s. Similar to this section that uses superclasses and subclasses, is the section on abstraction. The article uses the Shape and Circle example again but points out that having a draw() method that does something in Shape does not make any sense from a realistic standpoint. Abstraction resolves this, meaning that in an abstract class, there is no way to instantiate a method like draw() for the superclass of Shape. This also means that every abstract superclass needs subclasses to instantiate their behaviors.
These are just a few parts of the article that stood out to me personally. The article as a whole is incredibly useful and worthy of a bookmark by every developer. I will continue to revisit this article if I find myself lacking confidence about the topic of polymorphism in the future!
What is DRY code? I’ve heard the term before in some tutorials but never knew the meaning behind the phrase. I figured if I keep seeing it, it must be important. After searching around the web for a bit, I finally found a great article on what DRY/WET code is on softwareyoga. The article explains what DRY/WET means, the advantages of DRY code, and the precautions to take when considering this principle. DRY code means “Don’t Repeat Yourself” and WET means “Write Every Time”. Obviously, DRY is the one everyone should wish to achieve for most cases. The advantages that the article goes through are maintainability, readability, reuse, cost, and testing.
DRY helps make code more readable because logic is not repeated throughout multiple classes. Instead methods/functions are called and what is likely hundreds of lines of code is represented by a few function calls. Readers of the code base can find the logic, read it once, and understand how it functions. Then when they see it implemented, they do not need to double check that the logic is the same. If code is WET, the logic will be re-written entirely, forcing readers to ensure nothing is different in each implementation.
Reuse and Cost go well together as reuse lowers the cost of development. When reuse is the goal/option, cost is inherently lowered. These go along with maintainability as reuse means that the code is properly maintained. If code can be reused, this means that small changes to the logic are less likely to cause problems. There would also be less time spent refactoring code in the future if previous implementations are written with DRY in mind. This means that less time, and developers are needed to maintain a long-lasting codebase.
Testing is simple, if the source code is written DRY, writing the tests DRY only makes sense. This also makes tests easier to write, and easier to change in the future.
The cautions for DRY expressed in the article are rather self-explanatory. One of the pre-cautions is to not over-DRY your code. Basically, this means to only use DRY when it makes sense to use DRY. If the code doesn’t need to take advantages of what DRY offers, it likely doesn’t need to be written with DRY in mind.
DRY is a great principle to follow when writing code. It teaches good practice and can be applied to most of the design patterns that we are learning. Most of the design patterns build upon each other and do so to keep code DRY. Implementations are written without rewriting logic and instead only require simple method calls. I hope to keep my code DRY in the future. If I do so, I will find it much easier in the long run to both add to, and learn from my previous projects.
Here is the link to the original article: https://www.softwareyoga.com/is-your-code-dry-or-wet/
This week, I decided to tackle the idea of frameworks. I personally have messed with Bootstrap, Spring, and Node/Express. Even with some experience tinkering around in these frameworks, I still did not quite comprehend why they are such a required skill to develop in their respective languages. I chose this article because everywhere you look in the software development world, everything is about the latest framework. This can be from blog posts, tech articles, and most importantly, job postings. Everyone is expected to know a major framework for the language that is listed as a required skill. This article I found on InfoWorld, tackles what makes frameworks so powerful and why they are the foundation of the future of software development.
Probably the biggest point that this article is trying to make is that syntax does not really matter anymore. One of the secondary points to back this is up is the idea that architecture should be the focus instead of the minute details of the syntax of a language. The focus should be on how to utilize existing libraries/frameworks by reading the documentation and figuring out the little details as you go. Personally, when I first started writing code, I focused excessively on the syntax of Java instead of understanding data structures themselves. This is a good example because most of the data structures we use in practice are part of the Collections framework within Java. A strong understanding of this framework has helped me write better code more efficiently.
Another secondary point that the article makes to back up the idea that syntax is dying is the growing area of visual languages. This was completely new to me, as I would not really consider visual languages to be part of the software development process. It is hard to ignore the growth in products like SquareSpace, Wix, and tools like AndroidBuilder. While Wix and SquareSpace are not exactly what the article is referring to, I feel that it is important to consider these tools regarding visual languages. These tools alleviate the need for developers for small business owners who only need simple websites/web applications. I’m not too familiar with AndroidBuilder, but from the article, I can gather that this is more of a tool for a developer to manipulate. I do agree with the article that while visual languages will continue to grow, they will never replace the traditional means of creating applications. This does however, mean that they diminish some of the need for learning nitty-gritty syntax.
For this week’s blog entry, I found an article on the SOLID principles that I found to be rather interesting. The article teaches and reinforces the popular object oriented principles that have stood the test of time in a way that other articles have failed to do. This article explains the programming definition and relationship with each principle, then applies a real-life example to further illustrate each principle, which is why I chose it. Instead of breaking down every principle, I’ve decided to highlight the ones that stood out to me the most.
For the first principle, “S” the “Single Responsibility Principle”, the article explains that this principle states that each class should only do one thing and uses the duck boat as a real-life example of people failing to follow this principle. The duck boat tries to be both a car and a boat instead of serving one purpose, meaning that maintenance is doubled. When trying to maintain an application, if a class serves many functions, finding where a bug lies, and even just properly maintaining the application becomes inherently more difficult if each class is trying to do too many things at once.
“I” for “Interface Segregation Principle”. This principle explains that it is better to have five smaller interfaces than one monstrous one. The article uses the idea of a soup of the day on a menu not being important enough for everyone to be listed on the menu every day. If this was the case, there would need to be a different version of the full printed menu for each soup of the day, each a new implementation of the “menu” interface. By keeping the concrete detail of what the soup of the day is off the menu, this allows the restaurant to use a different interface for the soup of the day, asking the server. I feel like this principle has strong ties to the “S” principle. If interfaces are kept segregated, they become cleaner and seemingly, keeps the responsibilities of the implementations more precise.
These two principles along with the other three form a strong list of guidelines for any developer to follow when writing object oriented applications at the very least. This article’s use of real-life examples is what separated it from the rest of the pack and is why I’ll remember what each letter of SOLID stands for. I know I’ve violated several of these principles in the past but I hope to follow these principles when writing applications in the future to help future-proof my code and become a better developer overall.
Here is the link to the original post/article. https://dzone.com/articles/the-solid-principles-in-real-life
This week I decided I wanted to read a blog post as opposed to a podcast for my blog entry. I went to the slack channel and found an article posted by Jason Knowles on writing clean code. Before reading the article, I knew had a general idea of what clean code was supposed to be, but lacked depth in understanding. Clean code is tremendously important in becoming a strong software engineer. Without a good understanding of writing clean code, a developer will never be successful in effectively contributing to a team. My goal and reasoning for choosing this blog post was to get a better idea of what clean code is exactly and how to work towards consistently writing it.
The blog post opens up a general overview of what clean code is and it’s importance in software maintenance. This flows into the main portion of the post, which is the practices to follow to ensure that one’s code is clean. The post ends with a few sections about code review, pair programming, and other resources.
One of the areas in the post that stuck with me the most is the topic of methods/functions performing a single operation. If a method performs multiple operations, it is probably a good idea to split this method into two different calls. This concept relates to the idea further discussed in the post about inline code VS function calls. The writer identifies that there isn’t one perfect solution for every given problem. In some scenarios, inline code is a better solution than creating a function/method to solve an operation. What comes to mind immediately to me is situations where a few operations will clearly never be needed elsewhere in the application and writing a longer method/function once will make future maintenance and understanding easier. The scenarios where method calls are better seems to be the vast majority of the time.
Another area in the post that caught my attention is the area regarding comments. The writer discusses the idea that comments are often a sign of poor code. This caught me off guard as I’ve always used comments as a way to remember what a function does for future additions and changes to my applications. The author writes that “comments should explain where code cannot” and that comments should be used to explain unconventionally written code. From reading the rest of article, it seems that if the code is written unconventionally, the comments are still a cover-up for poorly written code. This may be a poor code base that the current developer is simply writing an addition to, but does not have time to fix a poor code base.
In my first couple of years as a CS major, I have struggled with writing clean code and I feel that this article will help me in the future to write, scalable, easy to maintain code.
For anyone interested, here is the article this post is about.