Source: https://www.tomdalling.com/blog/software-design/solid-class-design-the-liskov-substitution-principle/

SOLID Class Design: The Liskov Substitution Principle written by Tom Dalling on Tomdalling.com is a five part series about the SOLID class design principles in OOP. He starts off with a problem about inheritance. For instance, if you had a penguin which is a bird that falls under an “is a” relationship. However, when the penguin inherits from the bird class, it will also inherit the fly method. As soon, as you set the fly function to do nothing, then it violates the LSP. Then Tom explains that from applying the Open Closed Principle, subclasses must follow the interface of the abstract base class. If the class has to be altered in such a way to account for certain classes then it also violates the Open Closed Principle of being able to extend a classes behavior without modifying it. In conclusion, two solutions are presented, one is adding a method to check for a flying bird or non-flying bird. The other which, he states as a better solution, would be to create separate classes to account for a flightless type, that way the fly method is not inherited from the superclass.

After doing assignments for CS-343 revolving around refactoring a pre-existing poorly implemented code by applying design patterns. I did not realize that we touched upon the Liskov Substitution Principle before reading the blog post. However, choosing this post, serves as a great source of review material upon topics covered in class. The assignment that incorporated multiple design patterns started off with a clear application of the LSP, as the original design had two instances of overriding to do nothing. However, the criteria for our first refactor requires the LSP and other inheritance reworks.  Since we were working with Ducks, you can imagine a QuackBehavior and a FlyBehavior, that incorporated real and inanimate ducks. So, the LSP application is similar to the second solution presented earlier, in which the fly and quack methods aren’t inherited from a superclass but rather an interface later implemented by the duck class. But even though the method still does nothing, it isn’t an override method, so it does not violate the LSP.

Like other OOP principles, these exist to help achieve code that is maintainable and reusable. By acknowledging the existence of these SOLID class design principles, it will hopefully prevent future projects from projecting these type of code smells. Also, by understanding them and utilizing them wherever they suit best, my code will be cleaner, easier to maintain and add new features.

From the blog CS@Worcester – Progression through Computer Science and Beyond… by Johnny To and used with permission of the author. All other rights reserved by the author.

I chose the article “Software Analysis and Design Tools” because I think it’s important to know how to put design knowledge to work using the common tools and practices. Software design and analysis allows the requirements of an application to be converted to actual code. I chose Tutorials Point for this article because I’ve used them quite a bit as I’ve learned different topics in computer science.

The first tool that is mentioned is a data flow diagram. This is basically a graphical representation of the path of data in an information system including incoming, outcoming, and storage. It’s important to know that this flow does not convey underlying “how” the data actually flows, it just shows the path. The two types of DFD’s are logical and physical and they use a set of components to represent data flow and relationships. This includes entities, processes, data storage, and data flow which are organized into different levels which represent a layer of abstraction.

The next tool used is called a structure chart which is actually derived from a data flow diagram. It shows a system in much more detail down to the lowest functional modules and describes the functions of these modules. The actual chart depicts a hierarchy of modules where each layer performs a specific task. The charts use special symbols to represent things like conditions, jumps, loops, data flow, and control flow.

The next tool is called a HIPO diagram which stands for Hierarchical Input Process Output. This diagram represents a hierarchy or modules in a system and depicts all the functions and sub-functions of a module. They are a good tool to represent system structure and allow designers and managers to picture the overview of a system.

There is also a diagram called IPO which stands for Input Process Output. This diagram shows a good representation of control and data flow in a module as the HIPO diagram does not depict the flow of any data.

Some of the other tools mentioned in the article include pseudo code, decision tables, entity-relationship models, and data dictionaries.

After reading this article I think I realized there’s a step in the software design implementation that I’ve been overlooking. Creating these models and diagrams mentioned is a pre-cursor to choosing a design pattern or implementing any code. Creating a usable understanding of how a system will work is a crucial first step in any design. I think this article did a really good job or covering some of the more popular software analysis and design tools. When it comes time to design an application I will definitely make sure I’ve represented the system using one of these tools before I think about the actual design pattern or architecture I want to use.

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

I chose this topic because I tend to forget exactly what kinds of tests are being done when system testing is mentioned. The term is very vague so I thought it’d be smart to write my own explanation of it. I chose the specific article “What is System Testing?” because I’ve used articles from this website before and have found them to be helpful.

To start, system testing is the testing of a complete and integrated software system. The important part of this is to recognize an entire system and not just one program. Interfaces, programs, and hardware are integrated frequently and there needs to be a way to test how they all work as a system. System testing is how this can be achieved.

System testing is one type of black box testing (as opposed to white box testing). System tests examine how software works based on a user’s perspective. One of the things being tested are the fully integrated applications in an end to end testing scenario. This checks for how components interact with each other as well as the system as a whole. Inputs in the application will be tested and compared to what is the expected outputs are. Lastly, a user’s experience is also part of the system testing to ensure the system flows and can be navigated smoothly by the end user.

While system testing is extremely important it’s not the only type of testing needed and it’s important to realize when it needs to be conducted. Typically it will be towards the end of the development cycle as most of the system needs to be operating correctly in order to properly execute the test cases. Unit testing and integration testing will come prior to system testing and usually acceptance testing will follow.

While there are quite a few types of system some of the more popular types include usability, load, regression, recovery, and migration.

After reading this article I definitely have a better and clear understanding of what system testing is. I think this article gave good explanations and included a helpful video as well. In order to actually implement system testing on a project I’d need to do some further reading on one of the specific types in order to decide what type best covers my system. I haven’t had the need to really implement system testing so far mainly because my programs have been relatively simple. As I head to the work force this type is testing will become very important working on much larger systems.

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

Mediator Pattern

      This week, I chose to talk about a blog I found that went over the mediator design pattern and its implementation. The blog post starts off by explaining that the mediator design pattern is a famous pattern found in the Gang of Four book. It is known to reduce coupling between classes that can communicate with each other. The basis of this pattern is to create a mediator object that has control over the channels of communication between the objects. All messages to other objects essentially must go through the mediator to be directed to another object. The blog post says that this eliminates the need for the deploy objects to have knowledge of the receiver objects. The post goes on to talk about the removal of direct dependencies as it can simplify communication in programs with a large number of classes. It then talks about some of the positive effects this may have like making the code easier to read overall and the maintainability for future editing. The post then goes on to explain the pattern with an example that uses communicating between colleagues and mediators within a project.

      I chose this blog because it was a design pattern that focused on communication between classes which I find very interesting. I found that the explanations this blog uses makes it very easy for me to understand how this design pattern works. The easy to digest wording allows for an easy read that works well with the examples used. The phrasing within the examples allowed the UML diagram and the definitions of the classes underneath to make more sense. The only issue I had was with following the code at first glance due to the fact that it was written in C# but it didn’t take me long to piece it all together. The test classes were well written to show meaningful variable names as well making it easier to understand the parallels they were making from the examples. Through this information I was able to learn that if there is a mediator it can be implemented to make sure all the objects don’t hold unnecessary amounts of code in terms of communication. This will cut down on code within class heavy projects that need objects to remember each other’s addresses. This will help me in my future practice by making the code run much more efficiently and create a better sense of organization that makes it easier to read when dealing with many classes.

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

https://www.butterfly.com.au/blog/website-development/clean-high-quality-code-a-guide-on-how-to-become-a-better-programmer

This blog discusses various techniques that can be used to make your code cleaner and easier to understand. Writing high quality code is very important for software that is updated over time, and the following tips will help improve your code readability and quality.

Variable and Method Names

• Use names that reveal the intention of the variable or method
• Use names that can be pronounced
• With programming languages that support namespaces it is better to use them rather than prefixing names
• Use one word per concept throughout the program. For example, don’t use get and fetch to do the same thing in different classes
• Use solution domain names
• Use verbs for method names and nouns for classes and attributes

Better Functions

• The smaller the better
• A function should only do one thing (single responsibility principle)
• Less arguments are better
• Functions should only do what the name suggests and nothing else
• Avoid output arguments. If returning something is not enough then your function is probably doing more than one thing.
• Throwing exceptions is better than returning different codes dependent on errors
• Don’t repeat yourself

Comments

• Don’t comment bad code, rewrite it
• Explain your intention in comments
• Warn of consequences in comments
• Emphasize important points in comments
• Always use doc comments
• Any comments other than the above should be avoided
• Never leave code commented. With source control software you can always revert back to old code. Comments can be used when debugging or programming, but commented code should never be checked in

Code Smells and Anti-Patterns

The following should be avoided:

• Dead code
• Speculative generality
• Large classes
• God object
• Multiple languages in one file
• Framework core modifications
• Overuse of static
• Magic numbers (should be replaced with const or var)
• Long if conditions (replace with function)
• Call super’s overwritten methods
• Circular dependency and references
• Sequential coupling
• Hard-coding
• Too much inheritance (composition is better)

I selected this blog because being able to write high quality code is extremely important in software development. Quality code decreases time spent trying to understand it, making the code easier to maintain and reducing the possibility of bugs. I thought this blog was very well done because it was entertaining to read and gave plenty of examples. Reading this blog helped cement ideas that I learned previously from this class and taught me new techniques that increase code quality. Since none of the information is hard to understand I can begin applying what I’ve learned right now, and hopefully I will continue to get better at writing clean code.

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