OOP Design Patterns – Object-to-Object Communication Explained

design-patternsdomain-driven-designobject-orientedobject-oriented-designPHP

I've been reading in basic concepts of OOP,as i'm trying to make this shift from transactional scripts to more oop manner in php, and i often come across this definition :

An object stores its state in fields (variables) and exposes its
behavior through methods (functions). Methods operate on an object's
internal state and serve as the primary mechanism for object-to-object
communication

and a simple example like :

Objects like real life objects have state and behavior. Dogs have
state (name, color, breed, hungry) and behavior (barking, fetching,
wagging tail).

from definition i see that methods should be either manipulating internal state (setters) or communicating with other objects;

but when i try to apply this to a Blog example. composed of mainly 2 domains User and posts.

what could be the User object Behavior ?

I cannt find any !

  1. login, its an auth lib. thing so i should not include it in user.
  2. posting articles is a Post object thing; again user conduct it; but its more of a post object concern to create a post right ?

User may be the main Aggregate object in a blog; yet the user is more like the Creator of Other Objects but he does not have a Behavior i can think of; he is being used -and his state- by other objects in most cases that all !

in a nutshell : what are allowed type of methods inside an object ?

Best Answer

There is no hard and fast rule which methods an object must have.

Something is an object if you can talk about it as an entity with a name that is familiar to domain experts in either your problem domain or the solution domain. In essence, if you have a related set of properties and behaviors that you can refer to by a single name, then that set of properties and behaviors is an object.

The behaviors that I refer to fall into two broad categories:

  • Requests to take an action. The classic example of Dog::bark() falls in this category.
  • Requests for information. Most getter functions fall in this category.

There is nothing wrong with an object that has mostly (or only) getters. Some objects in some domains are just model an entity that must exist but that does not have any active behavior. Your User class might be one of those.

A class X with mostly getters becomes a code smell when

  • each getter also has a setter to change the property, and
  • either class X has invariants (invalid combinations of property values) that can be broken if you use the setters 'wrongly', or
  • class Y is performing operations on the properties of X that would logically fall within the responsibility of X.

An example of the first class with a code smell would be a class like this:

class Square {
    int x1, x2, y1, y2;
public:
    void SetTopLeft(int x, int y);
    void SetBottomRight(int x, int y);
};

Allowing to change the top-left and bottom-right coordinates independently makes it very easy to break the invariant that all sides of a square must have the same length and all corners are square.

An example of the second form of the code smell is a Dog class where the client moves a Tail object to make the dog wag its tail.

Related Topic