I am new to architecture design and need some help on this.
I have two class namely 'Part' and 'Supplier'. A part will have supplier.
In my class design, should i have 'int SupplierID' (type is 'int') or 'Supplier supplier' (type is 'Supplier' ) as my property in Part class ?
Which one is better? What is the Pros and Cons of them?
Kinldy provide your input on this.
Supplier supplier
Having Supplier as a type and having SupplierID as a property of Supplier would make more sense to me. The initial benefit is that you can do some basic validation on the supplier ID. Sure you are representing it as an int now but this could (and probably will) change in the future. For example, you may decide to represent the ID as a string and int internally but when reporting it you will represent it as a string: XYZ1234, where XYZ is the Supplier company name(string) and 1234 is the unique ID (int) (bad contrived example maybe, but it is still likely to change in some way)/
The real advantage of having Supplier as a type is due to the fact you will be able to use Dependancy Injection to assign the Supplier to the Part when you create an instance of Part. So your constructor for Part should look like:
Part(Supplier supplier)
{
_supplier = supplier;
}
Now your Part class is not dependant on changes in your Supplier class. I.e. it is not dependant on it.
Note: If your not familiar with Dependancy Injection, this article from Martin Fowler should explain:
http://martinfowler.com/articles/injection.html
Related
The entity is a person.
So the entity have a birthdate and maybe already have a deathdate.
But this dates can or cannot be informed (depends of the entity and avaibility of the informations) ; so the entity might have none of those.
But I feel to do mess with the cardinality and the relation type.
How should I represent that ?
I have created an abstract class Individual. It leads to 2 final class : Person (identified person) or Pseudonym (anonym person).
It linked to a class Birthdate and a class Deathdate (both are generalized as a class Date).
[Birthdate]----<>[Individual] relationship is :
one (optional)-to-many (0..1 - 1..*)
0..1 : Because birthdate can be omitted and individual can have just one date of birth.
1..* : Because birthdate must concern at least one, but can concern severals individual.
[Deathdate]----<>[Individual] relationship is :
one (optional)-to-many (0..1 - 1..*)
0..1 : Because the individual isn't dead yet and can die just once.
1..* : Because deathdate must concern at least one but can concern severals individual.
But since, theoretically, everyone have a birthdate (and will have a deathdate) I was tempted by a composition. But some might prefer keep these dates secret and I wondered if composition could allow that.
Futhermore one date can correspond to severals individuals and here also I guess composition isn't possible then OR else it's me who did the confusion between Individual class and its instances (the individuals) and then Composition would be possible but not with the aforementionned cardinality.
At the moment I chose that :
Aggregation :
___________ _______________
|Birthdate|0..1-----1..*< >| |
___________ | <<Individual>>|
|Deathdate|0..1-----1..*< >|_______________|
But I hesitate with this one
Composition :
___________ _______________
|Birthdate|0..1-----1<#>| |
___________ | <<Individual>>|
|Deathdate|0..1-----1<#>|_______________|
What is the right answer ? Thanks for the attention.
There is a number of issues with the approach.
First - using a class for dates is simply an overkill. Both birthdate and deathdate are attributes of a specific person and can be easily modelled as inline properties of the Individual class. Unless there is some significant reason to use something more than the good old Date DataType, keep with the standard approach.
For visibility issue, as object oriented principles say you should not expose the properties directly anyway. Rather than that you should have an operation responsible for retrieving birthdate and deathdate that will control if the date can be read or not. You may add boolean attributes that will support that, but it isn't necessary if the ability to see the dates depend on some state of the Individual or other things (e.g. "who" asks). In the former case you may also wish to still show explicitly those boolean attributes as derived ones.
If you insist on using a class for dates (e.g. as you want to have a Wikipedia-style "Born on date"/"Deceased on date" collections) you should create just one class Date and build associations to this class pretty much similar to the way you did in your second approach. In such situation, the multiplicity does not work "database style" but is a property of association itself. In particular association you have one birthdate/deathdate and one Individual. By default you will have two 1-0..1 association one for each but depending on the approach you may have much more complex approach as well.
I'll later add diagrams for more clarity.
One last remark.
Do not use << >> for the class name. Those are reserved to indicate stereotypes.
If you want to indicate that Individual is abstract either show it in italics or (if your tool doesn't allow that) use <<abstract>> stereotype.
How does Haskell solve the "normalized immutable data structure" problem?
For example, let's consider a data structure representing ex girlfriends/boyfriends:
data Man = Man {name ::String, exes::[Woman]}
data Woman = Woman {name :: String, exes::[Man]}
What happens if a Woman changes her name and she had been with 13 man? Then all the 13 man should be "updated" (in the Haskell sense) too? Some kind of normalization is needed to avoid these "updates".
This is a very simple example, but imagine a model with 20 entities, and arbitrary relationships between them, what to do then?
What is the recommended way to represent complex, normalized data in an immutable language?
For example, a Scala solution can be found here (see code below), and it uses references. What to do in Haskell?
class RefTo[V](val target: ModelRO[V], val updated: V => AnyRef) {
def apply() = target()
}
I wonder, if more general solutions like the one above (in Scala) don't work in Haskell or they are not necessary? If they don't work, then why not? I tried to search for libraries that do this in Haskell but they don't seem to exist.
In other words, if I want to model a normalized SQL database in Haskell (for example to be used with acid-state) is there a general way to describe foreign keys? By general I mean, not hand coding the IDs as suggested by chepner in the comments below.
EDIT:
Yet in other words, is there a library (for Haskell or Scala) that implements an SQL/relational database in memory (possibly also using Event Sourcing for persistence) such that the database is immutable and most of the SQL operations (query/join/insert/delete/etc.) are implemented and are type-safe ? If there is not such a library, why not ? It seems to be a pretty good idea. How should I create such a library ?
EDIT 2:
Some related links:
https://realm.io/news/slug-peter-livesey-managing-consistency-immutable-models/
https://tonyhb.gitbooks.io/redux-without-profanity/content/normalizer.html
https://github.com/agentm/project-m36
https://github.com/scalapenos/stamina
http://www.haskellforall.com/2014/12/a-very-general-api-for-relational-joins.html
The problem is you are storing data and relationships in the same type. To normalise, you need to separate. Relational databases 101.
newtype Id a = Id Int -- Type-safe ID.
data Person = Person { id :: Id Person, name :: String }
data Ex = Ex { personId :: Id Person, exId :: Id Person }
Now if a person changes their name, only a single Person value is affected. The Ex entries don't care about peoples' names.
Project M63 comes pretty close to what I was looking for. It is written in Haskell.
A more lightweight Haskell solution is outlined in Gabriel Gonzalez's post "A very general API for relational joins".
Now i have two classes, named patient and doctor:
Patient() {
public:
//functions here
private:
Doctor doctor;
Date dateAdmitted;
Date dateDischarged;
}
Doctor() {
public:
//functions here
private:
//data members here
}
In my UML class Diagram for patient class, do i need to include the doctor and date as attribute? or i just represent them by linking them as association?
If attribute it should be like:
Patient
doctor : Doctor
dateAdmitted : Date
dateDischarged : Date
According to UML syntactical rules, both solutions are valid - both class attributes and associated classes are so called class properties and can be shown as attributes (inside the class) or as separate classes, linked via association. For both these class features you can define name, multiplicity, scope, etc. Please refer to UML spec for detailed technical information.
However, the common practice if the following:
if the property is basic data type (int, boolean, date, etc) -> show
it inside a class, as attribute
if the property is full fledged
class -> show it as a separate class entity and use association to
display their relationship
This practice make sense, as "int", "boolean" or "date" do not have their own custom properties and it is enough to show them inside a class (withoult losing information about them). Classes, on the other side, have their own features (attributes, methods and own associations, generalizations, etc) and therefore "deserve" more space on the diagram.
Concluding with the direct answer to your question: show Doctor as a separate class on the diagram, connected with Patient via association (note the property name displayed as associationEnd name). Keep both dates inside the Patient class:
The following diagram is equivalent and valid, but you might agree that the first one is visually clearer (imagine some atts, methods and relationships or the Doctor class) and therefore recommended:
UPDATE (after the comments)
Note: Composition is used for Dates, to reflect a strong relationship of the Whole-Part kind and the fact that these Dates cannot be unlinked from their context.
The other association (Patient-Doctor) is a common assotiation and the corresponding link can be broken anytime (for example to change a Patient's Doctor).
In UML, you would model relationships between classes as an association. Attributes should be for data types.
That they will most likely end up as fields in e.g. Java does not play a role at this stage yet.
Say I'm modeling a school, so I have 2 Entities: Student and Class. For whatever reason, I want each class roster to have a custom sort order. In a simple relationship, this would mean giving Student a sortOrder attribute and just sorting the list by this number. Issue is, a Student might be order 3 in one Class and order 6 in another. How would I store these orderings in Core Data in a way that I can easily access them and sort my lists properly?
Student Class
classes <<--------->> students
^ ^
| |
unordered ordered
This diagram might help explain what I'm trying to do. The students "roster" I would want to be fetched in a specific order stored somewhere, which could be any ordering. Storing this ordering is what I'm not sure how to do in a way that's the most efficient. Creating a bunch of Order objects and trying to manage the links sounds like a lot of overhead, and it feels like there must be a better way.
If the ordering of students can be described by one or more NSSortDescriptors, you could create a fetched property on the Class entity that fetches the students and applies the sort descriptor. Alternatively, it may be easier (depending on your use case) to apply the sort descriptor(s) to the NSFetchedResultsController that you're using to deal with the class' students collection.
If you can't use an NSSortDescriptor, then you'll need an index attribute (or name of your choice) on the Student entity if there's only one ordering or a collection of Order entities describing the index in each ordering for each Student. You'll be responsible for maintaing these index values. Unfortunately, there's no easy way to do this in Core Data. It's just a lot of work.
Student <<->> StudentClass <<->> Class
StudentClass
----
studentID
order
classID
Then you can select as necessary.
For example, you have a student. Fetch all StudentClass where StudentID is student.studentID. You then have the order, as well as access to the Class.
You'll likely want to add some business logic to make your life easier. Also, if you're not already using it, take a peek at MOGenerator: https://github.com/rentzsch/mogenerator
EDIT: I'd really like to know why this is getting voted down. Comments would be much appreciated.
I am just starting to use the Entity Framework 4 for the first time ever. So far I am liking it but I am a bit confused on how to correctly do inheritance.
I am doing a model-first approach, and I have my Person entity with two subtype entities, Employee and Client. EF is correctly using the table per type approach, however I can't seem to figure out how to determine what type of a Person a specific object is.
For example, if I do something like
var people = from p in entities.Person select p;
return people.ToList<Person>();
In my list that I form from this, all I care about is the Id field so i don't want to actually query all the subtype tables (this is a webpage list with links, so all I need is the name and the Id, all in the Persons table).
However, I want to form different lists using this one query, one for each type of person (so one list for Clients and another for Employees).
The issue is if I have a Person entity, I can't see any way to determine if that entity is a Client or an Employee without querying the Client or Employee tables directly. How can I easily determine the subtype of an entity without performing a bunch of additional database queries?
Use .OfType<Client>() in your query to get just the clients. See OfType.
e.g. entities.Person.OfType<Client>() ...
Use is to test if a Person object is a specific sub-class, e.g. if (p is Employee) ...
BTW why isn't it entities.People? Did you not select the pluralization option?