A comment on my Early Thoughts: Object Oriented Encapsulation post brought up an excellent view about how to decouple a class from it's display mechanism. I'm on board with this idea. It helps keep the objects to their single responsibility.
My first thoughts on how to do this is using an inner class for the Item object; as it'll have access to the internals without exposing them.
Next would be a class in the same package. It weakens the encapsulation, but still a bit of wiggle room.
If I look at this as being able to build a library and exposing a way for the consumer to control the display; either will work... but I'm inclined to go the inner formatter. Otherwise the consumer could just create a same named package (since I'm in java) and extend Employee, breaking all encapsulation. Keeping the variables private and having a formatter access them maintains encapsulation; and does not allow/create dependencies of derived objects on the implementation of Item.
I like this thinking; it'll be what I try. We'll see how it goes; and ... go from there.
time passes
Onto the code!
I've started down the path. I am TDDing... and I hit a block.
beats the 'lack of pair' complaint
One major issue, isn't actually the lack of a pair; it's a lack of requirements driving this. I know I'm doing all of this as practice and investigation; etc. But - What's the requirement?
I've got a small inner class
public class Item{
...
public static class Formatter {
private final Item item;
public Formatter(Item item) {
this.item = item;
}
public String title() {
return null;
}
}
}
And I have a test for producing the title text.
@Test
public void providesTitle(){
final Item.Formatter formatter = new Item.Formatter(nullItem);
String expectedTitle = formatter.title();
assertThat(expectedTitle).isEqualTo("[ Loading Title ]");
}
A formatter that does static output? Even if I did return new String(title) it's still static. There's only the requirement that the data is displayed.
A formatter is excessive at this point.
I've requested my besterest UX friend (SAM!!!) if she'd be up for doing some UX for this app. I expect it'll cost me a few dinners; but if she can get me anything; It'll be awesome. I told her to go as crazy as she wants. She can treat it as an experiment and exercise just I am. Won't be for a few months before I might get anything. I expect I'll be getting something right around when this post goes live.
Anyway - that whole bit is to say that any requirements which might drive the direction of the formatter are a ways out.
Blocker
The first blocker I'm running into is that the example above; return new String(title) is a lie.
The actual code would have to look like
public class Item{
...
public static class Formatter {
...
public String title() {
return titleFormatter.title();
}
}
}
I can easily go implement a Title.Formatter that does the return new String(title). I could do that, literally with my nose, before my daughters practice gets out.
That's not the complication, duh.
The issue is where does the Title.Formatter get instantiated? Where does it get provided?
In the Item? In the Adapter? In the ViewHolder? In the Item.Formatter? This all have different implementations.
There's a lot of direction this could go; and I have no requirements driving it.
Whatever I do will be wrong.
I want to really emphasize this point. I don't have a requirement that's driving the creation of these formatters. I can not, can not, do a correct implementation. It's either not implemented, or implemented for the sake of building a "clever" system.
I think this idea is a fantastic one to explore when formatting needs to happen.
I could even see implementing the formatter like so
public class Item{
...
public static class Formatter {
...
public String title(final SetText item) {
return titleFormatter.title(item);
}
}
}
The strong encapsulation of data is maintained; while allowing the, potential, massaging of the data to happen in a different(ish) class. Better S.R.P.
Do I need a "FormatString" argument to actually allow customization of the data? Most DateTime implementations have similar.
I can think up a few solid implementations depending on the requirement for the formatter. As covered earlier; I'm blocked from implementing because I don't have the requirement.
I think I'm going to put implementing a Formatter on hold.
As the previous post started; I've begun work on interacting with the displayed item. One of the steps will be to move to an activity that displays the story/job along with the comments.
I can probably devise some way to have the display of the text on this screen vary. All Caps (ignoring that the TextView can do this) or restructuring "by AUTHOR" to be "from AUTHOR". These are a bit contrived, but these will are things that will drive a variation in how the data is processed.
No requirement driving; no work done. Really; this is my bad for trying this before I have what I need.
Summary
I think this has been a good process for me to go through. It highlights the idea of not doing work until the "Last Responsible Moment".
It's going to keep it in my head to have the ItemScreen display things a little differently. This different display will be driven by XP practices which given the Ruthless Refactoring could drive this into a Formatter (I like the idea) or some other design that will emerge... ... and I'll go from there.
Having the Formatter pattern in the back of my head will be great; but I'm not going to force it.
A short post; but a good lesson reiterated.
There's been minmal code written; and I'm doing a git reset --hard.
NO CODE FOR YOU!