RxJava offers a very large [operator set](http://reactivex.io/RxJava/javadoc/rx/Observable.html). Counting all the overloads, the number of operators on Rx is over 300. A smaller number of those is essential, meaning that you cannot achieve an Rx implementation without them. Others are there just for convenience and for a more self-descriptive name. For example, if `source.First(user -> user.isOnline())` didn't exist, we would still be able to do `source.filter(user -> user.isOnline()).First()`.

Despite many convenience operators, the operator set of RxJava is still very basic. Rx offers the building blocks that you combine, but eventually you will want to define common cases that repeat within your application. in standard Java, this would be done with custom classes and methods. In Rx, you would like to design custom operators. For example, there is no operator for calculating a running average from a sequence of numbers. But you can make one yourself:

That does it, but it's not reusable. In a real application, you will probably want to do the same kind of processing over many different sequences. Even if you don't, you'd still want to hide all this code behind a single phrase: "running average". Understandably, your first instinct would be to make a function out of this:

Once again, this works, but how far can you go with this? Imagine if everything in Rx was done this way (including all the existing operators).

Rx has a particular style for applying operators, by chaining them, rather than nesting them. This style is not uncommon for objects whose methods return instances of the same type. This makes even more sense for immutable objects and can be found even in standard features, such as strings: `String s = new String("Hi").toLowerCase().replace('a', 'c');`. This style allows you to see modifications in the order that they are applied, and it also looks neater when a lot of operators are applied.

Many languages have ways of supporting this. Inconveniently, Java doesn't. You'd have to edit `Observable` itself to add your own methods. There's no point asking for it either, since the RxJava team are conservative about adding yet another operator. You could `extend` `Observable` and add your own operators there. In that case, as soon as you call any of the old operators, you're going to get a vanilla `Observable` back and lose access to the operators that you built.

There is a way of fitting a custom operator into the chain with the `compose` method.

Java doesn't let you reference a function by its name alone, so here we assumed the custom operator is in our Main class. We can see that now our operator fits perfecty into the chain, albeit with the boilerplate of calling `compose` first. For even better encapsulation, you should implement `Observable.Transformer` in a new class and move the whole thing out of sight, along with its helper class(es).

We just added the parameter as a field in the operator, added constructors for the uses that we cover and used the parameter in our Rx operations. Now we can do `source.compose(new RunningAverage(5))`, where, ideally, we would be calling `source.runningAverage(5)`. Java only lets us go this far. Rx is a functional paradigm, but Java is still primarily an object oriented language and quite conservative about it.

Every Rx operator, internally, does 3 things

1. Subscribes to the source and observes the values.

2. Transforms the observed sequence according to the operator's purpose.

3. Pushes the modified sequence to its own subscribers, by calling `onNext`, `onError` and `onCompleted`.

The `compose` operator works with a method that makes an observable out of another. By doing this, it spares you the trouble of doing the 3 steps above manually. That presumes that you can do the transformation by using existing operators. If the operators don't already exist, or if you think you can get better performance manually, you need to receive items manually, process them and re-push them. An `Observable.Transformer` that does this would include a `subscribe` to the source `Observable` and the creation of a new `Observable` to be returned, possibly a `Subject`. As an exercise, you can try implementing an operator (e.g. reimplement `map`) without using any existing operators.

There's a simpler way. The `lift` operator is similar to `compose`. Instead of transforming `Observable`, it transforms `Subscriber`.

* If you are going to use asynchronous operations and scheduling, use the [Schedulers](/Part%204%20-%20Concurrency/1.%20Scheduling%20and%20threading.md#Schedulers) of Rx. That will allow your operator to become [testable](/Part%204%20-%20Concurrency/2.%20Testing%20Rx.md#testscheduler).

If you can't guarantee that your operator will obey the Rx contract, for example because you push asynchronously, you can use the `serialize` operator. The `serialize` operator will turn an unreliable observable into a lawful, sequential observable.

Despite what our observable is set to emit, the end result obeyed the Rx contract. That happened because `subscribe` will temrinate the subscription when the sequence terminates (or was supposed to). It doesn't mean that the problem will be taken care for us. There is also a method called `unsafeSubscribe`, which won't unsubscribe automatically.

Our subscriber's behaviour was identical to the previous example (we created an instance of `Subscriber` because `unsafeSubscribe` doesn't have overloads that take lambdas). We can see here we weren't unsubscribed and we kept receiving notifications.