CS 3140代做、代写java语言编程
- 首页 >> Python编程 CS 3140 - SDE Spring 2024
HW 3: Apportionment Refactored
1. Getting Started
In Unit III of our course, you learned that code refactoring is like giving your code a makeover.
It's the process of improving the structure, organization, and functionality of your code without
changing its external behavior. Refactoring can not only make your code easier to read,
maintain, and debug, but it can also increase its performance and efficiency. It's a skill that every
developer should master, as it's often the key to unlocking the true potential of their code.
In this assignment, we will revisit and refactor HW1-C. You are given an implementation of HW1
written by Prof. Will McBurney, the course's original designer. For reasons of academic
honesty, this implementation code may not be reposted anywhere or shared with anyone.
The assignment is divided into 4 parts:
● Part A - Refactor an Apportionment method
● Part B - Add a new concrete implementer to ApportionmentFormat
● Part C - Designed three classes ApportionmentMethodFactory,
StateSupplierFactory, and RepresentationFormatFactory, to instantiate and
return the correct concrete implementation of the functionality of our software.
1
CS 3140 - SDE Spring 2024
● Part D - Reimplement a new command-line arguments system
You may tackle these parts in any order, though doing Part C before you do Part D is
recommended since the new Arguments implementation should use the Factories created in
Part C.
Note on Piazza: For this and future assignments, we are back to our regular Piazza policies,
meaning it's completely okay (and encouraged) to ask public questions on Piazza about the
specification, starter code, etc.
Team Repository: Teams of up to 3 are allowed. You may have teammates from your previous
team or find new ones. However, you can only work with the same person up to 4 times.
1. Decide if you are working alone or if you are working in a group of up to 3 members. All
team members must have their NetID in the team repository name. In this assignment,
you will add the prefix “Refactor” to your team name. For example, a team of netID1,
netID2, and netID3 must follow this format: “Refactor-netID1-netID2-netID3”
2. Click on this GitHub Classroom Invite: https://classroom.github.com/a/fB4JiPvY
and create the git repository you and your team will use. If you miss this step, make a
private "rename repo" request on Piazza.
3. Using IntelliJ, clone the repository to your local computer in the root directory of your
project (by default, named HW3-starter-repo).
2. Program Specifications
This implementation additionally has three extra features, including 2 apportionment methods
that were not in Homework 1:
● AdamsMethod.java, which is used by adding "--adams" to the command line
○ You will rewrite the argument handling in a later part. The implementation will no
longer have the "--adams" flag.
● JeffersonMethod.java, which is used by adding “--jefferson” to the command
line
○ You will rewrite the argument handling in a later part. The implementation will no
longer have the "--jefferson" flag.
● PopulationFormat.java, which can display the apportionment in order of
population (ascending or descending).
As a rule, do not change any existing public or protected class interfaces (that is, do not change
the method declarations, and do not change their behavior) unless explicitly told to do so.
Additionally, do not remove any existing tests except for ArgumentsTest, which you will want
to replace in Part D completely. These tests help ensure you don't "break" any working features
when adding new code. You may add additional tests if they help. However, be aware that we
will run all existing tests except those in ArgumentsTest (as well as new tests) when grading
your code, and you will lose points for any test failures.
2
CS 3140 - SDE Spring 2024
In general, I would expect you only to need to change the following source files:
● Arguments.java (which you will replace completely in part D)
● Any of the classes that you add
● ArgumentsTest.java (which you are encouraged to replace with your tests)
2.1. Part A - Reimplement an Apportionment Method
You will expand some features from Homework 1C in the HuntingtonHill Method. You will
re-design the Huntington-Hill to implement the ApportionmentMethod interface and return a
Representation. You can refer back to HW1-C for an example of implementing the
Huntington-Hill Method and reusing any code from Homework 1C from any team member. The
class declaration should be:
public class HuntingtonHillMethod implements ApportionmentMethod {}
This class should not have any constructors! We will instantiate it with an implicit zero-argument
constructor. As part of the ApportionmentMethod interface, the getRepresentation function
should calculate how many representatives each state receives using the Huntington-Hill
algorithm and return an appropriate Representation.
Implementation Note: These methods may not change any code outside their class. Refrain
from modifying how command line arguments are handled (we will discuss that in Parts C and
D). You can reference existing code, but you must not change it! We intend to use
polymorphism to help ensure our new code can be added without changing existing code in
other software parts (though you can re-use code outside of the class, such as
Apportionment).
2.2. Part B - Add a New Feature: Relative Benefit
Since our code now supports a few apportionment methods, we want to add a Relative Benefit
feature to help users compare different apportionment methods. You will learn how to calculate
the relative benefit of an apportionment strategy and format it for display on the console. To do
this, you will implement a new class called RelativeBenefitFormat.
RelativeBenefitFormat
Looking at the table of the Jefferson method with our starting Divisor based on the Total
Population divided by the number of Representatives (described in Appendix A). The
RoundedDown column was replaced with the number of representatives given to the state.
Name Population Raw Final reps Benefit
Delaware 989948 0.808914 0 -0.808914
Maryland 6177224 5.04758 5 -0.04758
3
CS 3140 - SDE Spring 2024
Pennsylvania 13002700 10.62486 12 +1.37514
Virginia 8631393 7.052948 7 -0.052948
West Virginia 1793716 1.465695 1 -0.465695
From this table, we can see how much a state benefited from or was hurt by the
apportionment method:
Benefit = [final reps] - [raw]
In this case, we can say Pennsylvania benefitted the most from our use of the Jefferson
Apportionment method (then ended up with nearly 1.4 more reps than you would expect from
their raw number), whereas Delaware was hurt the most (they would expect roughly 0.8 reps -
they got 0). Using this information, here is how your printed format should look:
State | Reps|Benefits
Pennsylvania | 12| +1.375
Maryland | 5| -0.048
Virginia | 7| -0.053
West Virginia | 1| -0.466
Delaware | 0| -0.809
Format Description:
● A header row as shown above
● Vertical bars to indicate columns
● 16 characters left-aligned for state name
● 5 right-aligned for Reps. The number must be an integer
● 7 or 8 characters right-aligned for Benefit.(previously said 7, but example was 8, both ok)
○ the number must have exactly 3 decimal places,
○ + sign must be included for positive benefit values
○ - sign for negative numbers
○ 0.000 should have no sign.
That is, states should be sorted by benefit for the given algorithm. While this example uses the
Jefferson method, this relative benefit should work with ANY apportionment method.
The RelativeBenefitFormat class will also use our divisor. This could involve copying
commonly used code to a library accessible by many classes. Consider again how to approach
making our code D.R.Y. “Don’t Repeat Yourself”, and avoiding copying and pasting code.
The RelativeBenefitFormat should have a private field of type DisplayOrder which determines
the displayOrder class should have two constructors:
● public RelativeBenefitFormat() - defaults the DisplayOrder field to
DESCENDING.
4
CS 3140 - SDE Spring 2024
● public RelativeBenefitFormat(DisplayOrder displayOrder) - directly sets
the DisplayOrder field but throws an IllegalArgumentException if DisplayerOrder is
null.
Do not add any additional constructors.
I recommend looking at PopulationFormat when writing this class, as you should find that it
helps you out considerably, especially with how to handle DisplayOrder.
The interesting part of implementing this is getting each state's quota, since the function is
limited to taking in a Representation object. Be aware that you can calculate the quotas from
the Representation (either by writing the code yourself or re-using the default methods in
ApportionmentMethod.java).
2.3. Part C: Extracting Classes
By now, we should note that the Arguments class violates the Single Responsibility Principle:
"A class should only have one reason to change." Arguments could change because
1. We change the argument format
2. We implement new concrete implementations we want our program to use:
a. New input file format
b. New apportionment algorithm
c. New output String format
This means we have 4 reasons to change. Let's fix that before we start making changes to
Arguments class. You will make 3 Factory classes, each with 1-3 methods. These classes are
called Factory because they implement a creational design pattern called the Factory Pattern (to
be revealed later in the course). As a hint, all of these methods should be very simple,
basically just if-statements or switch statements that return new instances of the intended class.
The "default" factory methods should just be one-line return statements! If you find that any
method is more than 8 or so lines of code, you need to do something differently!
Factory 1: StateSupplierFactory
● public StateSupplier getStateSupplier(String filename) - Returns a new
StateSupplier (either CSVStateReader or SpreadsheetStateReader) depending on the
ending of the filename. This method will be very similar to the existing getStateSupplier
method in Arguments, but this method takes in the filename directly, rather than
extracting it from the command-line arguments. It should throw an
UnsupportedFileFormatException for invalid filenames.
5
CS 3140 - SDE Spring 2024
Factory 2: ApportionmentMethodFactory
○ public ApportionmentMethod getDefaultApportionmentMethod()-
Returns a new instance of the default apportionment method, HuntingtonHillMethod
○ public ApportionmentMethod getApportionmentMethod(String method)-
Returns a new instance of ApportionmentMethod (JeffersonMethod, AdamsMethod, or
HuntingtonHillMethod). The input string will be the command-line parameter associated
with the --method argument you will implement in Part D. Specifically, the input String
will be either "adams", "jefferson", or "huntington". Any other string input should
result in an IllegalArgumentException with a meaningful error message.
Factory 3: RepresentationFormatFactory
● public RepresentationFormat getDefaultRepresentationFormat() - Returns a
new instance of the default representation format, AlphabeticalFormat
● public RepresentationFormat getRepresentationFormat(String name) -
Returns a new instance of implementation of RepresentationFormat
(AlphabeticalFormat, RelativeBenefitFormat, or PopulationFormat). The input string will
be the command-line parameter associated with the --format argument that you will
implement in Part D. Specifically, the input String will be either "alpha", "benefit", or
"population". For benefit and population, use their default displayOrder (descending
and ascending respectively). Any other string input should result in an
IllegalArgumentException with a meaningful error message.
● public RepresentationFormat getRepresentationFormat(String name,
DisplayOrder order) - Does the same thing as getRepresentationFormat(String),
but allows the DisplayOrder to be specified (note that for AlphabeticalFormat, the
display order should be ignored.
Do not add any constructors to these Factories! All instantiation should be done using the
implicit zero argument constructor that all classes without an explicit constructor have.
Additionally, the classes shouldn't have any instance variables, though you are welcome to use
static constants. (public static final [type] [variable name])
Example Factory usage: If working correctly, then your usage of a given Factory will look
something like this:
StateSupplierFactory factory = new StateSupplierFactory();
StateSupplier supplier = factory.getStateSupplier(filename);
In this case, if the filename is a .csv file, the supplier will be an instance of CSVStateReader. If
the filename is an .xls or .xlsx file, the supplier will be an instance of SpreadsheetStateReader.
6
CS 3140 - SDE Spring 2024
2.4. Part D - Arguments rewrite
Note: You should implement Part C before attempting to implement this part.
Now that we have extracted the factories, we can re-implement Arguments based on the new
specification for handling requirements and ensure our project is scalable.
Tips: I recommend starting by deleting all of the implementations of all methods in
Arguments.java, but leaving the method declarations. You should also delete/comment
out all of the previous tests in ArgumentsTest.java, as those tests are incompatible with
the format of the new argument.
We can re-implement Arguments based on the new specification for handling requirements.
Arguments will still handle the same basic tasks:
● Take in the String[] args from Main via the Constructor.
● Providing the methods:
○ public StateSupplier getStateSupplier()
○ public int getRepresentatives()
○ public ApportionmentMethod getApportionmentMethod()
○ public RepresentationFormat getRepresentationFormat()
○ (these methods must still be present! - no interface change!)
However, rather than Arguments selecting which concrete implementers to use for
Configuration, it simply interacts with the Factories we wrote in Part C to do so. We are setting
up a framework for having a more customizable approach. So we're going to reset our
command-line arguments. We will still require one argument:
java -jar Apportionment.jar filename
Where filename is the name of the census population file (such as census2020.csv) - this
needs to accept both .csv and .xlsx files. From there, we want all our other arguments done in a
way that many modern programs handle optional arguments: … with flags!
Long Flag arguments
For simplicity, you can assume everything is case sensitive - we will only test your arguments
with lowercase letters.
java -jar Apportionment.jar census2020.xlsx --reps 1000 --format benefit
--algorithm jefferson
In this example, we have three optional arguments defined:
● --reps 1000 - run apportionment with 1000 representatives
● --format benefit - print results using RelativeBenefitFormat
● --algorithm jefferson - use JeffersonMethod
7
CS 3140 - SDE Spring 2024
In this case, the flag specifies the name of the argument, and the next argument specifies the
value of the argument. It's important that the optional arguments can be in any order, but
the argument must follow the flag directly. For example, the following is also a valid command.
java -jar Apportionment.jar census2020.xlsx --algorithm jefferson --reps 1000
List of optional arguments: This lists all optional arguments.
● --reps [integer] - must be followed by a positive (non-zero, non-negative) integer.
Throw a meaningful exception if the input is invalid.
○ Defaults to --reps 435
● --format formatName - set the format name. Format choices:
○ --format alpha - print States (AlphabeticalApportionmentFormat)
○ This is the default value
○ --format benefit - prints States by benefit (RelativeBenefitFormat)
○ --format population - prints States by population (PopulationFormat)
○ Anything else is invalid, a meaningful exception should be thrown
● --algorithm strategyName - set the Apportionment method
○ --algorithm adams - use Adams Apportionment algorithm
○ --algorithm jefferson - use Jefferson Apportionment algorithm
○ --algorithm huntington - use Huntington-Hill Apportionment algorithm
○ This is the default value
Short Flag arguments:
Short flags work largely the same way as long flags. For instance, long flag arguments:
java -jar Apportionment.jar census2020.xlsx --reps 1000 --format benefit
--algorithm jefferson
Could also be written as a short flag form:
java -jar Apportionment.jar census2020.xlsx -r 1000 -f benefit -a jefferson
That is:
● -r is short for --reps
● -f is short for --format
● -a is short for --algorithm
However, unlike long flags, short flags can be combined. For example,
java -jar Apportionment.jar census2020.xlsx -rfa 1000 benefit jefferson
Specifically, -rfa means that:
● The next argument (1000) is -r (--reps)
8
CS 3140 - SDE Spring 2024
● The argument after that (benefit) is -f (--format)
● And the argument after that (jefferson) is -a (--algorithm)
Just like long flags, these can go in any order, and only include some arguments:
java -jar Apportionment.jar census2020.xlsx -af jefferson alpha
The above means:
● Use the Jefferson Apportionment algorithm
● Print states alphabetically
● Use 435 reps (default)
A few words of encouragement: If you have followed the instructions and implemented the
code to the end of this part, congratulations! You have written a pretty complex piece of software
with several long and short flag arguments! This is no small feat, as it demonstrates a mastery
of functional and clean code design. I hope you take pride in what you have accomplished.
Keep up the awesome work, and continue to push yourselves to new heights in your future
projects!
3. Submission and Grading
Ensure all work has been merged to the main branch, then submit, as usual, answer the
questions on the Questions.md.
The coding portion of this assignment will be graded solely based on correct functionality, like
Homework 1 and 2. While we encourage practicing good style and testing (as they will likely
make developing the homework more efficient), we will not be grading anything other than the
functionality for the coding portion. Make sure your class and method names match this
document - we will use automated testing during this assignment to ensure efficient grading.
You should try to make your code DRY, but you will not be graded.
Functionality: We are only grading how correctly your code functions:
● Team Declaration: 5%
● Code Submission
○ Part A - 20%
○ Part B - 20%
○ Part C - 15%
○ Part D - 25%
● Submission and Reflection Questions - 20% (including 5% for Team Declaration)
○ 10% for answering the questions in Questions.md
○ 5% for filling out the Github information and setting up repo correctly
9
CS 3140 - SDE Spring 2024
4. Frequently Asked Questions
Q: Can I add code my team implemented in HW1-C?
A: Yes, you may add code that your team developed from HW1-C
Q: How do we access methods from an Apportionment if they are private?
A: You are welcome to **increase** the visibility level of any method (i.e., any private method
can be made protected or public, and any protected method can be made public).
Q: If a flag is syntactically incorrect/invalid ("-reps", "reps", or "--numreps") or if some
flag is missing, should we throw an error or should we allow the program to continue
running with the default configurations?
A: Any invalid flags or arguments not attached to flags should throw an error.
Q: Can I change the Method Signatures of Factory Classes?
A: No, you must adhere to the specification as given, only because it will make the grading job
more accessible if they can just use the automated test which relies upon a specific interface.
Q: May we use an external library to implement Arguments?
A: Yes. This is acceptable and in my view an intelligent thing to do. If you find the wheel that
works perfectly well, you don't need to invent a new one. Just make sure you do a proper import
through Gradle Dependencies.
Appendix A - Jefferson Apportionment Method
In this assignment, we will extend the pool of Apportionment methods with a new algorithm:
Jefferson Apportionment Method. As in Homework 1 with Hamilton and Huntington-Hill, we will
quickly illustrate the Jefferson Apportionment Method starting with these five states. For the first
few steps, this will look a lot like Hamilton. This Youtube video on Apportionment describes the
Jefferson Apportionment algorithm starting at the 13-minute mark.
In this example, we will be using 25 representatives once again.
Name Population
Delaware 989948
Maryland 6177224
Pennsylvania 13002700
Virginia 8631393
10
CS 3140 - SDE Spring 2024
West Virginia 1793716
Like with the Hamilton Method from HW1-A/B, we are going to get the total population
(30,594,981) and divide by our number of representatives (25) to get our divisor (roughly
1,223,799.24). And just like in Hamilton, we will divide every state by the divisor (Raw, in the
table below) and then Round all states DOWN (RoundedDown in the table below.)
Name Population Raw Rounded Down
Delaware 989948 0.808914 0
Maryland 6177224 5.04758 5
Pennsylvania 13002700 10.62486 10
Virginia 8631393 7.052948 7
West Virginia 1793716 1.465695 1
Now, if we were to allocate reps equal to the number rounded down, we would be allocating 23
representatives, which is two fewer than we should.
This is the part where we break away from Hamilton. In the Jefferson method, rather than
dealing with remainders, we instead change the divisor. That is, we start decreasing the value
of our divisor until we have allocated all 25 representatives.
So, for instance, if we change our divisor to 1.1 million (1,100,000), then our table becomes:
Name Population Raw Rounded Down
Delaware 989948 0.899953 0
Maryland 6177224 5.615658 5
Pennsylvania 13002700 11.82064 11
Virginia 8631393 7.846721 7
West Virginia 1793716 1.630651 1
We've allocated 24 representatives, but we are still short of 25. If we drop our divisor to 1
million (1,000,000), however, then we end up allocating too many representatives:
11
CS 3140 - SDE Spring 2024
Name Population Raw Rounded Down
Delaware 989948 0.989948 0
Maryland 6177224 6.177224 6
Pennsylvania 13002700 13.0027 13
Virginia 8631393 8.631393 8
West Virginia 1793716 1.793716 1
So that means 1 million is too small. I then tried 1.08 million (1,080,000) and got 25:
Name Population Raw Rounded Down
Delaware 989948 0.916619 0
Maryland 6177224 5.719652 5
Pennsylvania 13002700 12.03954 12
Virginia 8631393 7.992031 7
West Virginia 1793716 1.660848 1
Since we now have 25 representatives allocated, we stop here and accept this number. Yes,
this leaves Delaware without representation, but for the sake of simplicity, you should not try to
enforce "every state gets at least one representative" here. This would be the correct
Apportionment for this input.
Fun fact: In 1992, if Congress had been apportioned by the Jefferson method, Al Gore would
have won the 2000 Presidential Election even if no votes were changed. This is because
Jefferson heavily favors larger states.
12
HW 3: Apportionment Refactored
1. Getting Started
In Unit III of our course, you learned that code refactoring is like giving your code a makeover.
It's the process of improving the structure, organization, and functionality of your code without
changing its external behavior. Refactoring can not only make your code easier to read,
maintain, and debug, but it can also increase its performance and efficiency. It's a skill that every
developer should master, as it's often the key to unlocking the true potential of their code.
In this assignment, we will revisit and refactor HW1-C. You are given an implementation of HW1
written by Prof. Will McBurney, the course's original designer. For reasons of academic
honesty, this implementation code may not be reposted anywhere or shared with anyone.
The assignment is divided into 4 parts:
● Part A - Refactor an Apportionment method
● Part B - Add a new concrete implementer to ApportionmentFormat
● Part C - Designed three classes ApportionmentMethodFactory,
StateSupplierFactory, and RepresentationFormatFactory, to instantiate and
return the correct concrete implementation of the functionality of our software.
1
CS 3140 - SDE Spring 2024
● Part D - Reimplement a new command-line arguments system
You may tackle these parts in any order, though doing Part C before you do Part D is
recommended since the new Arguments implementation should use the Factories created in
Part C.
Note on Piazza: For this and future assignments, we are back to our regular Piazza policies,
meaning it's completely okay (and encouraged) to ask public questions on Piazza about the
specification, starter code, etc.
Team Repository: Teams of up to 3 are allowed. You may have teammates from your previous
team or find new ones. However, you can only work with the same person up to 4 times.
1. Decide if you are working alone or if you are working in a group of up to 3 members. All
team members must have their NetID in the team repository name. In this assignment,
you will add the prefix “Refactor” to your team name. For example, a team of netID1,
netID2, and netID3 must follow this format: “Refactor-netID1-netID2-netID3”
2. Click on this GitHub Classroom Invite: https://classroom.github.com/a/fB4JiPvY
and create the git repository you and your team will use. If you miss this step, make a
private "rename repo" request on Piazza.
3. Using IntelliJ, clone the repository to your local computer in the root directory of your
project (by default, named HW3-starter-repo).
2. Program Specifications
This implementation additionally has three extra features, including 2 apportionment methods
that were not in Homework 1:
● AdamsMethod.java, which is used by adding "--adams" to the command line
○ You will rewrite the argument handling in a later part. The implementation will no
longer have the "--adams" flag.
● JeffersonMethod.java, which is used by adding “--jefferson” to the command
line
○ You will rewrite the argument handling in a later part. The implementation will no
longer have the "--jefferson" flag.
● PopulationFormat.java, which can display the apportionment in order of
population (ascending or descending).
As a rule, do not change any existing public or protected class interfaces (that is, do not change
the method declarations, and do not change their behavior) unless explicitly told to do so.
Additionally, do not remove any existing tests except for ArgumentsTest, which you will want
to replace in Part D completely. These tests help ensure you don't "break" any working features
when adding new code. You may add additional tests if they help. However, be aware that we
will run all existing tests except those in ArgumentsTest (as well as new tests) when grading
your code, and you will lose points for any test failures.
2
CS 3140 - SDE Spring 2024
In general, I would expect you only to need to change the following source files:
● Arguments.java (which you will replace completely in part D)
● Any of the classes that you add
● ArgumentsTest.java (which you are encouraged to replace with your tests)
2.1. Part A - Reimplement an Apportionment Method
You will expand some features from Homework 1C in the HuntingtonHill Method. You will
re-design the Huntington-Hill to implement the ApportionmentMethod interface and return a
Representation. You can refer back to HW1-C for an example of implementing the
Huntington-Hill Method and reusing any code from Homework 1C from any team member. The
class declaration should be:
public class HuntingtonHillMethod implements ApportionmentMethod {}
This class should not have any constructors! We will instantiate it with an implicit zero-argument
constructor. As part of the ApportionmentMethod interface, the getRepresentation function
should calculate how many representatives each state receives using the Huntington-Hill
algorithm and return an appropriate Representation.
Implementation Note: These methods may not change any code outside their class. Refrain
from modifying how command line arguments are handled (we will discuss that in Parts C and
D). You can reference existing code, but you must not change it! We intend to use
polymorphism to help ensure our new code can be added without changing existing code in
other software parts (though you can re-use code outside of the class, such as
Apportionment).
2.2. Part B - Add a New Feature: Relative Benefit
Since our code now supports a few apportionment methods, we want to add a Relative Benefit
feature to help users compare different apportionment methods. You will learn how to calculate
the relative benefit of an apportionment strategy and format it for display on the console. To do
this, you will implement a new class called RelativeBenefitFormat.
RelativeBenefitFormat
Looking at the table of the Jefferson method with our starting Divisor based on the Total
Population divided by the number of Representatives (described in Appendix A). The
RoundedDown column was replaced with the number of representatives given to the state.
Name Population Raw Final reps Benefit
Delaware 989948 0.808914 0 -0.808914
Maryland 6177224 5.04758 5 -0.04758
3
CS 3140 - SDE Spring 2024
Pennsylvania 13002700 10.62486 12 +1.37514
Virginia 8631393 7.052948 7 -0.052948
West Virginia 1793716 1.465695 1 -0.465695
From this table, we can see how much a state benefited from or was hurt by the
apportionment method:
Benefit = [final reps] - [raw]
In this case, we can say Pennsylvania benefitted the most from our use of the Jefferson
Apportionment method (then ended up with nearly 1.4 more reps than you would expect from
their raw number), whereas Delaware was hurt the most (they would expect roughly 0.8 reps -
they got 0). Using this information, here is how your printed format should look:
State | Reps|Benefits
Pennsylvania | 12| +1.375
Maryland | 5| -0.048
Virginia | 7| -0.053
West Virginia | 1| -0.466
Delaware | 0| -0.809
Format Description:
● A header row as shown above
● Vertical bars to indicate columns
● 16 characters left-aligned for state name
● 5 right-aligned for Reps. The number must be an integer
● 7 or 8 characters right-aligned for Benefit.(previously said 7, but example was 8, both ok)
○ the number must have exactly 3 decimal places,
○ + sign must be included for positive benefit values
○ - sign for negative numbers
○ 0.000 should have no sign.
That is, states should be sorted by benefit for the given algorithm. While this example uses the
Jefferson method, this relative benefit should work with ANY apportionment method.
The RelativeBenefitFormat class will also use our divisor. This could involve copying
commonly used code to a library accessible by many classes. Consider again how to approach
making our code D.R.Y. “Don’t Repeat Yourself”, and avoiding copying and pasting code.
The RelativeBenefitFormat should have a private field of type DisplayOrder which determines
the displayOrder class should have two constructors:
● public RelativeBenefitFormat() - defaults the DisplayOrder field to
DESCENDING.
4
CS 3140 - SDE Spring 2024
● public RelativeBenefitFormat(DisplayOrder displayOrder) - directly sets
the DisplayOrder field but throws an IllegalArgumentException if DisplayerOrder is
null.
Do not add any additional constructors.
I recommend looking at PopulationFormat when writing this class, as you should find that it
helps you out considerably, especially with how to handle DisplayOrder.
The interesting part of implementing this is getting each state's quota, since the function is
limited to taking in a Representation object. Be aware that you can calculate the quotas from
the Representation (either by writing the code yourself or re-using the default methods in
ApportionmentMethod.java).
2.3. Part C: Extracting Classes
By now, we should note that the Arguments class violates the Single Responsibility Principle:
"A class should only have one reason to change." Arguments could change because
1. We change the argument format
2. We implement new concrete implementations we want our program to use:
a. New input file format
b. New apportionment algorithm
c. New output String format
This means we have 4 reasons to change. Let's fix that before we start making changes to
Arguments class. You will make 3 Factory classes, each with 1-3 methods. These classes are
called Factory because they implement a creational design pattern called the Factory Pattern (to
be revealed later in the course). As a hint, all of these methods should be very simple,
basically just if-statements or switch statements that return new instances of the intended class.
The "default" factory methods should just be one-line return statements! If you find that any
method is more than 8 or so lines of code, you need to do something differently!
Factory 1: StateSupplierFactory
● public StateSupplier getStateSupplier(String filename) - Returns a new
StateSupplier (either CSVStateReader or SpreadsheetStateReader) depending on the
ending of the filename. This method will be very similar to the existing getStateSupplier
method in Arguments, but this method takes in the filename directly, rather than
extracting it from the command-line arguments. It should throw an
UnsupportedFileFormatException for invalid filenames.
5
CS 3140 - SDE Spring 2024
Factory 2: ApportionmentMethodFactory
○ public ApportionmentMethod getDefaultApportionmentMethod()-
Returns a new instance of the default apportionment method, HuntingtonHillMethod
○ public ApportionmentMethod getApportionmentMethod(String method)-
Returns a new instance of ApportionmentMethod (JeffersonMethod, AdamsMethod, or
HuntingtonHillMethod). The input string will be the command-line parameter associated
with the --method argument you will implement in Part D. Specifically, the input String
will be either "adams", "jefferson", or "huntington". Any other string input should
result in an IllegalArgumentException with a meaningful error message.
Factory 3: RepresentationFormatFactory
● public RepresentationFormat getDefaultRepresentationFormat() - Returns a
new instance of the default representation format, AlphabeticalFormat
● public RepresentationFormat getRepresentationFormat(String name) -
Returns a new instance of implementation of RepresentationFormat
(AlphabeticalFormat, RelativeBenefitFormat, or PopulationFormat). The input string will
be the command-line parameter associated with the --format argument that you will
implement in Part D. Specifically, the input String will be either "alpha", "benefit", or
"population". For benefit and population, use their default displayOrder (descending
and ascending respectively). Any other string input should result in an
IllegalArgumentException with a meaningful error message.
● public RepresentationFormat getRepresentationFormat(String name,
DisplayOrder order) - Does the same thing as getRepresentationFormat(String),
but allows the DisplayOrder to be specified (note that for AlphabeticalFormat, the
display order should be ignored.
Do not add any constructors to these Factories! All instantiation should be done using the
implicit zero argument constructor that all classes without an explicit constructor have.
Additionally, the classes shouldn't have any instance variables, though you are welcome to use
static constants. (public static final [type] [variable name])
Example Factory usage: If working correctly, then your usage of a given Factory will look
something like this:
StateSupplierFactory factory = new StateSupplierFactory();
StateSupplier supplier = factory.getStateSupplier(filename);
In this case, if the filename is a .csv file, the supplier will be an instance of CSVStateReader. If
the filename is an .xls or .xlsx file, the supplier will be an instance of SpreadsheetStateReader.
6
CS 3140 - SDE Spring 2024
2.4. Part D - Arguments rewrite
Note: You should implement Part C before attempting to implement this part.
Now that we have extracted the factories, we can re-implement Arguments based on the new
specification for handling requirements and ensure our project is scalable.
Tips: I recommend starting by deleting all of the implementations of all methods in
Arguments.java, but leaving the method declarations. You should also delete/comment
out all of the previous tests in ArgumentsTest.java, as those tests are incompatible with
the format of the new argument.
We can re-implement Arguments based on the new specification for handling requirements.
Arguments will still handle the same basic tasks:
● Take in the String[] args from Main via the Constructor.
● Providing the methods:
○ public StateSupplier getStateSupplier()
○ public int getRepresentatives()
○ public ApportionmentMethod getApportionmentMethod()
○ public RepresentationFormat getRepresentationFormat()
○ (these methods must still be present! - no interface change!)
However, rather than Arguments selecting which concrete implementers to use for
Configuration, it simply interacts with the Factories we wrote in Part C to do so. We are setting
up a framework for having a more customizable approach. So we're going to reset our
command-line arguments. We will still require one argument:
java -jar Apportionment.jar filename
Where filename is the name of the census population file (such as census2020.csv) - this
needs to accept both .csv and .xlsx files. From there, we want all our other arguments done in a
way that many modern programs handle optional arguments: … with flags!
Long Flag arguments
For simplicity, you can assume everything is case sensitive - we will only test your arguments
with lowercase letters.
java -jar Apportionment.jar census2020.xlsx --reps 1000 --format benefit
--algorithm jefferson
In this example, we have three optional arguments defined:
● --reps 1000 - run apportionment with 1000 representatives
● --format benefit - print results using RelativeBenefitFormat
● --algorithm jefferson - use JeffersonMethod
7
CS 3140 - SDE Spring 2024
In this case, the flag specifies the name of the argument, and the next argument specifies the
value of the argument. It's important that the optional arguments can be in any order, but
the argument must follow the flag directly. For example, the following is also a valid command.
java -jar Apportionment.jar census2020.xlsx --algorithm jefferson --reps 1000
List of optional arguments: This lists all optional arguments.
● --reps [integer] - must be followed by a positive (non-zero, non-negative) integer.
Throw a meaningful exception if the input is invalid.
○ Defaults to --reps 435
● --format formatName - set the format name. Format choices:
○ --format alpha - print States (AlphabeticalApportionmentFormat)
○ This is the default value
○ --format benefit - prints States by benefit (RelativeBenefitFormat)
○ --format population - prints States by population (PopulationFormat)
○ Anything else is invalid, a meaningful exception should be thrown
● --algorithm strategyName - set the Apportionment method
○ --algorithm adams - use Adams Apportionment algorithm
○ --algorithm jefferson - use Jefferson Apportionment algorithm
○ --algorithm huntington - use Huntington-Hill Apportionment algorithm
○ This is the default value
Short Flag arguments:
Short flags work largely the same way as long flags. For instance, long flag arguments:
java -jar Apportionment.jar census2020.xlsx --reps 1000 --format benefit
--algorithm jefferson
Could also be written as a short flag form:
java -jar Apportionment.jar census2020.xlsx -r 1000 -f benefit -a jefferson
That is:
● -r is short for --reps
● -f is short for --format
● -a is short for --algorithm
However, unlike long flags, short flags can be combined. For example,
java -jar Apportionment.jar census2020.xlsx -rfa 1000 benefit jefferson
Specifically, -rfa means that:
● The next argument (1000) is -r (--reps)
8
CS 3140 - SDE Spring 2024
● The argument after that (benefit) is -f (--format)
● And the argument after that (jefferson) is -a (--algorithm)
Just like long flags, these can go in any order, and only include some arguments:
java -jar Apportionment.jar census2020.xlsx -af jefferson alpha
The above means:
● Use the Jefferson Apportionment algorithm
● Print states alphabetically
● Use 435 reps (default)
A few words of encouragement: If you have followed the instructions and implemented the
code to the end of this part, congratulations! You have written a pretty complex piece of software
with several long and short flag arguments! This is no small feat, as it demonstrates a mastery
of functional and clean code design. I hope you take pride in what you have accomplished.
Keep up the awesome work, and continue to push yourselves to new heights in your future
projects!
3. Submission and Grading
Ensure all work has been merged to the main branch, then submit, as usual, answer the
questions on the Questions.md.
The coding portion of this assignment will be graded solely based on correct functionality, like
Homework 1 and 2. While we encourage practicing good style and testing (as they will likely
make developing the homework more efficient), we will not be grading anything other than the
functionality for the coding portion. Make sure your class and method names match this
document - we will use automated testing during this assignment to ensure efficient grading.
You should try to make your code DRY, but you will not be graded.
Functionality: We are only grading how correctly your code functions:
● Team Declaration: 5%
● Code Submission
○ Part A - 20%
○ Part B - 20%
○ Part C - 15%
○ Part D - 25%
● Submission and Reflection Questions - 20% (including 5% for Team Declaration)
○ 10% for answering the questions in Questions.md
○ 5% for filling out the Github information and setting up repo correctly
9
CS 3140 - SDE Spring 2024
4. Frequently Asked Questions
Q: Can I add code my team implemented in HW1-C?
A: Yes, you may add code that your team developed from HW1-C
Q: How do we access methods from an Apportionment if they are private?
A: You are welcome to **increase** the visibility level of any method (i.e., any private method
can be made protected or public, and any protected method can be made public).
Q: If a flag is syntactically incorrect/invalid ("-reps", "reps", or "--numreps") or if some
flag is missing, should we throw an error or should we allow the program to continue
running with the default configurations?
A: Any invalid flags or arguments not attached to flags should throw an error.
Q: Can I change the Method Signatures of Factory Classes?
A: No, you must adhere to the specification as given, only because it will make the grading job
more accessible if they can just use the automated test which relies upon a specific interface.
Q: May we use an external library to implement Arguments?
A: Yes. This is acceptable and in my view an intelligent thing to do. If you find the wheel that
works perfectly well, you don't need to invent a new one. Just make sure you do a proper import
through Gradle Dependencies.
Appendix A - Jefferson Apportionment Method
In this assignment, we will extend the pool of Apportionment methods with a new algorithm:
Jefferson Apportionment Method. As in Homework 1 with Hamilton and Huntington-Hill, we will
quickly illustrate the Jefferson Apportionment Method starting with these five states. For the first
few steps, this will look a lot like Hamilton. This Youtube video on Apportionment describes the
Jefferson Apportionment algorithm starting at the 13-minute mark.
In this example, we will be using 25 representatives once again.
Name Population
Delaware 989948
Maryland 6177224
Pennsylvania 13002700
Virginia 8631393
10
CS 3140 - SDE Spring 2024
West Virginia 1793716
Like with the Hamilton Method from HW1-A/B, we are going to get the total population
(30,594,981) and divide by our number of representatives (25) to get our divisor (roughly
1,223,799.24). And just like in Hamilton, we will divide every state by the divisor (Raw, in the
table below) and then Round all states DOWN (RoundedDown in the table below.)
Name Population Raw Rounded Down
Delaware 989948 0.808914 0
Maryland 6177224 5.04758 5
Pennsylvania 13002700 10.62486 10
Virginia 8631393 7.052948 7
West Virginia 1793716 1.465695 1
Now, if we were to allocate reps equal to the number rounded down, we would be allocating 23
representatives, which is two fewer than we should.
This is the part where we break away from Hamilton. In the Jefferson method, rather than
dealing with remainders, we instead change the divisor. That is, we start decreasing the value
of our divisor until we have allocated all 25 representatives.
So, for instance, if we change our divisor to 1.1 million (1,100,000), then our table becomes:
Name Population Raw Rounded Down
Delaware 989948 0.899953 0
Maryland 6177224 5.615658 5
Pennsylvania 13002700 11.82064 11
Virginia 8631393 7.846721 7
West Virginia 1793716 1.630651 1
We've allocated 24 representatives, but we are still short of 25. If we drop our divisor to 1
million (1,000,000), however, then we end up allocating too many representatives:
11
CS 3140 - SDE Spring 2024
Name Population Raw Rounded Down
Delaware 989948 0.989948 0
Maryland 6177224 6.177224 6
Pennsylvania 13002700 13.0027 13
Virginia 8631393 8.631393 8
West Virginia 1793716 1.793716 1
So that means 1 million is too small. I then tried 1.08 million (1,080,000) and got 25:
Name Population Raw Rounded Down
Delaware 989948 0.916619 0
Maryland 6177224 5.719652 5
Pennsylvania 13002700 12.03954 12
Virginia 8631393 7.992031 7
West Virginia 1793716 1.660848 1
Since we now have 25 representatives allocated, we stop here and accept this number. Yes,
this leaves Delaware without representation, but for the sake of simplicity, you should not try to
enforce "every state gets at least one representative" here. This would be the correct
Apportionment for this input.
Fun fact: In 1992, if Congress had been apportioned by the Jefferson method, Al Gore would
have won the 2000 Presidential Election even if no votes were changed. This is because
Jefferson heavily favors larger states.
12