Instance variable or inheritance?

[Sangel Kapoor]

I need Person Class in my project and I do have 2 options.

First Option:-

1. Make Person class Abstract
2. Make Female class extends Person
3. Make Male class extends Person.


Second Option :

1. Make Person class and use SEX (enum) as Instance Variable.


Which option is better from design perspective or are they equivalent ?? Please do share your expert views.

[Campbell Ritchie]

Which would you think is better?
Why are you calling SEX (it should be Sex) a variable?

[Sangel Kapoor]

Yes its Sex and not SEX, typo !

Inheritance one makes me feel better but if someone asks me why . I don't think so I will be able to impress . :-D

[Bear Bibeault]

Will the classes have different behaviors? If not, then there's no sense having more than a gender member.

If, however, Female was to have a method givesBirth(), while Male has growsBeard(), then subclasses make sense.

[Paul Clapham]

The question for me is, what do you plan to do with those classes? A Person class with only a Sex attribute isn't very useful, for example.

And the other question is, is the Sex attribute mutable? If so, then your question is answered. If not, then why not?

[Sangel Kapoor]

I will be using Person Class in Family Tree.

Sex is Enum so immutable.

So, essentially Person Class will hold Age, Sex, Name, FamilyTree.

[Junilu Lacar]

Sangel Kapoor wrote:I will be using Person Class in Family Tree.

Sex is Enum so immutable.

So, essentially Person Class will hold Age, Sex, Name, FamilyTree.

I don't think that's what Paul was getting at with immutable vs mutable but I'll defer to him to comment on what you said.

Why age instead of birthdate? Age will vary over time. Birthdate pretty much is going to be one value for all time. If it's for a family tree, birthdate seems to make more sense to me.

[Paul Clapham]

Junilu Lacar wrote:I don't think that's what Paul was getting at with immutable vs mutable but I'll defer to him to comment on what you said.

No, my question was whether the design of the class required the sex attribute to be immutable. Simply saying it's immutable because it's an enum ignores the question about the design -- i.e. about why it's immutable -- not to mention that it's possible to change a variable even if it's a variable of an enum class, so that's not an answer at all.

Here's why it should be mutable: Sometimes people put in wrong information and need to change it later. If you don't allow them to change it, then they have to delete the object with the wrong information and then add a new version of the object. Often this can be very inconvenient.

[Paul Clapham]

And now that we know it's a family tree, are you considering separate MarriedPerson and SinglePerson classes? Why or why not?

[Junilu Lacar]

Further to Paul's question about Married vs Single, consider that marital status is temporal, just as age, address, etc. That means, it can change over time. A person may be single for a while, then get married, get divorced, get widowed, or the marriage gets annulled, etc. Even sex nowadays is subject to change over time, if you're going to consider social trends as with gender identity and gender change operations and all that as something you might want your Family Tree to be able to reflect.

[Sangel Kapoor]

Firs of all thanks for prolific inputs. So here goes the design

We are required to make a Family Tree for a Person and then Print family Tree for that person. <This is the Spec> For instance we should be able to add Relationship(s) for a Person and then retrieve it later and print it. Relationships could be SPOUSE, FATHER, MOTHER, SIBLING, SON, DAUGHTER etc

Here is the design for my classes.

public class Person {

    private PersonalInformation personalInformation;
    private FamilyTree familyTree;

    public Person(PersonalInformation personalInformation,FamilyTree familyTree) {
        this.personalInformation = personalInformation;
        this.familyTree = familyTree;
    }

public class PersonalInformation {

    private Name name;
    private Sex sex;

    private PersonalInformation(Name name, Sex sex) {
        this.name = name;
        this.age = age;
        this.sex = sex;
    }

public interface FamilyTree {
    boolean addRelationship(Person first,Relationship relationship, Person second);
    List<Person> getRelationship(Relationship relationship);
}

public interface Relationship {
    boolean isLegitimate(Person first,Person second);
    Relationship getReverseRelationship(Person first, Person second) throws IllegalRelationshipException;
}

So , Personl class is very much Mutable as it should be and suggested. I don't think so, given specs in hand, "Married" and "Single" would help me any way.
Also, Name is a tiny type.

Some more queries

1. Do you think , we should encapsulate Name and Sex in PersonalInformation or we should have them directly in Person class. So we have 2 groups here with different opinions. What is the right way or when should we decide to encapsulate something , is it based on number of Instance Variables going high in a Class, is there any threshold value , is it wrong for 2 Instance Variables ? Why I decided to make becuase I thought these piece of information goes together so encapsulate rather than thinking about number .


2. One kind of thoughts for Person is to hold FamilyTree directly as above. Another design thoughts is to make FamilyTree controller , which keeps track of Person in Application and their family trees. This way Person won't hold Family Tree. Whenever Person family tree is required, Person will delegate it to FamilyTree controller. Also , FamilyTreeController will add relationships, and add reverse relationships to family tree. For instance say, John's SON of Marry , then we add SON relationship in JOhn as well as Father/Mother (Depending on Sex) Relationship in Marry.

[Junilu Lacar]

This design may seem fine in your head when you thought about it but I doubt it will stand up to various ways one would typically expect to deal with People and FamilyTree objects. Have you written any tests to try out this design? The tests should allow you to see how certain scenarios of usage for these objects would play out.

[Junilu Lacar]

Whatever it was that made you think that there are "two groups of opposing thoughts" here, that's a misperception on your part. Various options have been presented to you to make you think your design through and come up with a good justification for your decision. The giving of an option is not necessarily an endorsement of it. In fact, we expect that you would reject some of those options.

[Junilu Lacar]

When it comes to design patterns, Controller has a very specific meaning. Don't use it in this context because your use of Controller doesn't fit the usual semantics of a Controller and only makes what you're saying confusing and sound wrong.

I suggest you start drawing up some tests so you can see how you might typically use Person and FamilyTree objects. That will help you see flaws and gaps in your design.

Ask yourself questions like the following, then try to write some sample code to answer those questions. That sample code is what should be in your tests.

Sample questions:
1. How do I create a FamilyTree?
2. How do I add a Person to a FamilyTree?
3. How do I represent a Marriage between two People from different FamilyTrees?
4. Do I add each Person in a marriage to their spouse's FamilyTree?
5. Does a FamilyTree support polygamous marriages? Divorces?
6. What about remarrying after the death of a spouse or a dissolution of a previous marriage, how is that represented in a Family Tree?
7. How do I represent sibling relationships in the FamilyTree?
8. How do I represent parent-child relationships in the FamilyTree?
9. How about step-parent/step-child relationships?
10. What about adoptions?
and so on...

[Winston Gutkowski]

Sangel Kapoor wrote:Relationships could be SPOUSE, FATHER, MOTHER, SIBLING, SON, DAUGHTER etc

Could they?

Father/Mother will be dependent on Sex, won't it? Same with Son/Daughter.

Also: those two relationships are subjective - ie, they depend on which person is the subject of the relationship (sometimes also called 'directional').

If Frank is the father of Helen, then she is his daughter. At the very least, I'd use gender-neutral words like 'parent' and 'child' to avoid redundancy. Unfortunately, there's no "two-way" word (like 'sibling' and 'spouse') to describe that relationship - at least I can't think of one.

Naming is very important, so make sure you think about them carefully before you go too far.

HIH

Winston

[Junilu Lacar]

Also, in certain cultures like with the Chinese, sibling order is important. The Chinese have very specific names for relationships that include the order of birth. For example, where westerners will simply say "my cousin", the Chinese will say something like "my father's second brother's third male child". Will that be something that could be determined with your FamilyTree?

[Winston Gutkowski]

Sangel Kapoor wrote:Another design thoughts is to make FamilyTree controller , which keeps track of Person in Application and their family trees.

And that definitely makes more sense to me.

People aren't family trees, are they? They may HAVE a family tree, but the whole concept of a family tree is an artificial one - indeed it wouldn't exist at all unless you'd been told to write one - so I'd definitely keep the two things separate.

Another thing that might be worth doing is thinking about a relationship as something that connects two people, eg:

public class Relationship {
   private final Person source;
   private final Person target;
   private final Type type;

   public static final enum Type {
      PARENT, CHILD, SIBLING, SPOUSE;
   }

   ...
}

And there may well be rules that govern how they're created. For example,
'Spouse' (at least in most Western countries) is a 1:1 relationship, so if Frank is Susan's spouse, he can't also be Nicole's.
It's also (hopefully) exclusive: Frank also can't be Susan's father, sibling or child.

Now how you go about enforcing those rules is up to you, but I'd regard any "family tree" that didn't as highly dubious.

BTW, the above class isn't meant to be "real"; just something to think about.

HIH

Winston

[Dave Tolls]

Winston Gutkowski wrote:'Spouse' (at least in most Western countries) is a 1:1 relationship, so if Frank is Susan's spouse, he can't also be Nicole's.

Divorce or death and subsequent remarriage should be taken into account. So, in a family tree sense, someone can have multiple spouses. You might end up writing a check to ensure dates don't overlap, but then you'd miss out on those juicy family secrets from way back when...you know, when Great Great Uncle Bob went off to sea, leaving Mrs Bob behind, and everyone thought he'd died...

[Sangel Kapoor]

Junilu Lacar wrote:Whatever it was that made you think that there are "two groups of opposing thoughts" here, that's a misperception on your part. Various options have been presented to you to make you think your design through and come up with a good justification for your decision. The giving of an option is not necessarily an endorsement of it. In fact, we expect that you would reject some of those options.

Apologies for this, seems like there is some misinterpretation from your side, when I mean "two groups of opposing thoughts" , I mean here in my team :-)

[Junilu Lacar]

Dave Tolls wrote:you know, when Great Great Uncle Bob went off to sea, leaving Mrs Bob behind, and everyone thought he'd died...

Surely you're not talking about The Uncle Bob

[Junilu Lacar]

Sangel Kapoor wrote:Apologies for this, seems like there is some misinterpretation from your side, when I mean "two groups of opposing thoughts" , I mean here in my team :-)

Fair enough. I think the best way that both groups of thought on your team can see the way to go is to come up with the test code to answer some of these questions. Like I've said, for the second time now, I don't think your current design will hold up well to the answers to the questions and scenarios that have been put forward so far. Write some tests and put your design through its paces. Unlike theoretical physics, thought exercises can only take you so far when you're doing software development and design. You have to drive the rest of the way using tests. Only with actual working code will you be able to find flaws and gaps in the design.

[Sangel Kapoor]

I think I have addressed all the issues and yes I have done TDD with my design.

My FamilyTree Implementation encapsulates "HashMap" with keys as Relationships.

My Concrete Relationships are classes that implements two methods in the Relationship Interface and dictates whether it is Valid or not and what is the reverseRelationship for that particular relationship. I am not able to think of any case that my design wont cater.

public final class GrandSon implements Relationship {

    private static final String ILLEGAL_RELATIONSHIP_EXCEPTION_MESSAGE = "Grandson should be Male";
    private static final String REPRESENTATION_FOR_CLASS = "GRANDSON";

    private GrandSon(){}

    private static class SingletonInstance{
        private static final GrandSon INSTANCE = new GrandSon();
    }

    public static final GrandSon getInstance(){
        return SingletonInstance.INSTANCE;
    }



    @Override
    public boolean isLegitimate(Person first, Person second) {
        if(second.getPersonalInformation().getSex() != Sex.MALE)
            return false;
        return true;
    }

    @Override
    public Relationship getReverseRelationship(Person first, Person second) throws IllegalRelationshipException {
        if(!isLegitimate(first,second)) throw illegalRelationshipException(ILLEGAL_RELATIONSHIP_EXCEPTION_MESSAGE);
        return Relationships.GRANDPARENT;
    }

    @Override
    public String toString() {
        return REPRESENTATION_FOR_CLASS;
    }
}

What should I call a Class "Family Controller" (Which I am saying ). It does two things

1. Add Relationship to the Person Family Tree.
2. Adds Reverse Relationship to the Second Person Family Tree.

For Instance, if you say addRelationship(X,Y,Mother) meaning Y is Mothe of X to familyTree, it does two things

1. Adds Mother relationship to X family Tree and , Add Y to it. (HashMap ,with MOTHER as Key)
2. Finds Reverse Relationship for Mother from Mother class. It is SON if X is male and Daughter if X is female.
3. Adds this relationship to Y's family tree.

What should I call to this class ? FamilyManager/ FamilyRegistrar ???

Also I am planning to remove "Family Tree" from Person and Injecting FamilyController(Wrong name!) instead. FamilyController would be Singleton and it holds all the Person and their familyTree's

[Junilu Lacar]

None of the code you've shown so far has me convinced that you're not painting yourself into a corner. For example, the GrandSon relationship is one-way only between two people. And as I said before, relationships can be defined in great detail and specificity in certain cultures more than others. My first thought, if I'm going to step into the world of speculative design, is to have some kind of a Strategy to calculate relationships within a FamilyTree. There are a few ways that relationships can be established. Primarily, it's biological. In the majority of cases, a Person can be born to two other Persons. I say "the majority" because there is at least one case where there was supposedly only one Person involved in the birth, but let's ignore that one for now Also, let's ignore cloning and spontaneous generation. For some donor-based fertilization and surrogate births, let's just say we specify "UNKNOWN" for one or both biological parents and defer to the legal relationship for the purposes of the FamilyTree.

All other relationships are formed through social/legal bonds: marriage and adoption primarily. That's where I would start.

I'd be interested in seeing the tests you have come up with, since you said you did TDD. The quality of your tests determine the quality of your design and production code and as far as what I've seen, I still harbor quite a few doubts about your design choices.

[Winston Gutkowski]

Dave Tolls wrote:Divorce or death and subsequent remarriage should be taken into account. So, in a family tree sense, someone can have multiple spouses. You might end up writing a check to ensure dates don't overlap, but then you'd miss out on those juicy family secrets from way back when...you know, when Great Great Uncle Bob went off to sea, leaving Mrs Bob behind, and everyone thought he'd died...

You mean like "doing a Lucan"...or indeed a "Stonehouse"?

However, you're absolutely right.

Winston

[Junilu Lacar]

I didn't complete my thoughts about the GrandSon relationship object design. It seems limited in usefulness to me to define this as a class by itself. Having this as a separate class implies that you'll have one for GrandDaughter, GrandMother, GrandFather, etc. What are you going to do about multi-generational gaps then? Will you define a GreatGreatGreatGreatGreatGrandSon class and all the other intermediate ones as well? Then have parallels for Daughters, Mothers, and Fathers? That seems like a design that will quickly become unwieldy and untenable to me.

[Bear Bibeault]

In my opinion, the relationships are inherent in the tree structure and shouldn't be codified into attributes or classes.

[Junilu Lacar]

Sangel Kapoor wrote:
What should I call to this class ? FamilyManager/ FamilyRegistrar ???

Also I am planning to remove "Family Tree" from Person and Injecting FamilyController(Wrong name!) instead. FamilyController would be Singleton and it holds all the Person and their familyTree's

What makes you think you need another object? Why not try to work with just FamilyTree and Person for now? I would not try to introduce a third class until my tests and refactoring code smells told me that I needed another class to handle some responsibility that didn't belong in either FamilyTree or Person.

Again, let's see some of these tests that you came up with while you were doing TDD.

[Junilu Lacar]

Bear Bibeault wrote:In my opinion, the relationships are inherent in the tree structure and shouldn't be codified into attributes or classes.

Exactly. Relationships between nodes (Person objects) can be calculated based on their relative positions within the tree structure. That's why a Strategy comes to mind. A "Simple" strategy can calculate relationships like Father, Mother, Brother, Sister, Sibling, Cousin, Aunt, Uncle, etc. Another Strategy might be able to calculate something like "Father's second Sister's fifth Son's first Daughter". This is why I'd start with the biologically-formed relationships and then add to that the social/legal relationships formed by marriage and adoption and figure out how to represent that in a tree structure.

[Junilu Lacar]

Furthermore, you can view family trees as multi-dimensional structures. In matriarchal societies, the lineage through mothers are held in more importance. Other societies hold lineages though the fathers as more important. Even when you only have one Person at the "root" of a tree, the relationships under that Patriarch/Matriarch can criss-cross on itself. Take the British royalty (of old) for example, where cousins marry each other. Then you have the stereotyped in-breeding in certain parts of the U.S. Even I have one uncle (my father's older brother) who was married to his first cousin. In fact, since we both come from the same hometown, my wife and I can trace back through our respective family lineages and find many common relations although we have traced back far enough to know that none of those common relations can be arrived at through bloodlines but rather through marriage, thankfully.

[Sangel Kapoor]

Junilu Lacar wrote:

Bear Bibeault wrote:In my opinion, the relationships are inherent in the tree structure and shouldn't be codified into attributes or classes.

Exactly. Relationships between nodes (Person objects) can be calculated based on their relative positions within the tree structure. That's why a Strategy comes to mind. A "Simple" strategy can calculate relationships like Father, Mother, Brother, Sister, Sibling, Cousin, Aunt, Uncle, etc. Another Strategy might be able to calculate something like "Father's second Sister's fifth Son's first Daughter". This is why I'd start with the biologically-formed relationships and then add to that the social/legal relationships formed by marriage and adoption and figure out how to represent that in a tree structure.

I understand what you mean and I though of the same , but it has other flaws as well. First of all it wont be a Tree Structure (Data Structure), it would be Graph. In tree , how would you differentiate between nodes at the same level ? Are they siblings, or Spouse ?

Although we can make a Single graph for a family . Nodes in a graph are connected by Relationships and those relationships tell us what they are. Similar to node4j

[Sangel Kapoor]

Also there is no requirement for going beyond GrandFather , then why to speculate and make generalized approach.
I feel if specs come , we can make another implementation of FamilyTree interface which can use Graph Data Structure with Relationships.
I took HashMap approach since it was easy to solve the problem with given relationships although it has limitations beyond specs.

[Junilu Lacar]

Sangel Kapoor wrote:First of all it wont be a Tree Structure (Data Structure), it would be Graph.

It's not called a Family Tree for nothing. You might be confusing binary vs non-binary trees. What distinguishes a Tree from a Graph is the absence or presence of a cycle. In fact, a Tree is a specific kind of Graph, namely, it's an acyclic connected Graph.

Although there is apparently a way that you can become your own Grandfather.

[Paul Clapham]

Junilu Lacar wrote:It's not called a Family Tree for nothing. You might be confusing binary vs non-binary trees. What distinguishes a Tree from a Graph is the absence or presence of a cycle.

But nevertheless a Family Tree isn't a Tree as computer scientists know it. Well, the part where you just have parents and children is a tree, but once you start inserting links for marital relationships you don't have a tree any more. As soon as somebody marries their niece (not an impossible scenario at all) you've got a cycle in your graph.

[Junilu Lacar]

Paul Clapham wrote:But nevertheless a Family Tree isn't a Tree as computer scientists know it. Well, the part where you just have parents and children is a tree, but once you start inserting links for marital relationships you don't have a tree any more. As soon as somebody marries their niece (not an impossible scenario at all) you've got a cycle in your graph.

I'm sure there are computer scientists who have not been confined to thinking this way and have managed to elegantly represent those cases in a non-binary Tree structure.

[Paul Clapham]

Junilu Lacar wrote:I'm sure there are computer scientists who have not been confined to thinking this way and have managed to elegantly represent those cases in a non-binary Tree structure.

I can conceive a couple of ways of making a tree out of those graphs, but I certainly wouldn't call them "elegant". Although if I were a computer scientist I might use that word in the abstract of my paper anyway -- one does have to get ahead in the academic world, you know.

[Junilu Lacar]

Here's what I'm thinking: a Node in a FamilyTree isn't strictly just representative of one person. As I said before FamilyTrees are multi-dimensional concepts. It all depends on which dimension you're currently looking at and what other dimensions you choose to ignore during traversal. Here's another case where premature optimization and thinking about normalization can box your thinking into something that's not workable. You can always compartmentalize being a father, a son, a brother, a cousin, etc. and be one thing or the other in different contexts. Thinking about optimization prematurely will lead you away for using this idea to come up with a solution though.

[Junilu Lacar]

Paul Clapham wrote:but I certainly wouldn't call them "elegant".

One of my criteria of elegance is to be able to distill and separate complex and difficult to manage ideas into simpler and more manageable ideas in a clear and straightforward way. Separation of concerns helps get you there. The idea that Marriage is when Two become One is not just a romantic concept.

[Paul Clapham]

Junilu Lacar wrote:You can always compartmentalize being a father, a son, a brother, a cousin, etc. and be one thing or the other in different contexts.

Yeah, that was one of my ideas. But even if you're a son you usually have two parents, so the basic structure ignoring marital relationships still isn't a tree. You could start with only the men, and then you almost have a tree, except that some men don't know who their fathers were and so that tree is broken too. And then you could consider the other half of the people and all of the other relationships as decorations to that tree...

And then there's Great-Uncle Merle who (as it was discovered much later) lived all her life as a man so that she could work as a surgeon, which is the background for my post way back where I asked whether sex should be mutable.

[Paul Clapham]

Junilu Lacar wrote:The idea that Marriage is when Two become One is not just a romantic concept.

Yes indeed, you've got a complex data structure with nodes of various types. Hopefully these types can be implemented to include polygamous and same-sex marriages, and adopted as well as biological children, and so on. The genealogy programs I'm familiar with address that sort of issue by not being too prescriptive about what data people put into them. But I'm just saying that the data structure you end up with isn't a tree.

[Sangel Kapoor]

Junilu Lacar wrote:

Paul Clapham wrote:But nevertheless a Family Tree isn't a Tree as computer scientists know it. Well, the part where you just have parents and children is a tree, but once you start inserting links for marital relationships you don't have a tree any more. As soon as somebody marries their niece (not an impossible scenario at all) you've got a cycle in your graph.

I'm sure there are computer scientists who have not been confined to thinking this way and have managed to elegantly represent those cases in a non-binary Tree structure.

How can you represent this as a Tree is confusing me .
Binary or Not-binary does not matter at all.
In a Tree you have one Parent, and we have notion of Father and Mother both in FamilyTree we are taking about.
You might use forest for this, but still you cannot represent 2 parents.

Also FamilyTree might not be a Tree DataStructure , in the same way as you said word "Controller" does not mean same Controller in Design Patterns (MVC).