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: https://www.indeed.com/career-advice/career-development/what-is-object-oriented-programming#:~:text=Object%2Doriented%20programming%20has%20four,basics%20of%20a%20computer%20program.

To read more info on different ways to program this is a another link with helpful information: https://careerkarma.com/blog/types-of-coding-languages/

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.

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.

https://www.educative.io/blog/object-oriented-programming

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

When using principles or techniques in code, we need to use them in moderation and understand the meaning behind them; otherwise we over-salt our code. The post that I will use in discussion explains a common salting problem in programming, the article was found in an early programming blogpost from Coding Horror, to reflect a topic that is relevant in programming and also discussed in one of my courses. The topic is Object Oriented Design.

In the article that I chose, titled, “Your Code: OOP or POO?”, the author, Jeff Atwood, talks about how many programmers these days are not using Object Oriented Programming correctly. He attributes this problem to institutions that rush and advise the usage of OOP to their students without properly explaining when and why objects are necessary in programming design. In addition, he also blames the pro-object culture that is common among programming communities, where programmers glorify objects and boast the superiority of object oriented languages over non-object languages. Due to these influence, he explains that it causes programmers to undergo object happiness, a frenzy of object-izing everything in their code. This mess, is the coding horror that is seen when Object Oriented Design is used improperly.

To address these concerns, Atwood recommends POO, Programming fOr Others, which brings in the element of empathy into programming design. What Atwood proposes is that programmers should be thinking about their audience, such as their readers, who will have to make sense and use their code. So, along with implementing other OOP principles, such as, encapsulation, simplicity, re-use and maintainability; Atwood encourages empathy and to build code while keeping in mind what their readers would want or need and to anticipate what they need to do next when following the code. Atwood concludes his argument with ‘programming as if people mattered will always be a more effective strategy than satisfying the architecture astronauts’.

Although this is an early post, which was posted on 2007, the topic of this post still holds relevance. While continuing my CS undergrad studies at WSU, I have noticed this pro-object culture, where object oriented languages are remarked as superior than non-object languages and I have also noticed that some of my peers falling victim to object happiness and not having a firm grasp of OOP principles. I also feel that this post was a good reminder, that we should be questioning our studies and what we are taught at institutions in programming. In a sense, it was a good step back for me to reevaluate my principles and goals in coding. It also brought in a new perspective, the element of empathy; where one should code as if people mattered; rather than solely focusing on the efficiency of the solution; we should also consider readability and simplicity of our code.

The link of the source can be found here

From the blog CS@Worcester – Will K Chan by celticcelery and used with permission of the author. All other rights reserved by the author.

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.

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.