I have concept PytanieWielokrotnegoWyboru and I need it to contain min 1 and max 4 child OdpowiedzWielokrotna.
Use constraints on your "question" concept to implement a "can be parent" function that rejects any new children after there are already four present.
A checking rule that underlines in red all overflow "answers" would be another option.
Related
How does one go about getting the number of elements in a class's attribute that has 0..* multiplicity?
I can only think of either using an << iterate>> construct to do so but that seems silly or a counter whenever something is added. This seems inelegant if not inefficient.
If you want to refer to the cardinality of an attribute in an activity diagram, you can use the size() function. Example:
If your activity diagram is meant to be read by humans, not by machines, you can also just simply write "number of elements in object.attr".
If you want to access the cardinality in order to create a loop, you might prefer the expansion region. An iterate construct in activity diagrams can be achieved by using an expansion region with mode = iterative. Suppose class Order has attribute orderline of type OrderLine[1..*]. The following diagram shows how to iterate over all orderlines.
See section 16.12 of the UML 2.5.1 specification for more information.
A multiplicity of 0..* means that for a given instance a of A there is a collection of associated instances of B that has has at minimum 0 and at maximum * (i.e. no upper limit) elements:
The same is true for an attribute b:B [0..*] that a class A could have.
The number of elements in the collection is called cardinality. In a constraint, you can refer to the cardinality with
self.b->size()
There is also a convenient way to check if the collection is empty or not:
self.b->isEmpty()
self.b->notEmpty()
I'm working on a module for a larger solution.
In this solution they tried in the past to work with DDD.
However that didn't turn out how it should of been because there was no DDD expert. (and there still isn't one present imo.)
Everything was under a single root aggregate, lazy loading was enabled, and so on.
Now for the new module we want to make it better.
However i'm failing to see how i can use DDD without lazy loading and not drain the entire database.
For example i have an object let's call it "B".
B has a flag let's say "AwesomeFlag"
B has children
If one of B's children is Awesome, then B is awesome as well.
If none of B's children is Awesome, then B isn't awesome.
Now if I would not work with DDD; I'd just get B and execute a linq query that check's if one of B's children is awesome without actually retrieving all of the children.
However if i got a domainobject where i am not allowed to perform queries, how can i do this?
Is DDD forcing me to get all of B's children just to get the calculated flag "IsAwesome" to work?
Or how am i supposed to do this correctly in a DDD environment?
A small hint in which direction i need to focus my research on would be appreciated.
UPDATE
As I was a bit broad in what my question is I'd like to rephrase whilst still using the same terms to be consistent.
B is awesome when one of it's children is awesome.
B itself, does not have a flag "awesome" as this is a calculated field based on the children.
B could have quite a few children, with the children each having allot of properties and data, which you do not want to retrieve just to check if one of the children is Awesome.
B has a method ShouldIBecomeADeveloper
If one of B's children is awesome, making B awesome, it should return a boolean "true"
If none of B's children are awesome, making B not awesome, it should return a boolean "false"
Disclaimer: although this is somehow a valid question, it is very broad, thus it may have many different valid answers.
You need to analyze the business requirements regarding the valid states in which the system is allowed to be. For this you need to answer the question: after a child of B becomes awesome, how fast needs B to become awesome as well?
There are two answers:
Immediately, in a strongly consistent matter. This means that the "awesome mutation" of a child of B and the "awesome mutation" of B are performed in an atomic fashion, they are in the same transaction. In this case you must load B and all its children before mutating one of its children awesomeness. The children of B are nested entities inside the B Aggregate.
It can be delayed, eventually changing its awesomeness to match the business rule, that is, the system can be for some time in a temporary invalid state. In this case, the children of B are also Aggregates. You need a way of mutating B when one of its "past childrens" mutate and for this you can use a Saga/Process manager.
In neither of the two cases you don't use lazy-loading, there is not such thing in case of DDD Aggregates. You can't anyway, if you have pure Aggregates, with no dependencies to Repositories (as you should).
B itself, does not have a flag "awesome" as this is a calculated field based on the children.
Even though "awesome" is a calculated field any operation you perform on the child entity has to go through "B" only, as it is the aggregate root. So you could have a state in "B" called numberOfAwesomeChildren and a child can become awesome/not awesome only when some operation happens on it and since all the operations are directed via "B" only, you can update the numberOfAwesomeChildren whenever a child becomes awesome/not awesome.
So "B" is awesome when numberOfAwesomeChildren is greater than zero.
Even this solution won't solve your lazy loading problem, since to perform an operation on a child entity you will end up loading all the child entity. You may have to have a re-look at your design.
Let's say I have a model Parent that belongsToMany Children. I want to query some parent objects, and sort them so that instances of parent with the most children come first.
Likewise, is it possible to append other conditions to the children that are counted? For example, sorting parents by the number of female children under the age or 3.
What is an efficient way to accomplish this?
You can add child count pre-calculation field to the parent so u will never need to go to children object and this will make quaring very fast, also when you add a new child/delete child keep remember to increase or decrease the value in the parent.
same in the second question add tow field into parent male_child_count & female_child_count, life will be more easier :-)
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I do not have any argument opposing why we need only a single universal class. However why not we have two universal classes, say an Object and an AntiObject Class.
In nature and in science we find the concept of duality - like Energy & Dark Energy; Male & Female; Plus & Minus; Multiply & Divide; Electrons & Protons; Integration & Derivation; and in set theory. There are so many examples of dualism that it is a philosophy in itself. In programming itself we see Anti-Patterns which helps us to perform work in contrast to how we use Design patterns.
We call it object-oriented programming. Is that a limiting factor or is there something fundamental I am missing in understanding the formation of programming languages?
Edit:
I am not sure, but the usefulness of this duality concept may lie in creating garbage collectors that create AntiObjects that combine with free or loose Objects to destruct themselves, thereby releasing memory. Or may be AntiObjects work along with Objects to create a self-modifying programming language - that allows us to create a safe self modifying code, do evolutionary computing using genetic programming, do hiding of code to prevent reverse engineering.
I've moved this question to Computer Science Site of Stack Exchange, as this is considered off-topic here. Please use that if you want to comment/answer this question.
The inheritance tree is commonly (as it is in C#) a tree, with a single root, for a number of reasons, which all seem to lead back to one big one:
If there were multiple roots, there wouldn't be a way to specify "any type of object" (aside from something like C++'s void *, which would be hideous as it tosses away any notion of "type").
Even the idea of "any type of object" loses some usefulness, as you can no longer guarantee anything about the objects you'll be accepting. How do you say "all objects have properties a, b, and c" in such a way as to let programs actually use them? You'd need an interface that all of them implement...and then, that interface becomes the root type.
GC'able languages would be useless if they couldn't collect every type of object they manage. Oops, there goes that "any type of object" again!
All-around, it's simpler to have one type be the root of the hierarchy. It lets you make contracts/guarantees/etc that apply to every object in the system, and makes fewer demands on code that wants to be able to deal with objects in a universal manner.
C++ gets away with having multiple root types because (1) C++ allows multiple inheritance, so objects can bridge the gaps between inheritance trees; (2) it has templates (which are far, far more able than generics to take any type of object); (3) it can discard and sidestep any notion of "type" altogether via means like void *; and (4) it doesn't offer to manage and collect your objects for you.
C# didn't want all the complexity of multiple inheritance and templates, and it wanted garbage collection.
In Nature, if in a family there are two children who are totally different and opposite from each other, still they have common parents.
All those examples which you have given come under common category. For e.g. Male and Female comes under Homosapiens Category. Plus and Minus come under Operator category.
In OOPS also there are two types. Reference type and value type but still they both come under object.
What you are suggesting is also good. But let us for a second, in a universe, accept what you are suggesting. Still there will be a Super_Class containing your Object and AntiObject class. So it has to stop somewhere and in OOPS object is that class where it stops.
As I understand it, the white dot indicates "optional" while the black dot means "required".
If so, a Category is required while a Classified is optional.
But what does that actually mean in the database - to say that a Category is required and a Classified is optional?
If the child of the relationship (in the example above set as "classified"), is optional then the column is defined with the database as allowing null records. i.e set to NULL. This means that you can either specify no records as being linked from classified to category, or many records.
In some cases, it could mean the difference between a foreign key being allowed to be NULL or not.
In other cases it might be something you need to check via constraints or application code.
Unfortunately I'm unfamiliar with the notation used in the diagram you post so I can't tell you what it means there.