CSIS 112 Square Class

INSTRUCTIONS

Construct a class named Square that has a floating-point data member named side. The class should have a zero-argument constructor that initializes this data member to 0. It should have member functions named calcPerimeter() and calcArea() that calculate the perimeter and area of a square respectively, a member function setSide() to set the side of the square, a member function getSide() to return the side, and a member function showData() that displays the square's side, perimeter, and area. The formula for the area of a square is Area = side * side. The formula for the perimeter of a square is Perimeter = 4 * side.

The class should use appropriate protection levels for the member data and functions. It should also follow "principles of minimalization": that is, no member data should be part of a class unless it is needed by most member functions of the object. A general rule of thumb is that if you can easily calculate it, don't store it.

Use your class in a program that creates an instance of a Square (utilizing the zero-argument constructor), prompts a user for a side, calls the setSide() function to set the square's side, and then calls showData() to display the squares side, perimeter, and area. Your program should allow the user to enter new square dimensions until the user enters -1. Be sure to include appropriate error checking. Does it make sense to enter "abc" as the side of a square? No. Therefore, you should ensure that the user enters numeric data for the side. Negative numbers (other than the -1 to exit) should also be prevented.

Style:

• Your lab should be constructed such that separate files are used: Square.h (your class declaration file), Square.cpp (your class implementation file), and SquareDriver.cpp (the file that contains main() and any other functions that are not part of the class).
• The purpose of having separate files is for code resusability. If other developers want to use your class in their programs, they don't need main() as well. They should only have to "#include" your class header file. As such, two separate files for the class are needed to be able to hide the implementation details from other developers. You want other developers to know how to use your class (i.e. what functions are available and how they are called -- this is called the "interface" of the class), but not how they are implemented.
• f both the interface and the implementation code are in the same file, this cannot be accomplished. When you distribute your class to other developers, the implementation (.cpp) file gets compiled, but the interface (.h) doesn't. That way, the developer can use your class, but he or she can't see or change your code in your class functions.
• Never use "using namespace std;" in a header file. Here is a link that describes why: https://stackoverflow.com/questions/14575799/using-namespace-std-in-a-header-file
• Note that when you follow the rule above and don't use "using namespace std;" in a header file, you have to remember to prefix certain things with std:: (i.e. cout, cin, endl, string, istream, ostream, and vector). If you fail to prefix these words with std::, you will get a compilation error that is often quite cryptic. Be on the lookout for this situation. It may save you hours of debugging.
• All "get" functions should be declared as constant. In fact, any function that does not change the data in the data members should be declared as constant. This is a security measure that prevents anyone from accidentally writing code in a function that changes underlying data when the purpose of the function is only to retrieve the data. In other words, "const" at the end of a function provides protection of your data. The rationale is that certain functions (e.g. those that merely return a data item to the caller or even those that just print the data) should be prevented from ever changing the underlying data. If a function doesn't need "write" access to a data item, it shouldn't be granted the access. This adheres to the "Principle of Least Privilege," which is a security principle that helps to protect the integrity of your data.
• One other thing that's important to know for future reference: Whenever you make a function constant, it can't call another function unless that function is also constant. It makes sense that if you lock down an object in a function, you don't want to open it up for modifications by calling another function that allows it to be inadvertently altered. If you ever try to call a function that is not constant from a function that is constant, you will get a compilation error.
• showData() should not refer to the data members directly. Instead, it should call getSide() to retrieve its value. Think of your getters and setters as middlemen. You should try to avoid accessing your data members directly due to maintenance issues. Pretend that you decided to change the name of your side variable to be "sid". You really should only have to make that change in two functions: getSide and setSide. If you refer to the private data members directly throughout your code, you'll have a nightmare trying to make all the changes necessary. If you always use the getters to retrieve your data, any changes you make to the variable name will only necessitate changes to your get function rather than your whole code base.
• CalcPerimeter, CalcArea, and ShowData should not have the side passed in as an argument because side is a data member of the class. Class functions have direct access to all data members in their own class. By passing in an argument for the value of the side, you're not using the value that has already been stored in the data member. You're using the value that you've passed in to the functions, which circumvents the whole purpose of storing side in the class.
• Use good prompting (correct spelling and clear instructions), output labeling, and modularization in your program and class.
• Be sure to avoid using global variables in your program unless they are constants.
• Finally, be sure not to include any unnecessary libraries.