3

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 ?

  • possible duplicate of what is message passing in OO? – gnat Mar 22 '14 at 7:55
  • @gnat oop manner in php, i dont think message passing is an php thing.. – Zalaboza Mar 22 '14 at 8:12
  • message passing in OOP is language-agnostic concept, it doesn't matter PHP or Java or Smalltalk, whatever – gnat Mar 22 '14 at 8:14
  • 1
    removed duplicated part of question, thanks for headsup – Zalaboza Mar 22 '14 at 8:18
  • Check out Pebble for a somewhat complex domain model of a blog system. Not saying it's good or bad, but it might give you some ideas of what behaviors exist in the objects in this domain. – Fuhrmanator Mar 22 '14 at 20:30
5

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.

1

what could be the User object Behavior ?

I cannt find any !

login, its an auth lib. thing so i should not include it in user. 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 !

Think about the system you are modeling, and worry less about where in the computer stuff happens.

Think about how you would do this in the real world. A blog post exists as a thing. But where did it come from? In most cases an author wrote it. That is behavior. Thus in modeling a system with OO design it makes sense to model that behavior by representing an author object that publishes blog posts.

"User" is way too general a term to have any meaning at this level. Think about the users of the system in terms of the behavior they carry out. An author of blog posts is very different behavior to a reader of blog posts, just like a newspaper reporter is very different to a newspaper reader. These can, and probably should, be different objects.

If all the different types of users share a common behavior, such as logging into the system, then you may have them all inherit from a parent "User" object that has one method, "log myself in".

This is behavior of the user, nothing else logs in to the system other than users after all. They may log in through an authentication system, but that system does not log in itself. So a User may carry out the "log myself in" message by sending another message to the authentication system saying "Here are my username and password, please authenticate me on the system".

0

There are no limits to allowed methods in an object, but there are philosophies about behavior when it comes to good design. There are many heuristics (rules of thumb that don't offer guarantees of a good design, but which have shown merits in the past).

As stated by Bart, software object behaviors can be classified as accessors (which don't change the state of an object but rather usually access information within the object, e.g., getters) and mutators (which do somehow change the state of an object, e.g., setters). Normally, the two should be separated -- an accessor should not also modify the state of the object. Combining those behaviors leads to problems in quality of the software, since it's harder to test how these behaviors work.

Perhaps if you consider object behaviors in terms of responsibilities, it might help. Responsibility-driven design is the name of the paradigm, if you want to find more info.

Software objects are not real-world objects, so I think the numerous examples with behaviors of Dogs, Birds, etc. lead to confusion. Software objects are part of a design to solve a problem that ties to the real world. Using objects should help one to understand the solution to a real-world problem, since an object abstraction is closer to how we think of elements in the real-world problem domain. That said, software behaviors are not necessarily real-world behaviors.

Dogs: If you are designing a software that helps veterinarians manage their business, you might have Dog objects. But their "bark" probably won't matter for this kind of problem and certainly won't be a behavior of the software object. However, it might be if you're trying to simulate something where a dog's barking is part of the problem (e.g., a sim game where police show up if too many of the player's dogs are barking in her back yard because they're hungry or bored).

Blogs: if a Blog has a limit to the number of messages it can contain, a possible behavior might be to "truncate()" itself (although it's debatable whether a blog should enforce this behavior itself or an outside entity). Truncate is an example of a mutator. A behavior to "getAuthor()" of a Blog would be an example of an accessor.

Behaviors should not reveal the implementation of your classes, if you want to strive for information hiding in your design. As for other 'rules of thumb' about behaviors, there are many when you go with responsibility-driven design (and you'll see things get very complicated with gray areas). Check out GRASP and SOLID for a start (some of the rules overlap - it's because OO software design is still a relatively immature discipline, compared to Bridge design or Furniture design).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.