Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Submitting Solar System assignment (with Optionals!) #34

Open
wants to merge 15 commits into
base: master
Choose a base branch
from

Conversation

ghostfruitleaf
Copy link

Assignment Submission: Solar System

Congratulations! You're submitting your assignment. Please reflect on the assignment with these questions.

Reflection

Question Answer
When does the initialize method run? What does it do? The initialize method runs every time you create a new object, such as in Hash.new or MyNewObject.new (I think this is instantiation?) Given the parameters (and if there aren't any, it will use default parameters), it will create a new object with fields/instance variables assigned to said parameters. That is to say, initialize "constructs" a new instance (?) of an object.
Why do you imagine we made our instance variables readable but not writable? I see it as an extra layer of protection, especially when the user doesn't necessarily have to keep track of what input is what data type in Ruby (whereas other programming languages may ask you to specify the data type of an input object). In this particular case, we are creating a CLI interface for the use to interact with one particular solar system and its existing objects. Being able to change the star_name and what planets already exist there could potentially introduce confusing bugs or output, such as changing the planet's fields for distance_from_sun throughout the code and getting constantly different results, potentially breaking the code if an object suddenly exists in with one set of fields while that section of the code is running and then suddenly with another set of fields because the user was able to directly change them.
How would your program be different if each planet was stored as a Hash instead of an instance of a class? There would be no extra files to hold our two class objects! Not only that, every time you wanted to create a new Planet object, you would have to manually create a new hash for each planet, which is a lot of typing, and every time you wanted to use a method, you would have to include it in the code itself instead of being able to pull from a collection of public methods for a class object, even if you tried condensing loop through each Planet hash into methods, even enumerable methods.
How would your program be different if your SolarSystem class used a Hash instead of an Array to store the list of planets? In comparison, the main things that would change is how @planets would be iterated through if called. I would imagine the Planet name being the key and the Planet object being the hash, meaning searching for values would require different syntax, as in the case of find_planet_by_name and list_planets (Something like @planets[:"planet name"] would suffice or @planets[:planet_index].name if the key was to number or ID the planets), or even distance_between when other fields need to be pulled. add_planet would change slightly in that it creates a new key-value pair containing the new Planet object, likely.
There is a software design principle called the SRP. The Single Responsibility Principle (SRP) says that each class should be responsible for exactly one thing. Do your classes follow SRP? What responsibilities do they have? My planet class was able to hold information about a Planet object and print a summary of its contents -- in that respect, I would think that the Planet class is very much in line with the SRP in that it really does one thing -- holds info about an object that you can read. Meanwhile, my SolarSystem class can hold info about a solar system, namely its star and planets, print a list of the planets in its solar system, print distances between two planets in its solar system, find whether it contains a planet with a certain inputted name, and add more planets to its array of planets. In that sense, Solar System seems a bit TOO multiple purpose to be SRP compliant for all the different functions (including one mutator) that also sometimes tend to multipurpose themselves ....
How did you organize your require statements? Which files needed requires, and which did not? What is the pattern? Generally, I noticed that files that required the use of other newly created class objects needed "requires" to access how to use and to actually use said object. Planet.rb did not depend on any new class objects being created, and therefore needed no requires statements. SolarSystem.rb, however, did need information on Planet.rb, and included an appropriate requires statement for such. Whereas main.rb was driver code using Class objects defined in SolarSystem and by extension Planet, I needed a requires of both classes to work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant