In this post, I will be discussing some basic concepts about abstraction in object-oriented programming. The resource I reference can be found here. I chose this topic because in the first few group activities, I was made aware that I had forgotten some of the key differences between kinds of abstraction (at least in Java), such as the difference between an abstract class and an interface. Though we reviewed these differences in class, I wanted to continue to find specific examples that would allow me to better understand the concept. Abu’s blog post briefly explains what abstraction in object-oriented programming is, some of its benefits/purposes, and some elementary examples of how to implement (no pun intended) abstract classes and interfaces.

The largest point of note I want to discuss is the benefit of modularity when abstraction is implemented. I recently finished up a personal coding project, in which modular development was a necessity. The project involved a central framework capable of ingesting a very specific kind of data from different websites, but each of the websites had a different way of providing that data. The most efficient answer I could think of was to make the central framework independent of the websites themselves, and to make it deal only with the data after it was obtained. I then created a module for each website that held the data, and implemented whatever logic I needed to in order to get the data and pass it to the central framework. I used Python for this project, but in hindsight, I may have been better suited to implement an object-oriented programming language like Java. Each module could have been a concrete class that extends some abstract class Parser, as each of my parser modules in my Python project used the same methods anyways. Each module had a get_url_and_interactions() function, a get_parse_function() function, and an stm() function (we can leave that abstract for now). It would have been very simple to use an object-oriented programming language, as I could have abstracted what it means to be a parser.

Now, this worked fine; since I was the only developer on the project, and had full visibility over all of the code, I didn’t need to check if a module implemented, for example, the get_url_and_interactions() function. I knew that it did. Moving forward, if I were coding more collaboratively with anyone else, or even if I just wanted to code according to some better practices moving forward, I could have used abstraction to standardize the parsers to ensure they all implemented certain methods or functions.

Though a little cliche, I do think it is very nice and elegant that the same thing can be accomplished in so many different ways. I think it is a good metaphor for most problems worth solving.

From the blog CS@Worcester – Mr. Lancer 987's Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.

Sunday, September 15, 2024

This week I was introduced to Object-Oriented Design Principles. In this week’s blog, I will be discussing what object-oriented design principles are and how these principles help with creating software so that it is easy to maintain.

The Medium blog post by Ravi Patel “Understanding Object-Oriented Design Principles” offers an overview of major object-oriented design principles and how they help to the creation of successful and maintainable software. Object-Oriented Design (OOD) is a software design methodology that views the program as a collection of interacting objects, each representing an instance of a class. Ravi goes on to discuss the fundamental principles, encapsulation, abstraction, inheritance, and polymorphism.

Encapsulation is the process of grouping data and methods that operate on it into a single unit or class while restricting access to certain of the object’s components. This aids in concealing the internal state and requires all interactions to be conducted through an object’s methods.

Abstraction is the process of simplifying complicated systems by modeling classes based on key traits and behaviors, while obscuring unneeded information. This focuses on an object’s actions rather than its methods.

Inheritance allows a new class to inherit characteristics and methods from an existing class, enabling code reuse and establishing a hierarchical connection between classes.

Polymorphism allows objects to be viewed as instances of their parent class rather than their own. This enables the use of a single interface for a broad range of activities, increasing code flexibility and extensibility.

I chose this blog post because it helped me understand the principles better. After this week’s reading I now understand that object oriented principles is a theory that helps developers in how to think about and build code that is easier to work with, simpler to understand, and requires less maintenance overall. When working on my POGIL activity with my team this week, there was a question that asked us to define the principles without looking them up. We defined the principles as follows:

Abstraction is simplifying code
Encapsulation is adding code to already existing code
Polymorphism is many forms of code/methods
Inheritance are classes and their super classes and constructors

Our definitions were not entirely wrong. We could gather what each principle meant to an extent. I see myself applying these principles in my future projects. It would help create readable code that can also be modified easily as needed. This week’s material made me understand that not all long code is helpful. The simpler the code is the better it is for the next developer to read it. When I usually code, I add a lot of unnecessary code that does not need to be there. I hope to improve my code writing skills as I learn more.

Blog link: https://medium.com/@ravipatel.it/understanding-object-oriented-design-principles-0c1e48207c89  

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

Looking back at this blog post it is a bit outdated, being posted nearly 2 decades ago but I still feel like it has a lot of quality information within it that can still be used today. I learned about several different architectures and their patterns that I thought were rather interesting. It was still a little over my head with a lot of jargon I didn’t understand, such as “Forms and Controls” and “Model-View-Controller” which is an apparently highly misconstrued architecture, that I had to look up, but I think this gave me a good look into what I can learn more about and where to direct my attention. I think in the future after I’ve learned some more basic architecture and design concepts, I’ll really be able to apply them and understand them more. Also, I’m a lot more interested in seeing more front-end things related to GUI and the process of developing a quality and useful GUI for a user. Now looking back at myself a little bit, reading this has really cemented for me how much I don’t know about the entire software development process. It truthfully shows me how I need to really pay attention and really work harder at developing my knowledge in the field as most of the blog post was entirely new to me and things I had never heard before which gets me excited about learning more! Also, all of the diagrams in the blog post were really neat and had a great effect in helping me understand the points of each pattern, so this has kind of helped me to understand how useful UML diagrams are and would be for designing and putting a program into and understandable and digestible format that makes it really simple to at a glance get what’s happening. I do think for my next blog post I may need to pick something a bit more my speed.

Summary: An interesting exploration of various architectures for GUI design and detailing their features as well as their underlying patterns within the architectures. Also is a sort of “intellectual history” of these varying GUI architectures.

Reason: I wanted to learn a bit more about GUI’s and how they work, this really details an almost historical record of UI development and how they work underneath. It also contains plenty of diagrams and detailed explanations that really helped me to better understand it.

Blog Link: GUI Architectures (martinfowler.com)

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

As the first blog post, and naturally occurring when at the start of my CS-343 class, I had a hard time picking a topic. In class we haven’t gone over many new concepts, but my professor did mention during a topic review that there are other options from inheritance that are able to do very similar functions. Piquing my interest, I wanted to look into inheritance itself and what other people thought of it and compare it to my experience coding programs using inheritance.

The blog post I chose started with an introduction about how inheritance is taught in a way that doesn’t give students the best grasp at how to implement some of the more niche situations or real-world cases where inheritance would be the most efficient method. Something that the blog mentioned that has been something that as a student I have never really come across, is deciding when a certain method, in this case inheritance, is the best way to solve a problem. Usually with assignments, the method is already predetermined, and the implementation is what you are graded on, or because of the limited subjects covered, the intended method is easy to figure out.

The author then goes into the two main problems that inheritance has, the complex syntax and the complexity of the problem inheritance is best suited to. Inheritance has it’s own syntax that is new and you have to learn but it also gets difficult because the new context of the code now has new rules to it that need to be considered such as precedence, overriding, and variable types. The other problem is that cases where inheritance would be the best implementation are problems that have a reasonable amount of complexity. There needs to be two classes of objects that have a good deal of similarity between them but also be different enough and have a good amount of shared code to where you would not want them to be two separate classes. 

Reading this blog as well as reviewing inheritance in class has shown me that while I know the concepts and am able to write a program that utilizes inheritance, my experience with all of the special cases and interactions is not complete. The blog was more catered to teachers but as a student I also found it to be helpful. The blog doesn’t offer much in terms of a deeper look into the topic or language specific examples, but having learned more about it’s complexity I will be sure to look at other resources that more thoroughly and meticulously go over the nuances of inheritance so that I can feel confident in implementing it in any program where it would be a proper fit. I think it’s always good to try and fully understand a topic especially when you think you know everything about a topic and you run into a roadblock. 

Teaching Inheritance – Ada Developers Academy

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