Category Archives: Week 1

Object Oriented Programming

This blog post is going to be about one of the most important concepts in today’s world of computer science and it is object oriented programming. The reason I chose this topic is because it directly relates to course material and is fundamental for most computer science students.

I’m going to first start of by explaining the basics of objected oriented programming and try to bring some clarity to people who are either new to coding, or want to learn about a different mechanism of coding. Now keep in mind, there are many different ways to code and different approaches one can take on his specific journey. Now to the outside world of coding, they might think it’s all the same. However, specific types of ways to code include objected oriented programming, functional programming, procedural programming, logical programming, etc. I will expand on this later when I talk about my real life experience with some different ways.

Essentially, object oriented programming consists of object which are created by variables and methods. It consists of many objects who are collected and arranged in a specific class for unique uses based on the person’s needs and end goal. The four main concepts of object oriented programming include encapsulation, abstraction, inheritance and polymorphism. Encapsulation is choosing to limit certain object’s information to be seen by everyone in a way to protect information. Usually this is done by using a private access modifier. Abstraction is similar to encapsulation, except it hides properties from everyone in order to make the outside code a lot more simpler and understandable. Not everyone needs to know the broad details behind the object and helps keep things from causing problems on the main front. Inheritance is when a subclass basically inherits its properties and methods from the parent class. The main objective of this is to reduce redundant code and make things easier to use. Polymorphism is when an object can have multiple functions and change methods through the process of overriding and overloading.

Now the most popular programming languages today are objected oriented programming such as Java, Python, C++, etc. Now two languages that I have had experience with was Java and C programming. Java is an object oriented programming language, whereas C is a functional programming language. When I was learning Java, I never understood the big deal with Java and object oriented until I learned C and saw how not as much could be done. Java is much better equipped for real world projects as it makes code very reusable, simpler as well as saving memory. With C functional programming, there was more code to write for accomplishing simple tasks and also there was less security with direct access to memory. Overall, going into the future I am going to improve my java skills and be more equipped with the simple as well advanced concepts of objected oriented programming because of the many types of projects that can be created with it.

To read more info on object oriented programming link which I used as a reference here is one:,basics%20of%20a%20computer%20program.

To read more info on different ways to program this is a another link with helpful information:

From the blog CS@Worcester – Roller Coaster Coding Journey by fbaig34 and used with permission of the author. All other rights reserved by the author.

Integration Segregation Principle

This blog is about the Integration Segregation Principle (ISP) based off of the “SOLID: Integration Principle” article by Anu Viswan. This topic relates to the course (CS343) because we will cover SOLID, a combination of principles which contains ISP.
Integration Segregation Principle is about organizing your interfaces in a way where you will not be implementing methods that are not needed in your subclasses. The example given in the article by Viswan contains an IPrinter interface with an All-In-One Printer class and an Economical Printer class. The example that shows bad technique in ISP displays the IPrinter interface with three methods: print(), scan(), and copy(). For the All-In-One Printer class this is fine since as it has the functionality of all three methods. However, the Economical Printer class only prints. This leaves us putting exceptions in the scan() and copy() methods. This could lead to a violation of the Liskov Substitution Principle and is also known as a “fat interface” or “interface bloat”.
This problem is most noticeable when each of the implementations have separate assemblies. When making a change in the interface, all of the assemblies have to be rebuilt even if it seems as there is no change in their functionality. ISP reduces the impact when making changes.
The example of the correct way to build the IPrinter interface as given by Viswan would be to create smaller interfaces with an IPrinter interface containing the print() method, an ICanScan interface containing the scan() method, and an ICanCopy interface containing the copy() method. Now, the Economic Printer class can implement only the IPrinter class with the methods it supports. Meanwhile, the All-In-One Printer class can implement each of the new interfaces giving it all the additional features.
One side note about this example that Viswan added to the end that I found important to clarify is that this does not mean that all interfaces should have only one method but that we should understand the responsibilities of the interface.
I chose this topic because I think it is an essential rule to follow in order to have a solid and well-rounded class hierarchy that will not cause problems down the road. I chose Viswans article in particular because the content by Viswan on the rest of the SOLID principles seem very reliable, accurate, and well thought out. This will be of great importance when designing our final projects for this course.


From the blog CS@Worcester – Austins CS Site by Austin Engel and used with permission of the author. All other rights reserved by the author.


In my first programming course, I asked my professor how important it is that I learn Object Oriented Programming (OOP). He replied by saying, if I want to program anything, I must learn OOP. Being a freshman then, I took that lightly until I started coding and did not understand what I was doing. It was then that I realized how important it is to learn about OOP and utilize the concept in my program. As students especially beginners in programming, we are so geared towards completing programming assignments, projects etc that we fail to really understand what is used to structure a software program which OOP is basically about.

I selected this specific blog post because it talks about OOP and what it entails. The blog explains OOP as a programming paradigm that relies on the concept of classes and objects. It provides the importance and reason for OOP. It also explains classes, objects, methods, attributes and provided some examples, code snippets and OOP structure. I believe that this is important to know especially for new programmers, to better understand, and help structure their programs as well as others. The blog also explains the principles of OOP which is inheritance, polymorphism, abstraction and encapsulation. It provides code snippets of how each of these principles are seen and employed in codes and programs. It also provides a table that summarizes each concept.

In this blog I learned more on inheritance that it supports reusability. I learned from previous programming class that subclass can inherit all attributes of its parents class and add more attributes but little did I know that subclasses do not have to redefine methods that are already defined in parent class. When a method is called, it goes up to the child parent classes to find where that method was defined. It used to be a common mistake in my programs as I would redefine methods from parent class in subclasses and I never clearly understood why I got errors.

Also, I learned on encapsulation that, it hides the internal software code implementation inside a class, and hides internal data of inside objects. After reading this, I am sure to employ this method to hide information that I would not want to change in my program or code. In the past, I wasn’t able to understand the difference between protected and public codes when I see them, other resources made it very ambiguous for me to understand. However, thus blog provided a simple, easy to understand difference between them. Public codes are those that can be accessed by other classes in the program and protected are those that can only be accessible to subclasses.

I hope beginner programmers will find this blog helpful. For continuous programmers, this blog will help broaden your understanding and knowledge of OOP like it did to me.

From the blog CS@Worcester – GreenApple by afua3254 and used with permission of the author. All other rights reserved by the author.

Object Oriented Programming

I would like to start my blog with a concept that is known for all computer scientists around the world. OOP or the long-term Object-Oriented Programming.  The OOP has been around since 1980, but unlike trendy fashions and video game characters, this programming model is still going strong after these many years.

When I was first introduced to OOP, I felt like I was never going to learn it. But like wise people say, practice makes you perfect. Most of the courses in colleges requires a good understanding of the OOP. In the CS-343 course we have to perform object-­oriented design and programming with a high level of proficiency so OOP will be a key in our projects that we are going to develop. You cannot develop software for mobile unless you understand the object-oriented approach. The same goes for serious web development, given the popularity of OOP languages like Python, PHP and Ruby.

You have decided to learn object-oriented programming, but you don’t know where to start. Object-oriented programming has so many concepts and features. The whole thing can feel overwhelming at times. It is easy to make mistakes when you construct a program using OOP. So, what to do When everything goes to hell? Duplicate and rethink.

Abstractions are tricky. When used properly, they can help you maintain your code over time. However, a wrong abstraction can add a lot of unnecessary complexity to the project and trap you in an even worse maintenance hell.

So how to avoid the wrong abstraction? How to recognize when an existing abstraction isn’t right for us anymore? And what can we do about it at this point?

When I made that mistake and I was looking for any information how to fix it, I found a good blog that gives you good directions on what to do next. Object Oriented programming requires thinking about the structure of the program and planning at the beginning of coding. Looking at how to break up the requirements into simple, reusable classes that can be used to blueprint instances of objects. Overall, implementing OOP allows for better data structures and reusability, saving time in the long run.

I have attached the link for you to read and have a better understanding. It is easy to get lost in coding, but the important part is that you still can get out of it. I hope this blog helps a little with your programming problems and make your life easier.

From the blog CS@Worcester – Tech, Guaranteed by mshkurti and used with permission of the author. All other rights reserved by the author.

Test Driven Development

As I progress more in my CS studies, I’m starting to move beyond learning how to write the code for a project to how the project should be designed overall. In fact, this is one of the main purposes of two of my current CS classes. This has lead me to learning about TDD, or Test Driven Development. I’ve come across a fantastic article by Andrea Koutifaris which outlines the concept well called Test Driven Development: what it is, and what it is not.

In this article, I’ve learned the purpose of writing test driven code and what the plan for doing it should be. In TDD, tests come first in the process while writing production code comes second. This is in order to almost put oneself in a user’s shoes. If I myself in the user, what do I want my code to do? This is where the tests come in. Once the goals are clear and defined, the production code can be written.

The rules for TDD can be broken down to two essential parts:

  • “Write only enough of a unit test to fail”
  • “Write only enough production code to make the failing unit test pass”

Tests must be written to be very specific and achieve the ultimate application goals. Analysis of your tests can help you determine a method to writing your production code. They often not only outline what need to be achieved, but how it needs to be achieved.

The next part of TDD would be writing production code. As outlined before, the second essential rule of TDD is to “Write only enough production code to make the failing test unit pass.” Had production code been written first, output may not match user goals and unnecessary code may be written, which comes with its own set of problems. The focus is on writing clean code and limiting the amount which you write.

The last part of TDD would be the “refractor phase.” This is where code can be changed to be better, but what is stressed here is removing all duplicate code and consolidating.

The result of TDD should be efficient, clean code which serves its purpose. Although it can seem long-winded and like extra work, it’s mostly just inverting the process which we usually work by, so once the process is learned and practiced, it can help with writing better code more coherently and more focused on user goals, which is the ultimate goal as a programmer.

From the blog CS@Worcester – Marcos Felipe's CS Blog by mfelipe98 and used with permission of the author. All other rights reserved by the author.

Craft over Art

For this week’s pattern I have chosen “Craft over Art”. It describes of the pattern where you are given a problem and you are solving it for a customer. You can do it the simple and tested way or create a new solution that will let you express yourself as a programming artist and will look nice on the resume. It describes the conundrum of making something simple and useful right away or making something beautiful and complicated and not usable right away.

I have chosen this pattern because I have struggled with it many times before in my professional career. Many times have I been given a problem to solve for a customer and I had to decide to make it the quick and easy way that I already know will work, or should I do it some new, more complex way that can possibly save some time in the long run. The way that the “Apprenticeship Patterns” describes it should be done with a mix of both solutions, make it somewhat easy but tested way but with possible improvements. I think this is a good approach but there is a catch to it in my opinion, what is acceptable to the customer? Can they wait for a different, nicer way or quick, not totally efficient way will suffice? I think in the moments like that it is up to a Project Manager or the customer to decide and anybody working on this should act accordingly.

We as programmers and developers are in the end a service providers, unless we work for ourselves and do not have any hard deadlines, we need to stick to timelines and or project deadlines. What works and is tested very often is the right solution because time spent on implementing new solution can be something that ultimately may cause a project to fail and nobody wants that. The book also says that we as craftsmen need to provide at leas a minimal level of quality, and I think that if something is well defined and tested and works has that kind of quality. Why go for a new fancy way that might now work 100% of the time, or it requires a lot of time to be understood by somebody else. My boss likes to remind me that “if it is not broken do not fix it, because you will only cause more headaches to yourself and somebody who will work with my code later”.

From the blog #CS@Worcester – Pawel’s CS Experience by Pawel Stypulkowski and used with permission of the author. All other rights reserved by the author.

CS-499: Independent Study Introduction

This semester, I’m building an Android app for an independent study.

The Proposal

After building a breadboard computer and beginning to understand electronics, I started to learn about audio electronics. This sparked (or reignited) a latent interest in audio processing. Working in a call center selling audio equipment is actually the reason I was motivated to return to school to study computer science, so I feel there is good reason to pursue it in my final semester.

I also began with Python, and moved to Android apps in my early programming learning process, so I’d like to refresh these skills and dig deeper. This project will serve as a constant reminder to how far I’ve come from those early struggling days.

So the app will use Python machine learning libraries to analyze user audio data and provide the user feedback based on this data. I am purposely being vague; not because I think I have the next big idea on my hands, but because I expect many changes as I struggle with the machine learning model.

Regardless of where the model winds up, this is a software development independent study. I will have a working, professional app within the next 4 months, using the technologies I have proposed.

The Motivation

Why, though? As an independent study, with an already-busy schedule, I’m going to have to set aside time each week when I work on this project, no matter what. Originally, I wanted to take Robotics this semester and I was signed up for it originally, but unfortunately there is not enough time in my schedule. On Tuesdays I’m sure I will find my mind wandering, dreaming of playing with robots instead of struggling through machine learning and Android Studio.

But that is part of my reasoning. I want to find the motivation to do things with a self-imposed deadline. These are tools I want to learn, to create and potentially sell a product. At the end of this degree, I want to be able to show a project to future employers that say, “this is what I did. Not because I had to, but because I enjoy it”. I want to be able to have users who give me unfiltered feedback. I want to fail, figure out why I failed, and eventually succeed.

Of course, I have done all of these to some extent already. But this is my following my current interests and goals.

The Progress

I have made a couple small spike projects to begin relearning Android and get started with Tensorflow. I have already built the back-end and gotten an app to communicate with it. I’ve also done basic user authentication.

When I first proposed this project, I set a schedule of features and tasks to complete. Due to other projects which used the same technologies and flashes of motivation I’ve already worked ahead a bit, but I still plan to complete each portion according to the schedule, as best as I can. The machine learning model will be concurrent work as I adjust it.

Next week, I will go into more detail on the tasks I’ve completed so far.

From the blog CS@Worcester – Inquiries and Queries by James Young and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns Introductions

After reading the Apprenticeship Patterns book introductions and a few of the patterns, I have to say they are very straightforward, which the book itself admits. The utility in reading them is that is is very easy to forget these ideas, or never apply them to your work.

I was ready to condemn the book from the beginning, as it introduced the idea of apprenticeships in medieval through industrial revolution times. I thought to myself how naive it is to write a book about such bad situations, and that the authors must be romanticizing this time. This thought was immediately shut down as I read the line, “we believe it is possible to reject the romantic fantasy”, in favor of something better. This served to drive further points home, as I had just fallen victim to some of the behaviors it warns against.

This book describes patterns that “are tools that solve one set of problems and create new ones.” And it says that “the trick is to use your judgment to choose the problems you prefer.” I love this idea because it illustrates the fact that one doesn’t need to be able to solve every problem if you can figure out how to solve it with the tools already at your disposal.

At the same time, it provides a framework for learning more tools. The idea of “exposing your ignorance” stands out most, because most of us want so badly to be intelligent and competent. Having spent some time in the workforce without a degree, I have become sensitive to this: trying hard to prove that I’m not “dumb”. Maybe it was actually that, that had slowed me down.

On “Emptying the Cup”

It’s always a good reminder that you might not know as much as you think. Or if you do, that you might be biased and closed to new ideas. I am very proud of some of my work, having had moments where I feel like a programming God, and in the face of a new technology, I am always humbled. But I feel that I run the risk of using my past professional and education experiences get in the way of new methods.

On “Accurate Self-Assessment”

I had to read some of these patterns, because I tend to self-assess in the negative direction. I already usually assume I’m “the worst”, or that my work isn’t good enough, and seek improvements. Still, the patterns themselves are useful, describing how to solve this problem. I tend to spend too much time assessing. I need to consciously tell myself to move on to new things, rather than dwelling on what has been done and how it can be done better.

…And Onward

My capstone team has been discussing learning some new technologies, and these introductions have lessened the fear of diving in and trying them. At the end of my college career, I have been reflecting on what I could have done differently, or how I could have done it faster, so this book comes at the perfect time.

Haven’t we all sometimes wanted a chance to start over again? How exciting to have a chance to be at the beginning of something.

From the blog CS@Worcester – Inquiries and Queries by James Young and used with permission of the author. All other rights reserved by the author.

Introduction for CS-448

This blog will be following my cs-448 class for this spring 2020 semester.

From the blog cs@worcester – Zac's Blog by zloureiro and used with permission of the author. All other rights reserved by the author.

What’s That smell?

A topic that caught my eye when looking over the syllabus for my CS-343 class was Code Smells, so I decided to delve deeper into the topic. I read a blog post titled “CODE SMELLS THAT ARE FOUND THE MOST” by Ekaterina Novoseltseva, which talks about commonly found design flaws in code and how to address them. Ekaterina goes through a list of those design flaws like the bloater which are code, methods, or classes that are too large or have grown too large making them difficult to work with. Another mentioned design flaw would be the change preventer, which as its name implies prevents change by making the coder change multiple places in order to fix/change one section of code. There are many more examples of code smells that are explained in the blog.
One of the code smells that stood out to me was long methods because for a while that was something I would do while coding and it made my code almost impossible to track and understand, as well as, made it hard to trouble shoot where my issues where when my code did not pass test classes. Having long methods made coding extremely difficult and created more problems than it did good. another code smell that really hit home was duplicate code, even though it is easy for me to just copy and paste the same code into multiple methods, it makes more sense to create a single method that can be used in multiple places. simplification of code is something that I have been working on because it makes coding a lot smoother and easier to adjust and make changes to in the future. The last code smell that really spoke to me was dead code which is code that is not being used. Too many times I find myself writing code that is too complicated or doesn’t work, and then commenting it out or saving it for future changes and usually forgetting about it which makes it all the more confusing for some one reading or looking at my code. learning more about code smells has given me the confidence and knowledge to avoid them in the future and to make simpler and cleaner code. Design of all things is meant to be efficient and useful to both the designer and the user, so to practice and understand good design a person must understand bad design as well.
Link to the Blog Referenced in this post:

From the blog CS@Worcester – Tyler Quist’s CS Blog by Tyler Quist and used with permission of the author. All other rights reserved by the author.