views:

66

answers:

2

I'm developing a library containing multiple controls (or components). I'm using an interface based approach to type design, but eventually it led me to a question that bothers me for a long time. If you use an interface-based design approach, how do yo name the behaviour interfaces? For example, let's assume you have some getter setter functions and they're used by many interfaces, and functionality they provide is cannot be named with a "-able" postfix; what would you do, or do you do? Thanks...

Edit: For example i created an interface like this:

public interface HasText {

    public String getText();

    public void setText(String text);

}

most interfaces that use this functions has no common super type.

+1  A: 

Sure that you need different behaviour interfaces? Wouldn't it be enough to implement one behaviour interface and a couple of concrete behaviours?

Just an example, assume we have an imlplementation of a real wild animal, say a class Cat with some sensors and a big catalog of behaviours. Now the cat's eye-sensor reports "mouse!!". The Cat will query it's Collection of Behaviour instances if there's a fit, iaw, if any of the stored Behaviour instances likes to take action. Assume we have an instance of class HuntMouse implements Behaviour stored in the list and this is the best fit, then the cat would call action() on that Behaviour and hunt the mouse.

Back to your question - I think, one Behaviour interface with 2-3 methods would be enough, concrete Behaviour objects do not need a prefix or suffix. And if needed, I suggest -Behaviour (like HuntMouseBehaviour)


Initially you asked for Behaviours but your HasText example shows some kind of Feature. Where in this special case, TextProvider could be an a better choice while hasText is more suiteable. Implementing the interface adds the provide some text feature to the class.


Not as an answer to the question but for further reading: List of behavioural design patterns.

(BTW - my example above was inspired by real implementations from the robotics area - even though a cat is not a robot ;))

Andreas_D
to be more precise, i'm trying to group common properties between some interfaces, i dont want to use command-like approach because specialized methods like getName() are more readable than get("name").
Deniz Acay
Having a Behavior interface, collections of unknown behaviors, etc. is fine if you have specific need for it, but isn't such need an exception, not the rule? Two advantages to using getName() instead of get("Name") are that getName gives you static typing (it returns a string, getDate() returns a DateTime, but get("propertyName") returns an object), and that strings (e.g. "Name") do not play well with refactoring tools--e.g., if you want to change "Name" to "PersonName", you have to resort to find-and-replace.
apollodude217
@apollodude217 - the example that Deniz added yesterday, is not an interface for a *Behaviour* but more for a *Feature*. You wouldn't say something like: 'the class behaves like having a text', it's more like: 'the class has the provide-text feature'. And of course, one would not use inheritance for the main class, not 'a cat **is-a** behaviour' but 'a cat **has-a** behaviour'. Only behaviours would implement a `Behaviour` interface.
Andreas_D
@Andreas_D it is a good example of course, just not what i was looking for; but thanks for useful information, voting up...
Deniz Acay
+1  A: 

Name the interface as a word or phrase correctly describing any class that implements it. "HasText" is a fine example as it describes the implementor (it has a Text property).

Make it specific to the interface. "IsAnObject" or "MightHaveData" or "ExistsInCyberspace" is not specific to the interface.

apollodude217