From what I've read and what I've seen, I consider multiple inheritance as a bad practice, not by itself but because it leads beginner to use everywhere where more elegant design patterns might be useful and more meaningful.
Some languages have chosen not to implement multiple inheritance and then have chosen to implement traits (e.g. PHP). The only interesting and substantial difference I see between multiple inheritance and traits I see is a linguistic one: while "inheritance" indicates some kind of shared nature, "trait" stands more for features.
Is there any other important difference I'm missing that would explain why some consider that multiple inheritance was inappropriate and that, now, traits are appropriate?
You could use traits to fake multiple inheritance, but I believe the basic difference is a conceptual one. A parent-child relation is a "is-a" relation.
If you have a Furniture class, with a Table child and a PicknickTable child, you have Picknicktable is-a Table is-a Furniture (hmm, is furniture countable like that? nvrmnd).
With traits, you just say: I hate to keep on writing the code to put stuff on a surface, so I write the "putStuffOnThisThing" trait, and they have it. This is not inheritance! The basic fault behind such reasoning might be is that you want to look at traits as a different way to show hierarchies while you shouldn't. It is no substitution for an actual good design, it is a trick in the toolbox that you could misuse for multiple inheritance, but you might be better use as a way to avoid writing some lines several times.
So in defence of the comparison: traits have some of the same problems as multiple inheritance, like the problem you need to address with aliasing in case of multiple things with the same name. While this is not exactly the diamond problem, it comes awfully close.
Related
I'm creating clothing shop and therefore I'm creating gallery functionality which consists of 2 types: Product gallery and lookbook gallery. A product gallery is simply pictures of singular products and a lookbook gallery is pictures that contains multiple products.
So far i I have a simplified UML diagram somewhat like this
I'm not sure how to translate this into MySQL tables. I've tried and I came up with something like this
But it seems like overkill and smells funny to me. What would be best practice in my situation? Am i on the right track or am i way wrong?
I don't know what "best practice" is on this, you could use a NO-SQL database or if you used a relational database you could just use 3 tables, Galleries, Pictures and Products.
A Gallery can contain many Pictures
A Picture can contain many Products.
The distinction between the types of galleries is just contained in an attribute.
Firstly consider whether inheritance is the best way to implement the behavior you need. Generally it is best to prefer composition over inheritance. From your diagram I'd say that you really don't need inheritance at all to solve your problem.
If you do need to implement inheritance then there are a number of strategies you can use. It is a really good idea to look for an object relational mapper as a good one can make implementing the below strategies much easier. If your using .NET then NHibernate or Entity Framework are good options. For Java Hibernate is pretty good.
Table per class hierarchy
Here you'd create a single table for the entire class hierarchy. This makes most sense
when the classes in the hierarchy all share many columns. You'd need to add a "discriminator" column so you could identify which subclass each row belongs to. In your example you'd have
gallery
picture
I'd say this strategy makes most sense for you as there don't appear to be many different columns between your sub-classes.
Table per subclass
In this example you'd create a table for each subclass. This makes most sense when the classes in the inheritance hierarchy don't share many common columns.
So you'd have tables like this:
product_gallery
logbook_galleries
product_picture
logbook_picture
Table per class
This is the strategy from your diagram. Like table per-subclass, This is useful when each of the sub-classes has different columns. The advantage over table-per-subclass is that it is easier to query the entire class hierarchy in one big join, the disadvantage is that you end up with lots of tables.
That database schema looks like it's doomed to fail. The most important thing to do when defining a schema is to start with the nouns and verbs of your problem. Describe in words what your environment is like. What entities are there? How do the entities interact with one another? For example, "a gallery has pictures." That statement alone tells you there is an association between a gallery and pictures.
Once you come up with your noun-verb associations, you can begin illustrating entities such as "gallery" and "picture." Is there a one-to-one relationship among galleries and pictures, or is there one gallery to many pictures?
Think on these things, and check out some basic design tips here: http://msdn.microsoft.com/en-us/library/b42dwsa3(v=vs.71).aspx
What is the accepted terminology to use for referring to the items of a dependency?
I've been using parent and child, where parents depend on their children, but this caused some confusion when someone else thought that children depended on their parents. Arguably both are true in real life.
We found that dependent isn't clear enough- you have to think really hard about which end it is referring to.
Bonus points for links to documents using or better yet discussing such terminology.
I've only ever heard of a child being the dependent. That goes for real life too (excluding some scenarios involving sickness or old age). From modelling heirachies in a database to filling out my tax return at the end of the year to changing nappies(diapers), my experience has been that a child always is the dependent of a parent.
If you need to describe entity relationships more thoroughly then you can use ER modelling. Or on the attribute level functional dependencies.
"Parent" and "child" are fine.
At the level of physical FOREIGN KEYs, the terms "referencing" and "referenced" are sometime used.
When talking about X:Y relationships in the logical model, the cardinality is sometimes used. For example, a 1:N relationship might use the terms: "1 endpoint" and "N endpoint".
In the end we decided to use item and depends_on. It's easy to read and avoids any ambiguity.
You could use dependent and depends_on, but it doesn't read as well.
Someone suggested requires and enables - I really like this.
How do you know when to create a new table for very similar object types?
Example:
To learn mysql I'm building a model solar system. For the purposes of my project, planets have many similar attributes to dwarf planets, centaurs, and comets. Dwarf planets are almost completely identical to planets. Centaurs and comets are only different from planets because their orbital path has more variation. Should I have a separate table for each type of object, or should they share tables?
The example is probably too simple, but I'm also interested in best practices. Like should I use separate tables just in case I want to make planets and dwarf planets different in the future, or are their any efficiency reasons for keeping them in the same table.
Normal forms is what you should be interested with. They pretty much are the convention for building tables.
Any design that doesn't break the first, second or third normal form is fine by me. That's a pretty long list of requirement though, so I suggest you go read it off the Wikipedia links above.
It depends on what type of information you want to store about the objects. If the information for all of them is the same, say orbit radius, mass and name, then you can use the same table. However, if there are different properties for each (say atmosphere composition for planets, etc.) then you can either use separate tables for each (not very normalized) or have one table for basic properties like orbit, mass and name and a second table for just the properties that are unique to planets (and a similar table for comets, etc. if needed). All objects would be in the first table but only planets would be in the second table and linked through a foreign key to the first table.
It's called Database Normalization
There are many normal forms. By applying normalization you will go through metadata (tables) and study the relationsships between data more clearly. By using the normalization techniques you will optimize the tables to prevent redundancy. This process will help you understand which entities to create based on the relationsships between the different fields.
You should most likely split the data about a planet etc so that the shared (common) information is in another table.
E.g.
Common (Table)
Diameter (Column)
Mass (Column)
Planet
Population
Comet
Speed
Poor columns I know. Have the Planet and Comet tables link to the Common data with a key.
This is definitely a subjective question. It sounds like you are already on the right lines of thinking. I would ask:
Do these objects share many attributes? If so, it's probably worth considering at the very least a base table to list them all in.
Does one object "extend" another - it has all the attributes of the other, plus some extras? If so, it might be worth adding another table with the extra attributes and a one-to-one mapping back to the base object.
Do both objects have many shared attributes and unshared attributes? If this is the case, maybe you need a single table plus a "data extension" system where each object can have a type or category that specifies any amount of extra attributes that may be associated with it.
Do the objects only share one or two attributes? In this case, they are probably dissimilar enough to separate into multiple tables.
You may also ask yourself how you are going to query the data. Will you ever want to get them all in the same list? It's always a good idea to combine data into tables with other data they will commonly be queried with. For example, an "attachments" table where the file can be an image or a video, instead of images and video tables, if you commonly want to query for all attachments. Don't split into multiple tables unless there is a really good reason.
If you will ever want to get planets and comets in one single query, they will pretty much have to be in the same table if you want the database to work efficiently. Inheritance should be handled inside your app itself :)
Here's my answer to a similar question, which I think applies here as well:
How do you store business activities in a SQL database?
There are many different ways to express inheritance in your relational model. For example you can try to squish everything in to one table and have a field that allows you to distinguish between the different types or have one table for the shared attributes with relationships to a child table with the specific attributes etc... in either choice you're still storing the same information. When going from a domain model to a relational model this is what is called an impedance mismatch. Both choices have different trade offs, for example one table will be easier to query, but multiple tables will have higher data density.
In my experience it's best not to try to answer these questions from a database perspective, but let your domain model, and sometimes your application framework of choice, drive the table structure. Of course this isn't always a viable choice, especially when performance is concerned.
I recommend you start by drawing on paper the relationships you want to express and then go from there. Does the table structure you've chosen represent the domain accurately? Is it possible to query to extract the information you want to report on? Are the queries you've written complicated or slow? Answering these questions and others like them will hopefully guide you towards creating a good relational model.
I'd also suggest reading up on database normalization if you're serious about learning good relational modeling principals.
I'd probably have a table called [HeavenlyBodies] or some such thing. Then have a look up table with the type of body, ie Planet, comet, asteroid, star, etc. All will share similar things such as name, size, weight. Most of the answers I read so far all have good advise. Normalization is good, but I feel you can take it too far sometimes. 3rd normal is a good goal.
I have a class A that has a collection of objects of Class B.
Class A can also 'inherit' (for lack of a better term) the collection of objects of Class B from other instances of Class A. To model this, instances of Class A point to other instances of Class A (I control for circular references).
A simplified concrete example might be that a person has biological children but also 'inherits' children from their spouse and ex-spouses.
I use instances of class A with and without the inherited objects in my application at run-time. That is, both 'projections' of instances of Class A are meaningful to me in the context of my application in difference scenarios.
My question is, is there a pattern for coding this sort of model or standard terminology? I don't think 'inherit' is the right word here. I have my own ways of handling it technically and my own cumbersome terminology but I'm imagining there is a standard pattern I can adhere to that I just can't seem to find.
An imperfect analogue would be inspecting the methods of .NET classes with and without their inherited methods or inspecting prototypes in Javascript, but here I'm 'inheriting' records/objects.
Looks like the composite pattern to me, with A objects being composites and B leafs. The one object A that points to other objects A is a root item. The difference seems that when getting leaf items you distinguish whether the root item includes leaf items from other composites it knows of or not.
No, I don't think (A) there are common OOP idioms for what you're doing, nor (B) any prominent patterns similar to yours. And (C), that is absolutely fine. Now maybe you should be doing it this way and maybe you shouldn't be. Whenever you're doing something that you have a hard time describing, you should certainly second-guess yourself and wonder if there's a simpler way of doing it. But, the lack of common terminology for describing your model, and it not fitting into a "pattern" you've heard of, does not in itself indicate a problem. Classes sometimes have to do wacky stuff under the hood. That's the point. If you're encapsulating a lot of complexity for the consumers of these classes, and it's intuitive and logical and discoverable for them, then great!
It is a mistake though to improperly use common terms to try to help someone understand. In fact, your use of the term inherit above really confused me, and I'm still not 100% sure I have it. Is it this?
An object of class ClassA maintains a collection of ClassB objects. In addition, some of a ClassA object's functionality has to act upon not only its own ClassB objects, but those maintained by other ClassA objects as well. A ClassA object maintains references to other ClassA objects for this purpose.
Assuming I have it correct of course, I think that's a good way to decribe it. And since there is precisely no inheritance here, it would confuse people if that term were used. Also, do not ever, ever, every be distressed if what you're doing does not match some pattern somewhere.
I think your model is at fault. If two or more instances of a class have a relation with an instance of another class, the correct model is not to make one of the instances contain the third - it is to make both of them refer to the third. In the case of human parents, each should refer to the same "offspring" (a list of human children) object. You then control the referred to class via mechanisms such as reference counting.
OOP defines two basic types of relationships:
A is a B
A has a B
Within the second category you have subcategories:
A contains B
B is a component of A
A is associated with (or references) B
The first two are similar, but your concrete example clearly refers to the 3rd. Parents do not contain children, they are related to their children, and when somebody marries into family, they have new relationships (associations) created with the existing family.
So I guess the answer is no, there is no "pattern." You are simply copying/transforming a set of relationships from one instance to another.
Something keeps showing up in my programming, and it is that two things are the same from some viewpoint, but different from another. Like, imagine you build a graph of rail stations, connected by trains, then the classes Vertex and RailStation are sometimes the same, other times not.
So, imagine I have a graph that very much represents rail stations and trains. Then I hand this graph to another object, which deletes some vertices, and then I want the corresponding rail stations to be gone.
I don't want to make rail stations "properties" of vertices, they're not. Also, the problem is symmetrical: If I erase a railstation, I want the corresponding vertex to be gone. What is the proper OO way to model or correspondences. I'm willing to go a few extra miles by writing some support methods or classes, if in the end the overall usage is simple and easy.
I'm currently using the Smalltalk programming language, but the question isn't really smalltalk-specific, I think. I just mention it because in Smalltalk, you can do cool tricks like examining the call stack, which might be helpful in this context.
Update:
Well, RailStations aren't Vertices! Are they?
Ok, let us consider real code, as demanded in the answers. Let me model a person with children. That's the easiest thing, right? Children should also know their parents, so we have like a doubly linked tree. To make disbanding parents from children easier, I model the link between parent and child as a Relationship, with properties parent and child.
So, I could implement parent>>removeChild: perhaps like this
removeChild: aChild
(parent relationshipWith: aChild) disband.
So, a parent has a collection of relationships, not of children. But each relationship corresponds to a child. Now I want to do things like this:
parent children removeAllSuchThat: [:e | e age < 12]
which should remove the relationship and the child.
Here, relationships and children correspond in some sense. So, what do I do now? Don't get me wrong, I'm fully aware that I could solve the problem without introducing Relationship classes. But indeed, parents and children actually do share a relationship, so why not model that and use it to help disbanding double links less imperatively?
In your problem domain, aren't stations a kind of vertex? In which case, why not derive Station from Vertex?
Notice the use of the phrase "in your problem domain". Your problem appears to be about the use as railway stations appearing in a graph. So yes, in that domain, stations are vertexes. If it was a different problem domain, say a database on railway station architecture, they may well not be. Most modern languages support some idea of namespaces to allow you to have different kinds of entity with the same names in different domains.
Regarding your parent/child problem, once again you are being too general. If I were modelling mathematical expressions and sub expressions, if I remove a parent I would want to remove and delete/free all subexpressions. OTOH, ff I were modelling legal responsibility relationships in the UK population, then when a responsibility isis dissolved (say because of a divorce), I only want to remove the relationship, and NOT delete/free the child, which has its own independent existence.
It seems like you just want RailStation to inherit from Vertex (is-a relationship). See this smalltalk tutorial on inheritance. That way, if you have a graph of RailStations, an object used to dealing (generically) with graphs of Vertexes would handle things right naturally.
If this approach won't work, be more specific (preferably with real code).
From your description of the problem, you have a one-to-one correspondence of stations to vertices and deleting a station should automatically delete the corresponding vertex (and vice-versa). You also mentioned building "a graph of rail stations, connected by trains", by which you apparently mean a graph in which stations are vertices and trains are edges.
So, in what way is a station not a vertex? If the station does not exist except as a vertex, and if a vertex does not exist except as a station, then what benefit do you see in maintaining them as two distinct-but-linked entities?
As I understand your situation, station-isa-vertex and inheritance is the way to model that.
Having a Relationship object is a good idea.
I think the appropriate question here is "which use should be made of it?".
Probably Parent and Child classes are extending the same Person superclass, so they'll have some attributes in common, age for example.
In my idea, I can see the following: Parent and Child objects have to know each other, so both classes have to keep a link to the same Relationship.
The Relationship object keeps a one-to-many relation between a single parent and a certain number of children, and it'll keep a reference to each Person object.
This way you can implement the whole disbanding logic within the Relationshp object, more or less sophisticated as you wish. You can query the Relationship object to know which members of the family match your requirements to do something. You can make the relationship to disband (and destroy) safely, as it will know all members and would ask them to break the reference and then it would be ready to destroy, or ask to some member to leave the family, keeping the Relationship object alive.
But that's not all. Relationship should be really a superclass, extended by HierarchicalRelationship and PeerRelationship (or FriendRelationship).
This specialization lets you have Parent(s) and Child(ren) to link between other hierarchies in a completely traversal way.
The true concept behind this is that your Relationship objects are the key to query and organize the whole bunch of Person objects (or Vertex objects) in a scalable and structured way, so the whole data domain you end up with is usable in any sense you like, whether you want to disband groups or walk a certain path (or railroad) between them.
Sorry for the huge amount of metaphores.
Take a look at Fame, see http://www.squeaksource.com/Fame.html
We use a specialized subclass of Collection that updates the opposite end when you add or remove elements. Also, you can annotate your classes with pragmas to annotate relations. These pragmas are used by the Fame framework to do all kind of nice stuff.