Are there two type of associations between objects or are there just different representations?

Question

I've been spending some time on 're-tuning' some of my OOP understanding, and I've come up against a concept that is confusing me.

Lets say I have two objects. A user object and an account object. Back to basics here, but each object has state, behaviour and identity (often referred to as an entity object).

The user object manages behaviour purely associated with a user, for example we could have a login(credentials) method that returns if successfully logged in or throws exception if not.

The account object manages behaviour purely associated with a users account. For example we could have a method checkActive() that checks if the account is active. The account object checks if the account has an up-to-date subscription, checks if there are any admin flags added which would make it inactive. It returns if checks pass, or throws exception if not.

Now here lies my problem. There is clearly a relationship between user and account, but I feel that there are actually two TYPES of association to consider. One that is data driven (exists only in the data/state of the objects and the database) and one that is behaviour driven (represents an object call to methods of the associated object).

Data Driven Association

In the example I have presented, there is clearly a data association between user and account. In a database schema we could have the following table:

-----------------
  USER_ACCOUNTS
-----------------
 id
 user_id
 ----------------

When we instantiate the account and load the database data into it, there will be a class variable containing user_id. In essence, the account object holds an integer representation of user through user_id

Behaviour Driven Association

Behaviour driven associations are really the dependencies of an object. If object A calls methods on object B there is an association going from A to B. A holds an object representation of B.

In my example case, neither the user object nor the account object depend on each other to perform their tasks i.e. neither object calls methods on the other object. There is therefore no behaviour driven association between the two and neither object holds an object reference to the other.

Question

Is the case I presented purely a case of entity representation? The association between user and account is always present, but its being represented in different ways?

ie. the user entity has an identity that can be represented in different forms. It can be represented as an object (the instantiated user object) or as a unique integer from the users table in the databases.

Is this a formalised way of recognising different implementations of associations or have I completely lost my mind?

One thing that bugs me is how would I describe the differences in UML or similar? Or is it just an implementation detail?

Answer 1

It s a bit hard to fully understand what is problem actually in :). I think you are a bit mixing some concepts.

Entities representation

At first, all models we are implementing is just a simplification of some real-world objects and environment. Your conceptual entity user corresponds to some real user and contains some attributes we are intresteing in according to application needs. Thus there are some models we have to implement.

Thus, all user defined by DB schema, user defined by class, and probably user defined by some presentation logic is normally present some real-world user. It is only about implementation purposes, we have to store, view and manipulate with user.

On the other hand let's take a look on Single Responsibility Principle. It tells us to use every class or program unit just for certain needs. Using single user (class or program unit) for storage and presentation needs violates this principles.

the user entity has an identity that can be represented in different forms. It can be represented as an object (the instantiated user object) or as a unique integer from the users table in the databases.

So, the answer is yes.

Associations and dependencies

I think it is more about terminology than about nature of problem. But in general you are right - there are different types of object realtions (especially, I will use other terms to list it). For example "referencing", "creation", "using", "coordinating", "storing", "inheriting" (!) ....

According to this, user instance references account instance. And A instance uses B instance.

For most cases it is good enough to distinguish just "referencing" and "using". It is what you've just written. It's enough common and abstract to be understood by other person when talking about domain, e.g.

But sometimes, to emphasize some aspects you should describe relations in a way like "A dispatches ensemble of Bs" or "R stores X to database". It's more applicable for specification and modelling.

Is this a formalised way of recognising different implementations of associations or have I completely lost my mind?

To call something formalized I suggest to look at UML.

UML and other modelling instruments

One thing that bugs me is how would I describe the differences in UML or similar? Or is it just an implementation detail?

There are a lot of UML models (diagrams). Let's take a look at most well-known - Classes and Objects Diagram.

It's interesting that UML allows to present all type of object relations, and moreover allows to decide "is it just an implementation detail".

Martin Fowler describes 3 levels (or point of views) of understanding of Classes Diagram.

1. Conceptual. Diagram is considered as high-level domain model, independent from implementation.
2. Specification. Diagram is considered as high-level realization model containing of interfaces.
3. Implementation. Diagram is considered as low-level technical paper containing interfaces, classes, references, other types of relations.

Is this a formalised way of recognising different implementations of associations or have I completely lost my mind?

Yes, you have to fix some point of view and choose appropriate relations set.

For example, let's take a look at Classes Diagram and consider it from an implementation point of view. UML defines 3 type of relations (and propose corresponding means to its designation):

Association

Association corresponds "referencing" between instances.

Dependency

Dependency combines all types of relations such as "using", "creating", "storing", etc.

Inheritance.

Inheritances as a fundamental OOP instrument is presented by UML in a distinct way. It's more about classes than about instances, but also one can say that A instance inherit attributes of B instance. So, that's ok.

First and second points of view on Class Diagram, as I remember uses only one type of relation unifying both associations and dependencies and is designated like association (no inheritance, of course).

Also, UML proposes Objects Diagram which is same to Classes Diagram, but fits better for runtime modelling needs.

Finally, a choice of a set of relations taken into consideration depends on a context and point of view. UML provides some ones.