Great question and great answers, thank you.
Regarding (3),
what if want to process various customer order implementations (say, sort
them) in a polymorphic way depending just on their total-price?
Assuming I do not control the implementations..
Is it ok in this case to define *HasTotalPrice* pr
Antonio, I think he means that the onus is on the consumer of an API to
make a sensible decision about what they depend on. Consumers could choose
to depend on implementation details rather than provided abstractions. When
they do so, they need to accept the burden of adapting should those
impl
can any one explain to me please
"If people don't have the sensibilities to desire to program to
abstractions and to be wary of marrying implementation details, then
they are never going to be good programmers. "
четверг, 3 мая 2012 г., 3:35:04 UTC+3 пользователь Takahiro Hozumi написал:
>
>
Thanks all, folks. Rich's video helped tremendously. The a-ha moment was
the realization that the biggest reason to abstract data access in Java is
the non-uniform built-in access to data: accessing fields in objects is
different from hashmaps which is different from instance access which is
> I've read in some recent posts that Clorujians prefer data to APIs. I'm not
> sure I understand what this means, in practice. When I'm in the early
> stages of developing an application, the data structures undergo a great
> deal of change. One of the ways, I isolate parts of the code from the
> I've read in some recent posts that Clorujians prefer data to APIs. I'm not
> sure I understand what this means, in practice. When I'm in the early stages
> of developing an application, the data structures undergo a great deal of
> change. One of the ways, I isolate parts of the code from
A nice example of this in clojure is ring: https://github.com/mmcgrana/ring
The essence of it is what keys are present in the request/response
maps, laid out here
https://github.com/mmcgrana/ring/blob/master/SPEC
On Wed, May 2, 2012 at 3:27 PM, Stuart Sierra
wrote:
> The data *is* the API. Des
Can you give an example of how your data structure changes?
Getters and setters are only a problem when they come baked into your
datastructure, as the only way to access the contents.
If you require more custom getting/setting logic than the built-in
datastructures provide, you can always just w
On Wed, May 2, 2012 at 12:27 PM, Stuart Sierra
wrote:
> The data *is* the API. Design the data structures you're going to accept &
> return at all the public entry-points of your library or application. That's
> your API design.
>
> It's kind of like web APIs returning JSON or XML: the structure o
The data *is* the API. Design the data structures you're going to accept &
return at all the public entry-points of your library or application.
That's your API design.
It's kind of like web APIs returning JSON or XML: the structure of the data
you get back is part of the contract.
-S
--
You
On Wed, May 2, 2012 at 7:03 AM, Mark wrote:
> I've read in some recent posts that Clorujians prefer data to APIs. I'm not
> sure I understand what this means, in practice. When I'm in the early
> stages of developing an application, the data structures undergo a great
> deal of change. One of t
> I've read in some recent posts that Clorujians prefer data to APIs. I'm not
> sure I understand what this means, in practice. When I'm in the early
> stages of developing an application, the data structures undergo a great
> deal of change. One of the ways, I isolate parts of the code from the
I've read in some recent posts that Clorujians prefer data to APIs. I'm
not sure I understand what this means, in practice. When I'm in the early
stages of developing an application, the data structures undergo a great
deal of change. One of the ways, I isolate parts of the code from these
s
13 matches
Mail list logo
