I am in a software engineering class and I need to pick a design pattern to use for a 'feature'... I have two features, and one of them is to have a feature where a user can enter a zip code and time span of days (up to 7). A collection with weather ratings for each day is generated (say a vector of ints, with 1 being good and 3 being bad) that my teammates will use in the class to do various calculations with.

I just wanted some advice on a design pattern I can use because we are being forced to use one. I am using a singleton pattern for the GUI of the project, and I gotta think of one for this feature.

My thought process for the flow is as follows:

After user enters calculate, the GUI will call a function in this feature sending the zipcode and amount of days (to be stored in the GUI singleton maybe??) My feature will take the Zipcode and # of days and connect to an OpenWeatherAPI, and will need to Parse through a JSON format being returned and for each day rate the weather (something very simple like if temp is over 70 degrees, rating is a 1, between 50-70, ratings is 2, and below 50 rating is 3) and store this into a vector collection and return this. I just have to choose a pattern and justify why I chose it, create a class diagram, sequence diagram, etc. I was thinking of something that removed implementation from the interface, so maybe bridge? Honestly this 'feature' is small (probably isn't even a feature haha) and I don't know too much about design patterns.

Thank you so much in advance for your help!

  • 11
    Your professor is doing it wrong. The way you choose a software pattern is by identifying a specific problem in your software, and attempting to identify a software pattern that successfully solves the problem. Choosing a pattern and building your feature around it, or attempting to create a feature by stitching together software patterns, is backwards. Oct 26, 2017 at 3:08
  • 10
    You don't "pick" a design pattern. You analyze the problem and then write a solution until you recognize a pattern that you've seen before. Oct 26, 2017 at 6:37

2 Answers 2


Hmm, I choose, the Null Object Pattern!

Why? Cause I can. Seriously you could tack on any old damn pattern here.

Robert Harvey is right. This is a silly way to think. This is a solution in search of a problem.

Just start working and watch what you end up needing to be able to do. Don't look for patterns until you have a problem that justifies them. In fact try to just solve the problem. Once you're done you'll likely find you've already used a pattern without realizing it. If not then refactor until you have something that also makes the instructor happy. Just try not to turn the code to crap while doing it. Using patterns does not guarantee good code.

My favorite implementation of the null object pattern is the empty string: ""

If you can't find a place to use that then you're just not trying. ; )

If you want this to be more than a mindless exercise then be sure there is a reason to use the pattern. I use the null object pattern when I want something, that usually does something, to instead do nothing without complaining.


My suggestions:

So, as you said there would be a class which calls some weather API, and returns objects representing that data. Then, you have a facade class which simplifies the API, returning a list of integers representing the ratings. This facade class internally calls the more complex object that returns more complex data.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.