How to Break Down a Programming Problem
When you face a programming problem, whether it’s a problem description like in an OpenClassrooms project or user stories like in an agile workplace, you have to translate the concepts and the problem into code.
You’ll most likely refine a process for doing this throughout your career that works for you, and modify that process based on the project and the different processes and constraints.
Some developers prefer to plan, identifying each of the system elements before touching their IDE. You can identify the objects and operations that need to occur in the system, drawing diagrams (for example, UML diagrams), and taking notes.
Other developers prefer to use a more hands-on prototyping approach, where they’ll attempt to understand the problem by building it. With this approach, you have to be willing to throw out code as your design develops. You can start with one part of the problem, try different approaches, and use placeholder code and classes to model the interactions between other parts of your system.
Take a moment to consider the benefits and weaknesses of both of these approaches. Is there any way they can be used together?
Whichever process you end up using, there are a few things you need to discover.
What does your program or feature need to do? What additional features may be needed in the future? How do you ensure that your code is extensible so those modifications are possible?
What objects exist in the problem space? What are the responsibilities of each of the objects? What are they used for?
To what extent will this code be interacting with other systems and other code? What will the interfaces - the methods, functions, and other functionality that links your program with others - look like?
With that in mind, let’s try it! Throughout your development career, you’ll be carrying out this process many times - plenty of time for refinement and the integration of new ideas and methods.
Your Turn: Break Down a Problem
You’re designing an order management system for your workplace. It will have to interface with your company’s accounting system and the inventory management system, both of which are accessible using a REST interface.
REST interfaces are a common design pattern that you’ll likely encounter a lot in the modern world. Each REST interface will define ways to respond to HTTP (web) requests sent in a certain format and provide data and perform operations based on those requests.
You’re have been provided with the following sample user stories that you’ll need to base your initial design on:
As a supply manager, I want to see the inventory’s items and their corresponding stock, to make informed purchasing decisions.
As a supply manager, I wish to send orders to suppliers to buy items, so I can ensure that the company has the stock it needs.
As a supply manager, I want to send my orders to our accounting software so that our suppliers will be paid on time.
As a treasurer, I want orders over a certain amount to require my authorization to meet regulatory requirements.
As a warehouse worker, I want to mark orders as arrived so I can update the inventory.
You should consider and plan a design based on:
The different classes that would need to be written and their responsibilities.
How should the system interact with the other systems mentioned; what operations will likely need to be performed, and what data needs to be sent and received?
What screens (i.e., interface pages) will need to exist for all of the above functionality?
Practice Makes Perfect
Ready to take on a more complex programming problem? Complete the following 13-step mini-project and ensure your Python skills are robust! 😎
This exercise will take approximately 2 hours to complete.
You are not signed in
Sign in to access coding exercises and test your new skills.
When faced with a programming problem, you need to break the problem down into smaller parts.
You can consider the desired features, objects in the domain, and other code it has to interface with in the design.
Learning to break down a problem is a skill that is honed through repetition and experience.
Covering design and structure leaves us with just one more thing to do: handle errors. In the next - and last - chapter you’ll learn how to handle and create exceptions.