Category Archives: Week-2

Why I Prefer Object-Oriented Design

Object-oriented design is incredibly useful in my opinion. While there are also functional and procedural languages, I feel that languages which are primarily Object-oriented are the most exciting and useful for the types of projects which I enjoy. Topics such as game development, large-scale user interface focused applications such as Microsoft Word, and general programming can all benefit from an object oriented approach. While functional and procedural languages are certainly important and have legitimate uses, I would be unlikely to choose one for any large project.

I recently read a blog post on The Robert Half Blog, a blog which focuses on career advice and discussion of skills which employers look for. The post focuses on a quick overview of some reasons that object-oriented programming is useful and some of the aspects of object-oriented programs which make them easier to understand compared to code written with different paradigms.

Overall, the article focuses on features which are key to the concepts of object-oriented design. Modularity is discussed, and while I was already aware of the concept the post brings up an interesting point. The idea that the self-contained nature of object oriented code makes it easier for teams to work on many different projects at once, while minimizing the chances of duplicate code (since classes and objects are self contained, it is almost always clear what each one will do in terms of functionality).

Additionally, the topics of inheritance and polymorphism are discussed. While I have always been able to easily visualize the concept of inheritance (one concept extends from and inherits functionality from another), polymorphism has been confusing to me throughout my academic career. The author of the post uses a clear example which was very helpful in clarifying my understanding of polymorphism. An example “car” class is discussed, with “drive” function which controls driving in general for all types of cars which extend and inherit from the parent car class. Since all types of cars inherit the drive method from the superclass, they can call drive with their own information and variables, and the method has the ability to be adapted into many potential situations.

Finally, the post discusses the use of object oriented languages in problem solving. It is described as a “natural and pragmatic approach”, which accurately describes object oriented languages in my experience.

Although the information provided in this post is fairly general in the information it provides, the examples and concise explanations of a few concepts which were becoming unclear to me over time (it has been a while since I have been able to study and review modularity and polymorphism, polymorphism in particular has been especially confusing). The post provided a good review of these concepts, and I will likely attempt to introduce polymorphic methodologies into some of my projects in the future. In some circumstances I think a simple explanation can be more effective than something complicated.

https://www.roberthalf.com/blog/salaries-and-skills/4-advantages-of-object-oriented-programming

image from The Robert Half Blog, July 13, 2017

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

S.O.L.I.D

In this week’s post for my blog about the crazy journey of coding, I will be talking about the SOLID principles. The reason I am selecting this topic is because it sets the tone on how to produce quality code. Many times, especially for most students like me, we rush to finish up any coding project we have and don’t live up to the potential that could have been put forth. Therefore, SOLID principle help give a guideline to follow for almost any programmer to outcome the best work.

Well S.O.L.I.D is actually an acronym that stand for five important principle of object-oriented programming by Robert C. Martin, who is commonly known by as Uncle Bob. Now if you have read my first blog you would know that I went to a lot more details on object-oriented programming and I would suggest everyone read up on that before reading this post. The essential purpose of the principles to create software that is easy to maintain and add onto in the future. These principles also help detect any minor problem in the code that could lead to bigger problems and help change around code any time on the code journey. Now let’s get into what these letters actually represent.

The S in the S.O.L.I.D principle stands for Single Responsibility Principle and it states that a class should have one and only one reason to change, essentially meaning a class should only have on job. This concept should be fairly easy to understand as one class should be responsible only for what it represents and all the methods in the class should correspond to that. The second acronym O stands for Open-Closed Principle and it states that objects or software entities should be opened for extension, but closed for modification. What this essentially means is that classes should be able to extend its behavior, but not be modified. This can be done in various different ways such as through inheritance or an interface, but the main guideline is not to modify.

The L in the S.O.L.I.D principle stands for Liskov Substitution Principle and it states that objects of a superclass can be replaced with objects of its subclasses without breaking the software application. What this simplifies too is that the objects of the subclass need to behave in the same way as objects of the superclass. The next acronym I stands for the Interface Segregation Principle and it states that no client should be forced to implement an interface that it doesn’t use or clients shouldn’t depend on methods they don’t use. These interfaces are difficult to maintain and change over time so it is best to avoid. The last acronym in the S.O.L.I.D principles stands for Dependency Inversion Principle and it states that software entities must depend on abstractions not on concretions. This is due to the fact that abstractions change less and so make it easier to change behavior.

I think personally these principles are all key to establishing good solid code. In the future, I expect myself to catch myself when I am coding and follow these principles. With this outlook, I will be able to keep a clear focus from start to finish of a project, and won’t compromise one thing for another. The principles create a clear road to follow and I have benefitted from learning about it.

To read more up on the S.O.L.I.D principles, here are some sources to check out which I have used for research:

View at Medium.com

https://scotch.io/bar-talk/s-o-l-i-d-the-first-five-principles-of-object-oriented-design

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.

S.O.L.I.D

As a student learning new things every day, I chose this topic because I was curious as to what it really entails in computer science as it is one of the topics that directly relates to the course. However, little did I know that it was an abbreviation for 5 important design principles employed in software programming to make software designs more understandable, flexible, and maintainable.  I selected this blog because it explains briefly but detailed about each principle of SOLID and definitions.

This blog talks about who introduced the acronym SOLID and its importance. Also, what it stands for, which are Single-Responsibility, Open-Closed, Liskov Substitution, Interface-Segregation and Dependency-Inversion Principles. Not only does it explain each principle, but explanations are concise and easy to comprehend. It has some links that provides detailed explanations to some of the principles, giving examples that enables one to grasp the concept fully. It also explains why each concept can help developers to build better software and the importance of cohesion and less coupling in software development.

In this blog not only did I learn about the 5 principles, but also learned that it is a part of object-oriented programming that enables one to write a better code that is robust. I learned in Single-Responsibility Principle that classes should have a unique responsibility and that will help reduce complexities, reduce dependency on other classes, ensure readability all in while leading to a stronger cohesion. I believe that the quote “do one thing and do it well” has come into importance in this principle as that will help me avoid fusing too much responsibility on classes in my future programs to make editing of codes easy.

In Open-Closed Principle, I learned that any class written or coded can be used as it is written. It can be extended but can not be modified. However this principle made me understand more about inheritance and polymorphism in the sense that classes can be open if attributes can be added but closed if it is available for use/extended/implemented by other classes. I always used to be a victim of modifying parent classes if there are any errors in my sub classes which should not be the case. Also, this principle improves readability.

When looking at sample programs using interfaces, I never understood why interfaces could not be segregated into one, rather such programs could have more than one interfaces. Also, one class could implement many interfaces. However, this blog made me understand why this is the case in Interface-Segregation Principle that an interface can be broken down into smaller interfaces that are specific rather than making it large. In addition, classes do not need to implement interfaces they do not use.

I will encourage other students to read this blog as it helps understand more concepts in Object-Oriented Programming to make them better programmers.

https://apiumhub.com/tech-blog-barcelona/solid-principles/

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

Hello fellow CS enthusiasts and beginner programmers!

  In this week’s blog post, I plan to go over Object Oriented Programming. I found an excellent blog that explains the four principles of OOP; encapsulation, abstraction, inheritance and polymorphism. The author hilariously titled the blog “How to explain object-oriented programming concepts to a 6-year-old”. As a father of two 6 year old boys, I don’t see many 6 year old’s understanding it but it did however clarify Object Oriented Programming for me. I chose this specific blog because I found it comprehensible and uncomplicated. It was written and formatted in a way that made it very enjoyable to read. I have read many examples in textbooks but none of them were as easy to understand as these for me.

I enjoyed the simple example the blogger used to explain encapsulation. Encapsulation happens when the object keeps its state private inside a class, but other objects can’t directly access it. Other objects they can only use public methods. The object maintains its own state, and unless explicitly stated other classes can’t change it. We are made aware of a developing sim game involving a cat class which has private variables as the “state” of the cat such as mood, hungerLevel, energyLevel. The cat in the example also has a private meow() method, and public methods sleep(), play() and feed(). Each of the public methods modifies the state of the cat class and has the possibility of invoking the private meow() method.

To explain abstraction, the blogger used an example of a cellphone. When using your cellphone, you only need to use a few buttons because implementation details are hidden. We don’t need to be aware of all the intricate processes that occur when we press buttons on our cellphones, we just need them to behave accordingly as expected.

Inheritance is the concept of code being reused to create more specific types of an object. is fairly easy to understand due to classes being referred to as parent and child classes. The child receives all the fields and methods of the parent class but can also have its own unique methods and fields.

When explaining polymorphism, the author uses the example of a parent “shape” class with the children triangle, circle, and rectangle. In the shape class we have methods CalculateSurfaceArea(), and CalculatePerimeter(). The children classes utilize polymorphism when calling the abstract classes of the parent because they each have their own formulas for surface area and perimeter.

Since discovering this blog post, I am more confident in my understanding of OOP. I can visualize the 4 principles better and will be able to utilize them in my coding much more efficiently now. I hope you enjoyed this blog post, attached below is the blog which inspired my post.

https://www.freecodecamp.org/news/object-oriented-programming-concepts-21bb035f7260/

From the blog cs@worcester – Coding_Kitchen by jsimolaris and used with permission of the author. All other rights reserved by the author.

S.O.L.I.D

In the second week of my blog I will continue to talk about the Design Principles. These are the first steps that each of us learn when we are introduced with the world of programming. The first week I talked about the importance of OOC and how to get out of a bad OOC case. Today I want to talk about SOLID. Computer science and their acronyms, never ending.

What does Solid stands for? Probably you all know but I will explain it anyway. S.O.L.I.D is an acronym that represents five principles of object-oriented programming and code design theorized by Robert C. Martin also known as Uncle Bob. 

[S]ingle Responsibility Principle
[O]pen/Closed Principle
[L]iskov Substitution Principle
[I]nterface Segregation Principle
[D]ependency Inversion Principle

The goal of the principles is to make it easier to develop, maintain, and scale. They also make it easy to recognize and avoid code smells as well as improving the refactorability of your code.

The reason why I choose this topic is that I like everything that makes my life easier. And these principles have helped me a lot in my programming experience. I used to do a lot of repetition in my code, so these principles helped me understand how to code better. Remember “Do not repeat yourself”.  SOLID it makes your software easier to implement and prevents unexpected side-effects of future changes.

I researched and read a lot about Solid principles, to understand the concept and how to apply it. There are tons of examples, books, websites that are nice, help you with anything that is unclear. Stackify and Medium are two of my favorites in this topic. They show the importance of SOLID and apply it in code examples. Stackify it is more detailed, shows what a future developer should keep in mind, tips and tricks that you might you use it.

Simply learning and knowing these principles will not in itself make a person a better programmer. To truly be able to understand them you must apply them. If you cannot do that in the code base you have now, then work through practice problems applying them there. As you use them you will see why they are important and where they may not be the best choice. This is something that comes with time because it takes many experiences to get a full picture or how they can be applied. Whether you are just starting your career and learning the best ways to write code or have been at it for decades there is much to learn from just applying simple principles to the way you code.

View at Medium.com

SOLID Design Principles Explained: The Single Responsibility Principle

View at Medium.com

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

UML Diagram

In today’s blog I’m gonna talk about UML diagram. This week in the past we learn how to draw email diagram and how it helps in software developing and designing. We also learned how programmers use this UML diagram to write code in class object and much more. This is directly related to the course materials in and computer science major this block will help the readers how to draw your UML diagrams and then write a code based on that.

i’m gonna start with what is your UML diagrams. UML, which stands for Unified Modeling Language, is a way to visually represent the architecture, design, and implementation of complex software systems. This language helps programmers to visualize the software and helps them developing code.I’m gonna talk about types of your mail diagram there are five component of uml diagram. Class, object, inheritance, Abstraction,and polymorphism. Below show definition of those component.

  1. Class –A class in UML diagrams tells the basic idea of the structure and functions of an object used in class.
  2. Objects –Objects help us break down large structures and allow us to modulate our behavior.
  3. Inheritance –Inheritance is a process by which child/Subclasses inherit the characteristics of their parent/Superclasses.
  4. Abstraction –It is the process by which implementation details are hidden from the user end.
  5. Polymorphism –It is the method by which functions or entities are to show themselves in more than one foam.

    People chose this because UML Because it helps strategic value of software increases for many companies, the industry looks for techniques to automate the production of software and to improve quality and reduce cost and time-to-market. These techniques include component technology, visual programming, and pattern. The Unified Modeling Language (UML) was designed to respond to these needs. this tool is really easy to use when you understand everything. This diagram helps Support higher-level development concepts such as collaborations, frameworks, patterns and components. And Integrate best practices.

    There are many ways to write or draw UML diagram. You can Draw it by pen or pencil or online tool like visual-paradigm that Han help developer to draw class and object UML diagram FOR FREE.

    we all know that your UML diagram is REALLY difficult to write or draw. I am going to explain what each symbol and sign mean in UML Class diagram. Link below show how UML diagram can be drawn. There are things in there you can look at like UML Class Notation, Class Visibility, class attribution, Class operation, Parameter Directionality, Relationships between classes and much more…

SOURCE: https://www.techtravelhub.com/what-is-uml
https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-uml/

free UML diagram: https://online.visual-paradigm.com/diagrams/solutions/free-class-diagram-tool/

From the blog CS@Worcester – </electrons> by 3electrones and used with permission of the author. All other rights reserved by the author.

Reading List

For this week “Apprenticeship Pattern” I have chosen Reading List. It is a pattern about keeping up a running list or more precisely a priority queue, as the author describes it, of books that are worth reading for amassing more knowledge about a given subject. The queue will change or be reorganized many times over the course of it, but it is worth having. Another useful advice in the pattern is to ask your mentors or people more knowledgeable bout a subject about which books they recommend reading.

What I like about this pattern is simply something that I have already started doing, it is interesting to me to find out that it is not only me who had this idea. I think this will be a very useful tool in anybody’s arsenal in their professional career. What I have done is essentially described in the pattern itself. I have talked to some of my colleagues at work as well as my bosses and figured out what books they recommend, after that I have done some research and based on other reviews of the mentioned books I have made my own list.

Not all the books in my opinion need to be about your work or career, if they are helpful in some way then they are worth reading. Any knowledge is good, the best knowledge of course is the one that helps us grow as a person.

One useful thing that I have learned from this pattern is to put my past books on my list and keep them there even after I have read them. This is to help me and other to reflect on them later and to better remember the contents and lessons acquired from the book. The pattern also states that better understanding of the subject at hand will help people refine and organize the list better. I agree with that and like the author states mentors are always a good source of said understanding and any good mentor will always steer you in the right direction. I’m feeling lucky because I have been able to find such a person. Currently due to my student status my reading has stalled to a degree, but I do plan to get back to it as soon as possible.

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.

The White Belt

For this week’s blog post, I decided to write about The White Belt.  This section is in Chapter 2 which is called Emptying The Cup, and if I remember the introduction for Chapter 2 correctly, this chapter 100% belongs in this section. Like all sections in this book, it is split up into 5 sections, context, problem, solution, action, and see also. The context is a short sentence that basically explains the reader is now confident in his abilities in a certain language, and people rely on them for help. I was actually shocked to read this because typically the white belt symbolizes the beginning, and this book’s description of a white belt is knowing a language and helping people. That’s shocking to me because that just means I have no belt because I feel like I’m in no position to be helping people with the skills I have now.

The next section is the problem. This section was also very short, but it should be because it is only discussing the issue. The issue for this section is that it is difficult to learn new things, and that your “personal development may have stalled” (Oshineye, Hoover). While this isn’t an issue for me yet because I am still learning my first language, this could very much be an issue in the future for me as I also struggle with learning new things.

The solution section urges the reader to start to learn new things by unlearning the things he already knows. They use real life examples as well as some code examples to get their point across. I particularly enjoyed the code section because I liked how they showed the same process being done with two “radically different” (Oshineye, Hoover). languages. They did this to show that because you have a solution in one language, you should still learn a new language to broaden your horizons.

This section was a really easy read for me. The part where they talked about how the white belt had to learn the way while the black belt knows the way really hit me because that was how my internship was. I had to watch and learn everyday before I could even do anything, and it was actually nice to learn along the way because I realized there was so much more that I had to learn before starting my real job.

From the blog CS@Worcester – My Life in Comp Sci by Tyler Rego and used with permission of the author. All other rights reserved by the author.

Pratice makes permanent

Apprenticeship Patterns is a really interesting book to read and I actually learned a lot from it. For this week, I read about the pattern “Practice, Practice, Practice” and there are a few interesting things I found about it. The pattern starts with a quote by George Leonard saying that masters they don’t just get better by devoting in a particular skill, but they practice getting better and the it gets more enjoyable to perform basic moves over again once they are better. I can definitely agree on this as I think we all have been through a rough beginning of doing something, but when we are better, we would think back how easy it is to do those basic task and we would do those rather than more complex problems that we have to face later on during the process of mastering a skill.
Then the author went on to talk about practice is a long process and it has to be done without interruption, and in a comfortable environment of making mistake. At this part, it is interesting to learn that practice in software development can be in a stress-free and playful environment. For me, I always think that the best way to practice is to join a group project, and there would be one or another thing that would stress me out so easily like if I work in a small group or alone even on a small size project, at some point we would be overwhelm with the amount of work that we have to deal with, or too much concern about security, features, accessibility, etc. and after reading this chapter, it makes me question about my priority on different aspect of the program and maybe I should change in order to get better.
The author also brings up another interesting point is to try to do a bit different for each time we practice and choosing the right thing to practice is very important. In my opinion, I think that should be the most optimize way to discover new things and not to miss out any important things while we are still on the basic level.

From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.

Unleash Your Enthusiasm

Further reading into chapter 2 I find that I relate to many of the patterns in this chapter, However, in my reading tonight I felt a specific interest in UnleashYour Enthusiasm. Unleashing Your Enthusiasm is about taking your passion for the work you do and exercising that passion. Think of it like starting at a new gym. You may not know what to do or the correct ways to do things, you may feel weak, confused, and embarrassed. Even with all of these negative feelings you know that you are excited to learn and get stronger. You may need to ask trainers for help and exercise your want for learning despite the embarrassment. This pattern is primarily about understanding that your passion used correctly is itself a valuable attribute to contribute to a team or teacher.

I find that this pattern goes hand in hand with Exposing Your Ignorance and that are one in the same. In order to unleash your enthusiasm you must be willing to expose your ignorance. If you are new to a team or project you are undoubtedly going to have to learn. You have to know that other more senior members will know more than you and will have to take the time to teach you, which for them may seem counterproductive. Being alright with your ignorance is the first step toward unleashing your enthusiasm. UnleashYour Enthusiasm is more about seeing the value in your ignorance. With this drive for knowledge it can help rekindle the flames of other more senior members who have plateaued and have their fire of passion die down to a smolder.

I find I experience the fear of exposing my ignorance quite often. At this point in my education I am always learning in everything I do. It sounds silly because it’s so obvious, but everything I have learned was once something I did not know. This means I had to overcome some fear and pursue that knowledge. Working with teams of my peers there is often a wide range of knowledge based on experience and backgrounds. It is scary to put myself out there and explain that I may not know something that they are all talking about it, but I have had the courage to do so. Many times I have done this and then had a pleasant conversation with my peers about having the drive for knowledge. It doesn’t pay to be afraid of taking the chance, that chance is knowledge and it gives others the opportunity to share something with you. I find that this unleashing of enthusiasm sparks a great pep talk for any team.

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