Простое сообщение Java, диспетчеризирующее систему
Другие люди дали вам общий ответ; Вот пара небольших предложений, которые могут оказаться полезными в случае, если вы не можете предпринять более масштабные действия:
- перечислите, от каких библиотек DLL зависит ваше приложение. Если вы точно не знаете, от чего зависит ваше приложение, как вы можете убедиться, что зависимости доступны?
- Напишите утилиту, которая ищет и регистрирует любой экземпляр этих DLL в системе, а также версию DLL и путь к системе. Если у пользователя возникают проблемы, эта утилита может помочь вам решить проблему, поскольку вы упомянули, что у вас нет физического или сетевого доступа к машинам, на которых обнаружена проблема.
- напишите утилиту, которая ничего не делает, кроме
LoadLibrary()ваших зависимостей. Ошибки могут регистрироваться, и, по крайней мере, у вас будет простой способ определить, что не так на компьютере клиента.
Надеемся, что общие проблемы будут выяснены быстро и исправлены, так что они перестанут быть общими, и вам будет все меньше и меньше нужно использовать эти инструменты. Но пока вы не разберетесь с проблемами, они могут оказаться полезными.
Кроме того, в одном комментарии вы упоминаете, что проблема вызвана системными DLL-библиотеками Windows - они, как правило, должны вызывать несколько проблем с «адским DLL» в современных системах, поскольку стороннее программное обеспечение (включая ваше) обычно не может заменить их. Все системы Windows должны получать то, что предоставляет MS, и MS довольно хороша (хотя и не обязательно совершенна) в том, чтобы делать новые обратно совместимыми. Если это вызывает у вас проблемы, возможно, вы захотите опубликовать подробности того, какие библиотеки DLL (и, возможно, версии), чтобы люди могли ответить с более подробной информацией, например, о том, что может потребоваться настроить, чтобы убедиться, что программа установки Windows устанавливает DLL.
3 ответа
Если существует определенный интерфейс слушателя для каждого события. Каждое событие может само вызывать слушателя. Затем роль диспетчера состоит в том, чтобы идентифицировать целевых слушателей и инициировать для них уведомление о событии.
Например, общее определение события может быть:
public interface GameEvent<L> {
public void notify( final L listener);
}
Если ваш CollisionListener:
public interface CollisionListener {
public void spaceshipCollidedWithMeteor( Spaceship spaceship, Meteor meteor );
}
Затем соответствующее событие может быть:
public final class Collision implements GameEvent<CollisionListener> {
private final Spaceship ship;
private final Meteor meteor;
public Collision( final Spaceship aShip, final Meteor aMeteor ) {
this.ship = aShip;
this.meteor = aMeteor;
}
public void notify( final CollisionListener listener) {
listener.spaceshipCollidedWithMeteor( ship, meteor );
}
}
Вы можете представить диспетчера, который может распространять это событие на целевые прослушиватели, как в следующем сценарии (Events - это класс диспетчера):
// A unique dispatcher
final static Events events = new Events();
// Somewhere, an observer is interested by collision events
CollisionListener observer = ...
events.listen( Collision.class, observer );
// there is some moving parts
Spaceship aShip = ...
Meteor aMeteor = ...
// Later they collide => a collision event is notified trough the dispatcher
events.notify( new Collision( aShip, aMeteor ) );
В этом сценарии диспетчеру не требовались какие-либо знания о события и слушатели. Он запускает индивидуальное уведомление о событии для каждого слушателя, используя только интерфейс GameEvent. Каждая пара событие / слушатель выбирает свои собственные режимы диалога (они могут обмениваться множеством сообщений, если захотят). время (без возможной ошибки),
If you want to avoid instanceof, then your only bet is to use inheritance to route a method call to the right method. You cannot use method overloading, since that is decided at compile time by the declared type of the variable you are passing to a method. You have to use inheritance.
If you cannot use inheritance, then your only other choice (that I'm aware of) involves a lot of instanceof.
Regarding a messaging system, you can use ActiveMQ as an in-the-JVM message transport. You do not have to use it via socket or other means. I can't imagine that ActiveMQ would not be efficient enough for your means.
У Java-бинов должен был быть такой интерфейс: он упрощает жизнь.
interface PropertyChangeProvider {
void addPropertyChangeListener(PropertyChangeListener l);
void addPropertyChangeListener(String property, PropertyChangeListener l);
void removePropertyChangeListener(PropertyChangeListener l);
void removePropertyChangeListener(String property, PropertyChangeListener l);
}
Реализуйте его повсюду.
Создайте класс доски (возможно, одноэлементный. Это только набросок) )
public class Blackboard implements PropertyChangeListener,PropertyChangeProvider {
static Blackboard getInstance(){
// implement this
}
void initialise(){
// start the thread here
}
void republish(){
// this can save you heartache too.
}
}
Создайте ветку Blackboard, прислушайтесь к событиям и повторно опубликуйте ее, используя собственную ветку.
Классы могут просто публиковать свои события на доске.
Подпишитесь на классную доску для событий.
Если хотите, можете сохранять события, разрешать повторную публикацию и т. д.
Для чего-то внутри приложения это очень хорошо. (работает так же хорошо, как и интерфейс обмена данными!)