If an aggregate root is meant to hold references to entites that are part of the aggregate, and you are not allowed to reference these entities from other aggregate roots, then how does an aggregate root (aggregation) differ from composition which for me does exactly the same?
The word "Aggregate" in DDD is not derived from the general OO concept of Aggregation.
DDD Aggregate roots are indeed closer to composites if there's a parallel to be made, but they're also much more than that.
Related
Referring to an Image I found online. It labels Composition as a subset of Aggregation.
As per my understanding Composition is a form of tight coupling like when we instantiate an object inside another object. While Aggregation is a form of loose coupling kind of like a Dependancy Injection. They both seem different so why would Composition be a subset of Aggregation?
Image:
https://algodaily.com/lessons/association-aggregation-composition-casting
Because it's historical state of the art an not true for UML 2.5. Aggregation as attribute of a Property is explained on p. 110 of UML 2.5:
none | Indicates that the Property has no aggregation semantics.
shared | Indicates that the Property has shared aggregation semantics. Precise semantics of shared aggregation varies by application area and modeler.
composite | Indicates that the Property is aggregated compositely, i.e., the composite object has responsibility for the existence and storage of the composed objects (see the definition of parts in 11.2.3).
So actually both stand side-by-side with shared having no semantics whatsoever. Former UML specs had some definition which made shared some kind of subset. But that is just history. Though, you don't get it out of people's heads.
Composition is a specialized form of aggregation. In composition, if the parent object is destroyed, then the child objects also cease to exist. Composition is actually a strong type of aggregation and is sometimes referred to as a “death” relationship.
I have a doubt. Map.putAll(Map) method is implemented using composite pattern, I want to know , is it correct ?
Because PutAll() method is present in all the decedents of Map irrespective of leaf or non leaf.
My doubt is, in composite class add(Composite) will be present in non leaf classes, but in Map it is present at the interface level, that means even the leaf class have a aggregation link to the component , this contradicts the class diagram of composite design pattern as it shows the aggregation link from composite to component , not from leaf to component. Kindly help
Thanks
Praveen B
From wikipedia:
The composite pattern describes that a group of objects is to be treated in the same way as a single instance of an object. The intent of a composite is to "compose" objects into tree structures to represent part-whole hierarchies. Implementing the composite pattern lets clients treat individual objects and compositions uniformly.
By reading this, you should answer your question: A Map is not a composite
When you write:
map1.putAll(map2)
You are not creating a parent-child relationship between map1 and map2. You just put all the map2 content in map1.
Under a specific requirement such as not using an abstract base class (or super class), I need to implement a simple hierarchy of two entities one of which is supposed to extend the other but have a different #Id of its own.
My googling about this seems to conclude this is impossible or only on condition that I use a mapped super class (which is forbidden in my case due to a certain policy).
I don't want to duplicate the code of the entity with several dozen attributes and then mutate the duplicate by adding / overriding attributes in order to avoid future maintenance problems, but then I'm stuck in JPA restrictions.
Any help / suggestion will be appreciated.
Having different id types for non-abstract derived entities is not compatible with the JPA inheritance strategies.
What I mean is:
Imagine you have succeeded and different classes in the hierarchy use different incompatible types for the id.
how would you define the DB constraints for a single table inheritance in such a case?
and for joined inheritance?
EDIT: JPA does not distinguish between inheritance strategies when it comes to id definition. And you cannot even be sure that you can use TABLE_PER_CLASS with pure JPA. Virtually all providers implement it, but it is specified as optional and thus the least portable inheritance strategy.
The question remains however. How can the DB constraints look in order to make the table usable unambiguously by the persistence provider? E.g. Which columns should comprise the primary key on DB level?
If you cannot make the parent entity neither abstract nor embeddable nor use the same id, you will have to work around that. How you do that is highly dependant on what you want to achieve and what organizational constraints you have.
There are several possibilities - the least invasive would be composition, having A as a field in B, effectively creating a 1-1 relation.
More ugly approaches could be native and constructor queries but I doubt you want to descend that far.
tl;dr No, it is not possible.
I am implementing a schema matching algorithm.I need to perform schema structure matching, i need to represent schema as a is-a has-a relationship graph....one graph per schema...
each node in relation model will represent a table with is-a as table and one has-a relationship for each column(having there own is-a).
My question is how to implement this in best way using java, comparing graphs will be pseudo polynomial in graph size and may through out of memory error if we pull complete schema..i want to find nodes with similar relationships in both graphs ( this will lead to DFS)
is there any already existing java implementation that can do this, i already explored jgraphT, jung...not sure which one will be best to do this..please help
thanks in advance.!!
Whatever graph API you use ought to allow you to do something like this:
boolean equal = graph1.equals(graph2);
where that evaluates true if the nodesets and edgesets are equal. The nodes would need IDs or else content so you could establish actual equality as opposed to graph isomorphism.
Is that what you are asking?
I have two classes Parent and Child.
class Child extends Parent {
private String extraField1;
private String extraField2;
...
}
Child class has 2 extra fields extraField1 and extraField2.
Q1. Should I make two diff. tables in the databse: one for Child and other for Parent?
or
Q1. Should I add two columns in the Parent table (each column for one extra field) and store the Child in the Parent table.
=============================== EDITED =======================================
Yes, Child and Parent are classes in the same hierarchy.
Should there be 2 datatables for a Parent and Child class in Java?
There is no universal answer to this question. There are actually several techniques to map an inheritance hierarchy into a relational database and they all have advantages and disadvantages. Choosing one or the other depends on your context.
Scott Ambler details the various approaches in the section 2. Mapping Inheritance Structures of his famous paper Mapping Objects to Relational Databases: O/R Mapping In Detail that I'm quoting below:
(...) In this
section you’ll see that there are
three primary solutions for mapping
inheritance into a relational
database, and a fourth supplementary
technique that goes beyond inheritance
mapping. These techniques are:
Map the entire class hierarchy to a single table
Map each concrete class to its own table
Map each class to its own table
Map the classes into a generic table structure
For a full comparison (with advantages, disadvantages and a recommendation on when to use), have a look at the section 2.6 Comparing The Strategies.
I can't do a better job than him so there is no point at paraphrasing him, just refer to the original paper.
Patterns of Enterprice Application Architecture covers this as well in its chapters on Single-table inheritance, Class-table inheritance, and Concrete-table inheritance.
The coverage is similar to what Pascal has said. There's no One True Way, but the book does give you a good breakdown of costs and benefits, e.g.
The strengths of Concrete Table Inheritance are:
Each table is self-contained and has no irrelevant fields. As a result
it makes good sense when used by other
applications that aren't using the
objects.
There are no joins to do when reading the data from the concrete
mappers.
Each table is accessed only when that class is accessed, which can
spread the access load.
The weaknesses of Concrete Table Inheritance are:
Primary keys can be difficult to handle.
You can't enforce database relationships to abstract classes.
If the fields on the domain classes are pushed up or down the hierarchy,
you have to alter the table
definitions. You don't have to do as
much alteration as with Class Table
Inheritance (285), but you can't
ignore this as you can with Single
Table Inheritance (278).
If a superclass field changes, you need to change each table that has
this field because the superclass
fields are duplicated across the
tables.
A find on the superclass forces you to check all the tables, which leads
to multiple database accesses (or a
weird join).