The Henry Used Car Dealership

March 15, 2019

Today’s exercise is simple, but leads me to ask a question. Here is the exercise, taken directly from /r/learnprogramming:

Draw the hierarchy chart and then plan the logic for a program needed by the sales manager of The Henry Used Car Dealership.

The program will determine the profit on any car sold. Input includes the sale price and actual purchase price for a car.

The output is the profit, which is the sale price minus the purchase price.

Use three modules. The main program declares global variables and calls housekeeping, detail, and end-of-job modules.

The housekeeping module prompts for and accepts a sale price. The detail module prompts for and accepts the purchase price, computes the profit, and displays the result. The end-of-job module displays the message Thanks for using this program.

I have written the actual program, but I am struggling with the hierarchy chart. Can someone give me any guidance on this one?

Is this for real? Separate modules for each statement? Why does the detail module get input, compute profit and display the result? If you have to have separate modules to ask for the purchase price and say thank you, why not split getting the sale price, computing the profit, and printing the result into separate modules? Is this how programming students are taught these days? To take a fundamentally simple program and make it ridiculously complex by splitting it into modules? What would David Parnas say about this modularization?

Your task is to write a program to compute profit for The Henry Used Car Dealership; you might also help me understand the way this program is intended to be modularized. When you are finished, you are welcome to read or run a suggested solution, or to post your own solution or discuss the exercise in the comments below.

Posted by programmingpraxis

Filed in Exercises

5 Comments »

5 Responses to “The Henry Used Car Dealership”

Vincent Manis said
March 15, 2019 at 7:08 PM
HIPO charts are so 1970s. A more modern exercise would require an 11-way multiple-inheritanced class hierarchy.
matthew said
March 16, 2019 at 9:42 AM
It does seem a little old-fashioned. This book seems to be the source: https://books.google.co.uk/books?id=s72HJL9Z-4AC&pg=PT97

Globules said

March 16, 2019 at 6:04 PM

Here’s a Haskell version. Its only trick is that it will prompt repeatedly until you enter a valid amount.

import Control.Monad (msum)
import Control.Monad.IO.Class (MonadIO, liftIO)
import Control.Monad.Trans.Maybe (MaybeT(..), runMaybeT)
import Data.Decimal (Decimal)
import Data.Maybe (fromJust)
import System.IO (hFlush, stdout)
import Text.Read (readMaybe)

getProfit :: MonadIO m => MaybeT m Decimal
getProfit = do
  purchPrice <- msum $ repeat $ readValue "Enter purchase price: "
  salePrice  <- msum $ repeat $ readValue "Enter sale price: "
  return (salePrice - purchPrice)

readValue :: (MonadIO m, Read a) => String -> MaybeT m a
readValue prompt = promptRead prompt >>= maybeRead

promptRead :: MonadIO m => String -> m String
promptRead prompt = liftIO $ putStr prompt >> hFlush stdout >> getLine

maybeRead :: Monad m => Read a => String -> MaybeT m a
maybeRead = MaybeT . return  . readMaybe

main :: IO ()
main = do
  profit <- fromJust <$> runMaybeT getProfit
  print profit

$ ./usedcar
Enter purchase price: dlkjflj
Enter purchase price: 12345.67
Enter sale price: 12567.89
222.22

Daniel said

March 21, 2019 at 7:41 PM

Here’s a solution in Python.

from decimal import Decimal


def housekeeping():
    global sale_price
    sale_price = Decimal(input('sale price> '))


def detail():
    global purchase_price
    purchase_price = Decimal(input('purchase price> '))
    profit = sale_price - purchase_price
    print('profit: {}'.format(profit))


def end_of_job():
    print('Thanks for using this program')


if __name__ == '__main__':
    housekeeping()
    detail()
    end_of_job()

Example Usage:

sale price> 20.00
purchase price> 10.00
profit: 10.00
Thanks for using this program

Richard A. O'Keefe said
August 19, 2024 at 1:09 PM
In response to @matthew, the book contains such gems as “In Chapter 2, you learned about many features of program modules,
also called methods.” It should come as no surprise that it makes HEAVY use of flowcharts, rather than say Nassi-Shneiderman charts. By the 1970s, we had learned a lot about program design and logic. They’re in the title of the book. But the book does not mention ‘assertion’, ‘precondition’, ‘postcondition’, (data structure) ‘invariant’ or (loop) ‘invariant’. ‘Termination’ is absent from the index, so good luck searching for advice on how to make sure your loops and recursions stop.

As a free speech advocate, I am pleased that such a book can find a publisher in the 21st century. But it makes me very sad that anyone would try to learn programming from such a book.

Programming Praxis