Category Archives: Week 5

B5: Encapsulation

Encapsulation

        I chose a podcast this week to try and broaden my learning experience using different resources. This podcast talked about object oriented programming dealing specifically with the idea of encapsulation. It went through the basics of what encapsulation is and how classes, methods, and variables all connect with each other to hide data. The people on the podcast explained the differences that encapsulation can have between different languages but the basic idea is essentially the same. The overall syntax may change slightly but the idea of data and code being hidden from the user is still there. They then explain how the idea of a roadmap works well with this idea and how helpful it could be if other programmers are looking at the code. It allows programmers to understand what they can and should use in your code. They go over access modifies such as public, private, and protected where they explain that giving the user all the code can be harmful as that allows the user to change values that could end up breaking the program. They also use global variables to help show this point by saying they are not reusable and make it more difficult to track down errors.

         I chose this podcast because encapsulation is an essential part of coding in an object-oriented language like java. It allows the programmer to hide code that doesn’t need to be seen by the user to make sure that they can’t alter anything they shouldn’t. I have to admit that out of all the complicated podcasts I searched through, this one especially made it easy to understand java concepts. Coding blocks has a solid source of information and does a great job explaining how everything works using their own definitions for the somewhat confusing vocabulary. Although I already knew most of this information, it was a great idea to refresh on it because I had forgot all the vocab such as mutators and accessor methods which I just called getters and setters. Overall the content was very easy to understand due to the helpful explanations given by the people in the podcast. It affected and helped me by allowing me to refresh on encapsulation and encouraged me to go look at inheritance along with polymorphism again. This obviously will tie back to our class since we’re going to be using a lot of object oriented programming in java and using encapsulation to work on our projects. Encapsulation will have a big impact on my practice of code as it will help shape my design for how the code will look and what the user will have access to if I want them to only have limited control over the program.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.

Lesser–Known Java Syntaxes

https://blog.joegreen.pl/lesser-known-java-syntaxes.html

Today I stumbled across an interesting little blog post on lesser-known Java syntax. The author gives examples of code that doesn’t look like it would compile, but is surprisingly still legal syntax. For example, a two-dimensional array is usually declared like this:

int[][] arrayOfIntArrays;

However, since the brackets can be placed after either the type or identifier when declaring a regular array:

int[] intArray;
int intArray[];

A two-dimensional array can also be declared like this:

int[] arrayOfIntArrays[];

An interesting (although hard to read) application of this is that a single and multidimensional array can be declared on the same line:

int[] intArray, arrayOfIntArrays[];

This line of code declares an array intArray and a two-dimensional array arrayOfIntArrays. The second one is two-dimensional because the brackets are placed after both the type and identifier just like the previous example. The fact that another array is declared on the same line does not change anything. Although it is not very practical, it is still a very interesting use of syntax that compiles just fine. Similar syntax can be used when specifying the return type of a method. A method that returns a two-dimensional array would usually look like this:

int[][] fun();

But since brackets can be added to the end of the method signature, it can also look like this:

int[] fun()[];

Taking all of this to the extreme, a method that takes an array of arrays as a parameter and returns an array of arrays can be written like this:

int[] fun(int[] arrayOfIntArrays[])[];

Next the blog discusses the receiver parameter, which is a syntactic device for an instance method or inner class’s constructor.

class MyClass {
    public void method(MyClass this, int argument) {
    }
}

This code compiles and generates the same bytecode without MyClass this as a parameter. Currently the only use of this syntax is to annotate the argument.

The most commonly taught way to initialize an array is like this:

int[] intArray = new int[]{1, 2, 3}; 

However, the type of the array does not have to be specified twice. Instead, an array can be declared like this:

int[] intArray = {1, 2, 3};

But splitting this line of code into two lines will not compile. If the array is declared without being initialized, the new int[] must be included when the array is initialized.

I selected this blog post because I think it is very interesting and useful to see examples of code that don’t look like they should compile, but they do because there is nothing wrong with the syntax. It’s important for a software developer to know the ins and outs of the language they are developing in and knowing little quirks like this helps give a better overall understanding of the language. The more syntax you know the less caught off guard you will be when reading other people’s code, as nobody uses the exact same syntax in every situation.

I learned specific syntax from this blog that I will now understand if I ever see. These examples helped me better understand Java syntax in general, which will make it easier to read other people’s code and will make me less prone to errors.

 

From the blog CS@Worcester – Computer Science Blog by rydercsblog and used with permission of the author. All other rights reserved by the author.

Quality Assurance – The Most Important Aspect of Testing

A big part of testing is making sure that the product you are working on is going to be a highly reliable, quality piece of software. Quality assurance is a big part of testing as a poorly designed product could mean bad news later on down the line. Softwaretestinghelp.com recently posted a blog that dives into this subject.

The first thing that stood out to me in the blog was a formula: Quality assurance = quality control + defect prevention. This formal makes a lot of sense to be. One of the main goals of testing is making sure it works as it should and if it doesn’t making sure someone knows it needs to be fixed. That is the quality control portion of the equation. The second part, defect prevention, is preventing bugs from getting into the software in the first place or recognizing a problem before it happens. I feel if you complete testing with confidence that those two items have been completed, you have done your job as a tester.

Now, how might one go about making sure they hit the mark with the formula? First of all, reviews are a very important aspect. This includes design reviews, specification reviews, code reviews, etc. I cannot express the importance of reviews. Getting other sets of eyes on things are crucial to making sure nothing is missed. From my experience at work, reviews are done for anything and everything, and if a review isn’t done it usually sent out with a disclaimer that whatever is being sent out is a draft. It will bite you if you don’t. Another important step to meeting the requirements of the formula is logging any issues that may have been find when testing. Any issue, not matter how small, should be logged and investigated to determine the problem and if any action is needed. This relates to the next item of the list, which is finding the root of the problem. Often a bunch of little issues that have to keep being fended off are really due to some underlying issue. It is important to make sure that you find the real issue, and not just cover it up. Lastly, make sure as a tester you utilize the resources you have available to you, especially your manager. They have the ability to get you what you need and probably know that quickest way to get it. Most of the time they are more than willing to help as your work reflects on them as well.

This blog provided a nice intro into testing with quality assurance in mind.  I found their thoughts to be intriguing and will be on the lookout for more blogs like this one considering how important quality assurance is to a piece of software.

Link:

http://www.softwaretestinghelp.com/defect-prevention-methods/

From the blog CS@Worcester – README by Matthew Foley and used with permission of the author. All other rights reserved by the author.

What is Smelly Code and Why Your Code May be Stinking Up the Room

Code Smells. Kind of a strange phrase, isn’t it? At least I thought so while perusing Professor Wurst’s concept diagram. I decided to look it up out of curiosity and found some interesting information on it.

Well, what exactly does it mean? In short, code smells is basically code, trends, patterns, etc. that indicate there may a be an underlying issue with the code that could cause issues later down the line and/or is already causing problems. Now, that doesn’t mean the “smelly” code will always cause problems. It could be there for a specific reason. Perhaps it has to handle an odd scenario or something similar, but the point of knowing what smelly code is to be able to determine where there my be common issues or bad habits. In his blog at codinghorror.com, Jeff Atwood dives into some signs of stinky code…

Going through his list, there are several that stuck out to me. The first couple involve length. Long methods are trouble for several reasons, but perhaps the most important is they can be hard to read and trouble shoot. Atwood mentions that methods that are significantly longer that the rest of the methods in the class/program are often trouble and it is a good idea to break it into smaller methods if possible. He also mentions lengthy parameter lists. The more parameters, the longer and more complex the method is going to be. I have to say I agree with both of these. Nothing is worse than trying to read through an endless block of code. Items can get lost and users can easily get confused or lost while trying to decrypt what is going on.

Next on the list are “oddball solutions”. If there is a problem that needs to be solved multiple times, there should only be one way of getting to that solution within the code. There may be multiple ways to get to an answer (i.e. 5*1 = 5 and 1*5 = 5), but the way of getting to the answer should be consistent throughout your code. I agree with his thoughts here. Seeing two different equations to get to one solution could certainly confuse the reader. Not to mention that if the process is the same it should probably just be put into a method anyhow.

Last on the list this week are temporary fields. Make sure that all the fields are actually needed. Unnecessary fields can cause, you guessed it, confusion. The user may think they are needed for some reason and may deem the program to not work properly or something similar. Not to mention that fields that need to be filled out each time the program is run can be extremely annoying while trying to test, so you are doing yourself a favor by keeping the number of fields down as well.

Since I have found this blog particularly useful and insightful, I plan to continue with a part two next week, so stay tuned.

Link:

https://blog.codinghorror.com/code-smells/

 

From the blog CS@Worcester – README by Matthew Foley and used with permission of the author. All other rights reserved by the author.

The Clean Coder 9 & 10 Week 5

In the first section of the reading time management was discussed. One of the biggest time wasters could be meetings, they may seem important but many times they are not manditory. If you feel you are getting nothing out of a meeting, then leave. A big issue with wasting time is if you are not focused. Do your best to stay focused because if you’re not you’re not going to get anything done. A few strategies to help stay focused is take breaks, get enough sleep, drink caffeine, etc. I know if I’m tired and can’t focus it takes me twice as long as if I were focused.

The next section talks about estimations in your project. Theres a big difference between a commitment and an estimate. A commitment you must follow through with in your professional career, an estimate is a guess on your part and most likely will not be accurate. The best way to estimate tasks is to ask the people around you, they might actually know more about when you can complete a certain task. As a professional software developer you will become better at estimates, even though things could still happen that will throw your estimate way off.

From the blog CS@Worcester – Software Testing by kyleottblog and used with permission of the author. All other rights reserved by the author.