Tag Archives: software-design

Software Design: Feature based design on class

This is about when to create a class: for a new feature instead of a new object concept
For example, an enemy for a combat game. Instead of making a class for an enemy, we should make a class for a feature/skill/behavior of enemy. Enemy should be a “data structure” instead of “controller”.

// Wrong practice:
class EnemyA : Enemy {
    public void throwFireBall() {...}  // it is hard to share this
                                       // with other enemy

// Correct practice:
class Enemy {
    string name; //name = "EnemyA"
    List<EnemyBehavior> behaviors;
class EBThrowFireBall : EnemyBehavior { //EB stands for EnemyBehavior
    public override void someEnemyMessage() {
        //throw fire ball

Therefore different enemies can share same behavior with different settings and combination.

The key to make this decision is all about concept: enemy is a combination of behavior, and the behavior sharing between enemies are expected.

Android is plugin unfriendly

As I worked for mobile app almost 2 years, I conclude that Android is not a good platform for plugin development, comparing to iOS platform. I always feel painful to integrate any plugin for Android apps. Here are some reasons why.

Manifest.xml vs info.plist

Manifest file just does too much then a configuration file. Every activity/service and permission requirement in Android app have to register itself in it, which causes many plugins to modify this file. By the design pattern of Android SDK, many plugins cannot avoid to do so.

More than one plugins modifying the same file turns out the plugin users to do that manually, which increase the chance of careless mistake and the effort to manage them, or the users will do a template for several plugins, but it is still complicated if there are too many.

In my opinion, I don’t see any point for such registration on Manifest XML. To protect end-user? They won’t care about it. To protect app developer from third-party developer? No it can protect nothing. It would be perfect if Manifest XML does exactly what info.plist does. At least it should be application oriented, but not module oriented. There should be another automatic system to detect and conclude the combined activity/service and permission requirement.

Message in Activity

Such as onActivityResult, must be listened by an Activity, and there is only one active activity at the same time normally. It also causes different plugins trying to modify the only activity class.

Android View Parameter

All parameters of an Android View, such as position, width and height and etc, are stored in a ViewParam, which is an instance of one of the ViewParam classes, depending on the parent view of it. which causes a dependency of plugin component to external component.

Many plugins developer (mostly in iOS) implement a help method to create a view for users, so that the view could be added to the custom view made by the plugin users and it’s done. However, the view parameter cannot be pre-made as the plugin developer don’t know what is the parent view they are using. The plugin users have to hard code the parameters themselves, and have to update that if the view is updated.

May be it’s not fair to compare an old designed Cocoa Framework with a really new Java framework, and Google is so busy about catching up the visual design against iOS. For now a plugin management for Android should be a good idea to be invented.