1) Документируй
2) Абстрагируйся всегда максимально
3) Пиши классы по принципу "черного ящика"
4) Один класс решает одну конкретную задачу, не стоит городить комбайны.

Потому что у p2p только один единственный плюс в виде децентрализации и он же является минусом перечеркиващим все остальное. Сам p2p также фигово предназначен для передачи мелких и РАЗНЫХ данных но хорошо для передачи мелкими кусочками болищих неменяющихся данных.

Т.е. грубо говоря одно дело идет раздача 1гб данных куче пиров которые также становится раздающими и в целом ускоряют раздачу потому что этот гиг хочет 1000 человек. Другое дело у тебя 10 байт текста обвязанных 300 байтами служебки и их надо передать одному единственному или паре пиров, остальным он не нужен, в таком случае сеть грубо говоря превращается в кучу шлюзов ретрансляторов из разряда ПирА(отправляет сообщение пиру Я) -> увидел пирБ(не мое передам дальше и затру у себя)->...-> поймал пирП(не мое передам дальше и затру у себя) ->...->->получил пирЯ(а это мне!). В савокупности для передачи породится космическое число мусора и изначальные байта сообщения по дороге выжрут мегабайты чужого трафика. Кроме того время доставки сообщения может быть очень большим пока сообщение путешевствует от пира к пиру даже потому что иногда придется искать маршрут что говорится в слепую не зная с какой стороны находится адресат.
Почему на мобилках не интересен и не популярен тот же токс, ну вот ты пользуешься торрентом на телефоне? Аааа трафик жалко стало да? вот и тут схожая ситуация.

Вобщем для передачи однотипных данных прокол просто изумительный, для передачи мелких или часто изменяемых он ужасен и неповоротлив.

Намного более интересные это жаббер\matrix которые могут быть гибридными, проще это представить как почту где ты привязался к сервису например яндекс и можешь отправить сообщение пользователю который привязан к гуглу, каждый сервис имеет свои плюшки а если что то не нравится то всегда можно найти другого провайдера почты. Но к сожалению яббер не нашел массового успеха погрязнув в стандартах изза чего потерял совместимость, а матрица досих пор в каком то непонятном состоянии.

Видимо не достаточно понимаете =)
Когда вы имплементируете интерфейс, к примеру Runnable, то вы реализуете метод run(). Вы его не переопределяете а реализуете, это не одно и тоже с переопределением. В JAVA есть класс Thread в котором объявлено что он знает интерфейс Runnable(вполне конкретный) и что в нем совершенно точно есть реализация метода run(), других методов которые не объявлены в интерфейсе не знает.
Например если вы создатите свой интерфейс:

interface MyRunnable{
      void run(); 
}

То класс Thread никак не будет знать что это и что с ним делать и пошлет вас в веселую пешую прогулку.
Даже если вы создатите "однофамильца":

interface Runnable{
      void run(); 
}

То класс Thread никак не будет знать что это и что с ним делать и пошлет вас в веселую пешую прогулку. Потому что это не реализация java.lang.runnable.
Зато такой момент сработает:

interface MyRunnable extends Runnable{
      void some(); //Обратите внимание что тут уже run нельзя объявить т.к. он объявлен в  Runnable
}

и при реализации этого интерфейса вас заставят реализовывать уже 2 метода

class CoolRunnable implements MyRunnable{
      void some(){System.out.print("some from MyRunnable")} 
      void run(){System.out.print("run from Runnable")} 
}

И в этом случае класс Thread увидит что класс CoolRunnable реализует интерфейс Runnable в котором есть метод run() о котором он знает и который ему нужен. Метод some() он не увидит. При запуске соответственно он выведет только "run from Runnable".

Если попробовать на пальцах объяснить так сказать по аналогии с чемто. Скажем вы класс который может нажимать на левую кнопку мыши. Ничего другого вам не объясняли. Т.е. вам дали описание что это называется мышь и на котором есть кнопка слева и которую нужно нажать. Теперь любой производитель берет это описание и реализует мышь с левой кнопкой. Каждый свою, из разного материала, с разными механизмами кнопки и принципами работы, разной формы, и даже с кучей других кнопок. Все они попадают к вам, вы смотрите что конкретный экземпляр мыши реализован по описание которое вы знаете, кроме того это именно то описание что у вас а не одноименное. На основе этого вы признаете что эта вещь вам подходит и начинаете нажимать левую кнопку мыши на любой такой мышке которую вам дадут. Если же приходит другой предмет то вы ломаете палец, потом руку и умираете от потери крови с криками что это не по описанию что у вас есть.

Автору. Вы взяли какой то очень невнятный пример себе. Образно говоря интерфейс это абстракция.
К примеру у вас есть некая игра. В игре есть транспорт. Вы задаетесь вопросом а какбы сделать так что бы не знать о том что именно это за транспорт но при этом уверенно использовать его.
1) Вы смотрите все свои классы: легковая машина, автобус, самолет, катер, велосипед.
2) У всех классов транспорта можно выделить общие черты. Они могут ехать вперед\назад, рулить влево\вправо, подать сигнал и т.д.
3) Описываете интерфейс с этими выделенными общими методами. Например

interface Transport{
   void gazuem();
   void tormozim();
   void signalim();
...
}

4) Теперь настало время реализовать этот интерфейс. Пример:

public class Avtobus implements Transport{    
    public void gazuem() {
        //реализация особенности как едет автобус
    }
    public void signalim() {
        //тут просто школьный Фа-Фа
    }
}
//Велосипед
public class Velosiped implements Transport{    
    public void gazuem() {
        //реализация особенности как будете крутить педали
    }
    public void signalim() {
        //тут колокольчиком Дзинь-Дзинь
    }
}
//Остальные реализации

5) Абстрагируемся в коде от реализаций конкретных видов транспорта, т.е. работаем с ними как с черной коробкой. Например:

Transport velik = new Velosiped();
Transport avtobus = new Avtobus();
...
Transport samolet = new Samolet();

...
И гдето , например, все виды транспорта попали в коллапс и надо резко посигналить.
velik.signalim(); //Дзинь дзинь
avtobus.signalim(); // Фа-Фа
samolet.signalim();// А тут звуков не будет но вам до лампочки и никаких ошибок не будет
...
//Дальше, например, у игрока есть метод использовать.
//Вам не нужно знать какой именно тип транспорта перед ним, вы просто делаете следующее:
class Player{
...
public void use(Object someObject){
          if(someObject instanceof Transport){
                //Сюда попадет абсолютно любой тип транспорта
                ((Transport)someObject).sadimsya(); //Что там внутри и как оно работает вас уже не интересует
          }
}
...
}

Вот в целом как то так это выглядит.