Welcome to the Treehouse Community
Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.
Looking to learn something new?
Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.
Start your free trial
Gabriel Simonetti
1,453 PointsWhy create new methods instead of declaring constructors?
Since the Model layer is responsible for retrieving and displaying the data, wouldn't it be better if, for each object of this class, we used a class constructor that receives a JSONObject as parameter and populates the object, instead of doing that in a method on the Activity class?
1 Answer
Andrew Winkler
37,739 PointsI'm jacking a Stackoverflow thread for this one:
The important difference between constructors and methods is that constructors create and initialize objects that don't exist yet, while methods perform operations on objects that already exist.
Constructors can't be called directly; they are called implicitly when the new keyword creates an object. Methods can be called directly on an object that has already been created with new.
The definitions of constructors and methods look similar in code. They can take parameters, they can have modifiers (e.g. public), and they have method bodies in braces.
Constructors must be named with the same name as the class name. They can't return anything, even void (the object itself is the implicit return).
Methods must be declared to return something, although it can be void.
^^^^^^ given all of this criteria, methods are much more flexible, descriptive, and reusable in this context. Using methods rather than constructors offers much more potential for expansion in the future.
Gavin Ralston
28,770 PointsGavin Ralston
28,770 PointsThis is where abstractions like "Model, View, Controller" really melt down in my brain.
On one hand, the Activity handles the View, but really it's a Controller. And the Forecast is really a Model, so would it be best if it did a Model job and simply stuck to representing data structures, not manipulating itself, right?
Then again, if you're modeling the data from Forecast.io api call exactly, like we're doing in this case, you'd think that, yes, in fact, it should accept a json representation of itself and know how to build itself accordingly.
In fact, that means that your controller no longer has to concern itself with anything but your Forecast model API. It just makes a call to the weather api, passes the data along to a model it can work with, and count on certain behaviors from, and be better off for the less breakage.
Plus I guess this would mean that the Forecast model could be enhanced in the future to accept other forecast json/xml objects with new constructors or a source parameter and still behave exactly the way we would expect it to in the Stormy activity itself.
I sure do like the idea of the MainActivity code including a single line like:
mForecast = new Forecast(jsonData);or...
mForecast = new Forecast(jsonData, "bobsWeatherShack");