Category Archives: Week 7

10 Object Oriented Design Principles

http://javarevisited.blogspot.com/2012/03/10-object-oriented-design-principles.html

For my blog post this week I chose another topic on the concept map that I thought looked interesting: design principles. These are helpful guidelines to follow that will make your code cleaner and more modular. This blog post describes 10 design principles that are useful in object oriented programming.

  1. DRY (Don’t Repeat Yourself) – Means don’t write duplicate code. It is better to abstract common things in one place as this will make your code easier to maintain.
  2. Encapsulate What Changes –  This will make it easier to modify your code in the future. One good way to implement this is by making variables and methods private by default and increasing access step by step.
  3. Open/Closed Principle – Classes and methods should be open for extension and closed for modification. Following this principle means that you will not have to change much existing code when new functionality is added.
  4. Single Responsibility Principle – A class should always handle a single functionality. Introducing more functionality to a class will increase coupling which makes it hard to modify a portion of code without breaking another part.
  5. Dependency Injection or Inversion Principle – High level modules should not depend on low-level modules; both should depend on abstractions.
  6. Favor Composition Over Inheritance – Composition is a lot more flexible than inheritance and allows changes to the behavior of a class at run-time.
  7. Liskov Substitution Principle – Subtypes should be able to be substituted for their supertypes without any issues. To follow this principle, subclasses must enhance functionality and not reduce it.
  8.  Interface Segregation Principle (ISP) – Avoid monolithic interfaces that have multiple functionalities. This is intended to keep a system decoupled which makes it easier to change.
  9. Program For an Interface, Not an Implementation – Leads to flexible code that can work with any new implementation of an interface.
  10. Delegation Principle – Delegate tasks to specific classes. An example of this design principle is the equals() method in Java.

I chose this blog because I wanted to learn more about design principles. We have covered some of them in class, such as the open/closed principle and composition over inheritance. However, this blog introduced me to a few new ones like the Liskov Substitution principle and interface segregation principle. I thought this was a decent rundown of the most common design principles, but I could tell the author is not a native English speaker which made some parts not entirely clear. This encouraged me to look up other resources and now I feel like I have a firm grasp on all of these principles. I will be applying what I’ve learned to all future code I write because like the design patterns, they will make my code more flexible, readable, and easy to maintain.

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

What Is Needed to Make Automated Testing Successful? Some Basics…

Testing software can take up a lost of time. One way to reduce the time spent on testing is to automate it, meaning that a person doesn’t have to run each individual test manually. Automated testing is the way of the future, and there is information everywhere on it. Bas Dijkstra of StickyMinds.com discusses some of the basic principals of automated testing in his blog post, “5 Pillars of a Successful Test Automation Implementation”.

The first of the five pillars is the automation tool. Everybody has to have some sort of tool to help organize and run automated tests. Testing teams often overlook the tool and just go with whatever is available on hand. By doing this, they may be making their own lives more challenging. Take the time to make sure you have tool that fits your needs. I agree that this is an important first step. If you pick or are forced to use a tool that is poorly designed or doesn’t meet your needs, you are putting yourself behind the eight ball to start.

The second and third pillars discusses test data and test environments. Depending on how broad the scope of the tests are that are being run, data can become a pain to maintain. You want to make sure that you have this situation under control or you are asking for trouble. It is easy to imagine how out of hand and disorganized this could get in large scale testing. To go along with test data is the test environment. Have an environment that is as realistic as possible. Make sure it has everything you need to complete your testing and if possible, make it easy to replicate. This can allow you to run multiple tests is independent environments and/or continue with develop in one of the environments. Nothing is more frustrating that not having an environment to do you work on, whether another team member is using it, it is down for maintenance, etc. and one that is easy to duplicate can help eliminate this problem.

Next is reporting and craftsmanship. Reporting is vital as it allows others and yourself to analyze test results. Dijkstra suggests that a good report should show what went wrong, where it went wrong, and the error message that went with it. This can relate directly to craftsmanship as testing can be challenging if the correct skills aren’t available. There should be someone who has experience creating reports, for example. Make sure the correct developers, engineers, etc. are on hand to answers questions and help when needed.

My experience with automating testing is limited, which is why I have started to investigating it. From experience with manual testing, I can say that what Dijkstra discusses certainly applies, so I see no reason why it wouldn’t apply to automated testing too. I hope continue reading about automated testing as I feel it is an important and necessary tool/skill to have.

Link:

https://www.stickyminds.com/article/5-pillars-successful-test-automation-implementation

 

From the blog CS@Worcester – README by Matthew Foley and used with permission of the author. All other rights reserved by the author.

S.O.L.I.D. Design Principals – What Are They and What Purpose Do They Serve?

This week I went back to Professor Wurst’s concept map looking for some fresh material to research. This week’s topic of choice are the S.O.L.I.D. deign principals. These are design principals discussed and promoted by Uncle Bob (Robert C. Martin). The goal of having design principals is the make software easier to deal with, maintain, and expand upon. Samuel Oloruntoba does a great job at giving a general overview of these principles in his blog.

First things first – what does S.O.L.I.D. stand for? Well, it stands for Single-responsibility principal, Open-closed principal, Lisko substitution principle, Interface segregation principle, and Dependency inversion principle.

Single-Responsibility Principle: A class should only have one responsibility. In other words, a class should perform only one job. This can be applied to help make your program more modular. If you have a class that performs many tasks, it can become challenging to make changes to it.

Open-Closed Principle: It should be easy to extend a class without having to make changes within the class that needs to be extended. In other words, be prepared for the future. Don’t assume that the class/program will ever need to do additional things/serve a different purpose than it does today.

Liskov Substitution Principle:  Every subclass should be able to act as a substitute for the parent class. This once again promotes the ability to extend upon a program if need be.

Interface Segregation Principle: Don’t make people use methods or interfaces that they don’t need to use and/or are not needed. In my opinion, this can create unneeded work for the user and can cause confusion/be deceptive because it may not be clear what they need to do.

Dependency Inversion Principle: Items should depend on abstractions rather than concretions. Don’t pigeon hole yourself. This is probably best explained in an example: Say you have class LandscapeWorker with several methods including one that assigns a piece of equipment to them. Once could simple assign the equipment in the LandscapeWorker class, but then if they want to switch equipment, you would have to change the LandscapeWorker class that should not have to be changed. Instead, have an interface called equipment with separate classes for each piece of equipment, that way the class can simple be called.

I feel design principals are important as they help paint a picture of the logic and power behind programming languages they are designed to be used in. They cause you to think of new and better way to design code in ways you may not have beforehand. This is why I chose to discuss some of them this week. I feel that S.O.L.I.D. design principles are a good place to start for anyone, including those who are just starting out. I understand that I have barely scratched the surface with design principals in general and purpose behind the ones discussed here.  In the coming weeks, I hope to dive deeper into design principals and perhaps go in-depth into some of the principles discussed here. Stay tuned.

Link:

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

 

From the blog CS@Worcester – README by Matthew Foley and used with permission of the author. All other rights reserved by the author.

The Clean Coder 13 & 14 Week 7

The first part of this reading discusses teams. Teams are a very important part of completing a project. “The Gelled Team” is a very efficient way of forming a team, it usually consists of 12 people, some programmers, some testers and a project manager. This team needs to learn eachothers habits and learn to be able to work with them, this can sometimes take a long time but is necessary. This team can then take on multiple projects and is much more efficient.

The second part of the reading focuses on learning to program outside of school. A lot of programmers haven’t even gone to school, they teach themselves. The ones that do go to school are not ready to start coding right away, it takes years of learning the way an office works and how to perform efficiently.

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