Adding approach change

[jagdish-15]

pull request

This pull request adds an approach for the "Change" exercise in the Java track, based on discussions with @kahgoh during mentoring.

I was unsure how to generate a uuid for the approach, so I've left it empty for now. I would greatly appreciate guidance on how to generate one.

---

Reviewer Resources:

Track Policies

[jagdish-15]

There's only one issue causing the unsuccessful check i.e. the uuid.

[kahgoh]

Sorry it took me a while to get to this one @jagdish-15. Looking at the content, it looks the structure and formatting differ quite a bit from the existing ones, so the comments are mostly trying to become more consistent with the existing ones.

[kahgoh]

Looking at how we have written the content for some of other approaches (like boolean chain for leap, bit shifting for grains and if statements for Bob, I'd suggest moving the code up here, just under the heading. The description of the approach then begins just under it.

Also, we generally use one sentence per line in our Markdown content. For example:

The **Dynamic Programming (DP)** approach is an efficient way to solve the problem of making change for a given total using a list of available coin denominations.
It minimizes the number of coins needed by breaking down the problem into smaller subproblems and solving them progressively.

[jagdish-15]

Sure, I will move the code to the top and start the explanation afterward. I have also used new lines for every sentence separately, except when it is in a bullet point.

[kahgoh]

Could you please remove this section on alternative approaches? This should just focus on the dynamic programming approach as this will become the dynamic programming page. Alternatively, we could move it to a Which approach to use? section in the introduction.md (similar to the isogram or robot name approaches), but we probably should briefly describe the Greedy Approach if we do (and we could possibly move the point about the efficiency there too).

[jagdish-15]

I have removed both the "Efficiency" and "Alternative Approach" sections entirely. I agree that it makes more sense to include these points in the introduction file under a section like "Which Approach to Use?" However, I believe this should be done only after we add another approach to compare. For now, with just a single approach, these sections are unnecessary.

[kahgoh]

This suggestion is to make the heading consistent with our other existing approaches.

Suggested change

	# Introduction to Change Calculator
	# Introduction

[jagdish-15]

Indeed!!

[kahgoh]

I don't think we need to repeat the exercise here. The other approaches generally have a "General guidance" section that talks about the "key things" to solve the exercise - things that all approaches are likely to have to. For example, in leap, it is as simple as knowing whether a year is divisible by 400, 100 and 4. For grains, its knowing that each square is doubled.

For Change, it could be that not all totals can be reached and somehow figuring out which ones can be reached and how.

Suggested change

	## Problem Overview
	## General guidance

[jagdish-15]

Sure, I've changed it.

[kahgoh]

The other approaches generally have a short listing of all the approaches here, with a link to the specific approach's page just underneath. For example, this would normally be a code listing for your dynamic programming approach followed by a link to the page generated from dynamic-programming/content.md (the URL would be https://exercism.org/tracks/java/exercises/change/approaches/dynamic-programming).

Suggested change

	## Approach Overview
	## Approach: Dynamic programming

[kahgoh]

In regards to the approach file link, there is a preference to use reference linking to make maintenance easier.

I also suggest changing the link text to "Dynamic Programming approach" as students will see a web page based on your content.md (and not the content.md "file").

[jagdish-15]

I agree, and I've made the changes accordingly.

[kahgoh]

Suggested change

	"kagoh"
	"kahgoh"

[jagdish-15]

I am sorry for the oversight.

[jagdish-15]

Thank you so much, @kahgoh, for all these suggestions. Please let me know if there's anything else I should improve, change, or remove.

[kahgoh]

Thanks @jagdish-15, that looks better!

[kahgoh]

I find this sentence redundant because all the approaches will need to do this to successfully solve the exercise.

Suggested change

This approach ensures that we find the most efficient way to make change and handles edge cases where no solution exists.

[jagdish-15]

Yep, I can't deny! I will remove this sentence altogether.

[kahgoh]

I think the core of this document should be focusing on the specifics of how the approach works. From that point of view, I think the Key Points heading/section is confusing as Time Complexity and Space Complexity isn't a core part of the implementation, but I do think we can certainly mention them. Perhaps we could remove the heading.

Suggested change

## Key Points

[jagdish-15]

Sure, I've removed this heading.

[kahgoh]

Suggest moving the points from the edge cases to be with your explanation as they are part of the implementation details. Idalso suggest separating them to follow the order of the code to make it easier to follow (i.e putting the point about checking if grandTotal is negative to the top and one about if no exact total to the bottom of the explanation).

[jagdish-15]

I've moved the first point to the start of the explanation as you suggested and removed the second point since it's already covered at the end, just before the 'Time Complexity' section.

[kahgoh]

I think we could remove this conclusion section. Similar to my earlier comment, I think the first sentence is redundant as all approaches have find the optimal solution to be valid. The second sentence would probably make more sense in a Which approach to use? section if we have more approaches.

[jagdish-15]

I agree! I've removed the conclusion section altogether.

[jagdish-15]

Sorry for all the back-and-forth! I've submitted it now—please take a look and let me know your thoughts.

[kahgoh]

No worries, thanks for preserevering! I think we're almost there!

[kahgoh]

Sorry, have some minor style comments that are similar to the ones on the Queen Attack PR

[kahgoh]

Suggested change

	- The time complexity of this approach is **O(n * m)**, where `n` is the `grandTotal` and `m` is the number of available coin denominations. This is because we iterate over all coin denominations for each amount up to `grandTotal`.
	The time complexity of this approach is **O(n * m)**, where `n` is the `grandTotal` and `m` is the number of available coin denominations. This is because we iterate over all coin denominations for each amount up to `grandTotal`.

[kahgoh]

Suggested change

	- The space complexity is **O(n)** due to the list `coinsUsed`, which stores the most efficient coin combination for each total up to `grandTotal`.
	The space complexity is **O(n)** due to the list `coinsUsed`, which stores the most efficient coin combination for each total up to `grandTotal`.

[kahgoh]

Similar to one the comments on the Queen Attack approach, should this be a heading?

Suggested change

	1. **Initialize Coins Usage Tracker**:
	### Initialize Coins Usage Tracker

[kahgoh]

Suggested change

	2. **Iterative Dynamic Programming**:
	### Iterative Dynamic Programming

[kahgoh]

Suggested change

	3. **Result**:
	### Result

[kahgoh]

If the making Initialize Coins Usage Tracker a heading the indent should be removed.

Suggested change

	- If the `grandTotal` is negative, an exception is thrown immediately.
	- If the `grandTotal` is negative, an exception is thrown immediately.