> On Apr 24, 8:56 am, James Richardson <ja...@time4tea.net> wrote:
>> You might find that using a static helper method increases readability
>> there.

>> Rather than new Age(10) etc, see what you think about Age.of(10)
>> Name.of("bob")

>> James
>> On Apr 24, 2012 3:12 PM, "Chuck Krutsinger" <chuck.krutsin...@gmail.com>
>> wrote:

>> > I can see an advantage to the latter case when programming in Java,

>> > public class Person {
>> >    private Name name;
>> >    private Age age;
>> >    private Salary salary;
>> >    // ...

>> > because when you make calls to the Person constructor or one of its
>> > methods, there may be an improved readability (with the side affect of
>> > being verbose) in saying:

>> >  Person chuck = new Person(new Name("Chuck Krutsinger"), new Age(51),
>> > new Salary(100000));

>> > vs.

>> >  Person chuck = new Person("Chuck Krutsinger", 51, 20000);

>> > Because in the latter case you have multiple integer args that are not
>> > distinguished and are sequence dependent.  Plus, as the system grows
>> > you may start to add behaviors to Age, Salary, and Name.

>> > On Apr 23, 11:29 pm, Micha³ Piotrkowski
>> > <mpi.michal.piotrkow...@gmail.com> wrote:
>> > > It depends. It depends if you can attach behavior to a Children class
>> > that
>> > > is specific to a collection of children but is not for a collection of
>> > > people. Example of such behavior in this case could be
>> > > children.favoriteToys().
>> > > Otherwise, you end up with classes like Parents, Neighbors, Coworkers...
>> > > All of them could be generalized to "a group of people".
>> > > I like to use variable name vs variable type analogy:
>> > > String name or Name name?
>> > > Lets look at an example:

>> > > public class Person {
>> > >   private String name;
>> > >   private Integer age;
>> > >   private Integer salary;
>> > >   // ...

>> > > Or

>> > > ublic class Person {
>> > >   private Name name;
>> > >   private Age age;
>> > >   private Salary salary;
>> > >   // ...

>> > > Which one is better???

>> > > I can't imagine any reasonable behavior that could be attached to Name.
>> > It
>> > > is just a sequence of characters. However Age has some validation rules:
>> > > age cannot be negative. You could also provide a creational method
>> > > Age.fromBirthDate(Date birthDate).

>> > > When to use Integer age and when Age age?
>> > > Eric Evans in "Domain Driven Design" introduces concepts of a "core
>> > domain"
>> > > and a "supporting domain". For example, if I am creating an application
>> > > that calculates and visualizes currencies exchange rates I can let myself
>> > > to store address data as String addressLine1, String addressLine2, but I
>> > > should create a separate class for Currency, Money, ExchangeRate, ...
>> > >  23-04-2012 14:04, "Piotr Przybylak" <piotr.przyby...@gmail.com>
>> > napisa³(a):

>> > > > Wouldn't "Children" be more appropriate for a class in this case then
>> > > > "People" ?

>> > > > --
>> > > > Best regards
>> > > > Piotr Przybylak

>> > > > W dniu 22 kwietnia 2012 16:24 u¿ytkownik Micha³ Piotrkowski
>> > > > <mpi.michal.piotrkow...@gmail.com> napisa³:
>> > > > > Jimmy Nilsson in his "Applying Domain Driven Design and Patterns"
>> > > > suggests
>> > > > > another way of encapsulating collections (original code was in C#,
>> > but I
>> > > > > translated it to Java):

>> > > > > public class Person {

>> > > > > private List<Person> children = new ArrayList<Person>();

>> > > > > // ...

>> > > > > public Collection<Person> getChildren (){
>> > > > >   return Collections.unmodifableList (children);
>> > > > > }

>> > > > > public void addChild(Person child){
>> > > > >   children.add(child);
>> > > > > }

>> > > > > // ...
>> > > > > }

>> > > > > I like this because it its very simple. It is default solution for
>> > me.

>> > > > > When (after a while) I spot a lot of collection handling code in
>> > Person.
>> > > > I
>> > > > > refactor by applying "extract class" People.

>> > > > > 22-04-2012 14:38, "Kevin Rutherford" <ke...@rutherford-software.com>
>> > > > > napisa³(a):

>> > > > >> Hi Chuck,

>> > > > >> On Sat, Apr 21, 2012 at 11:06 PM, Chuck Krutsinger
>> > > > >> <chuck.krutsin...@gmail.com> wrote:

>> > > > >> > "Encapsulate Collections - We've developed a habit of packaging up
>> > > > >> > common types, such as Collections, in our own classes, even though
>> > > > >> > Java generics avoid the need to cast objects..."

>> > > > >> I use a couple of rules to help steer me in the right direction:

>> > > > >> 1. Never pass a collection as a method parameter or return value
>> > > > >> 2. Any class that has a collection as an instance variable must have
>> > > > >> no other instance variables.

>> > > > >> These aren't hard guidelines, but they do push me towards wrapping
>> > > > >> most collections in a class. That class will only have methods that
>> > > > >> correspond to the ways it is actually used, and will generally not
>> > > > >> expose the collection at all.
>> > > > >> Cheers,
>> > > > >>   Kevin
>> > > > >> --
>> > > > >>http://www.kevinrutherford.co.uk
>> > > > >>http://myonepage.com/kevinrutherford
>> > > > >> +44 (0) 797 356 3521