Java - Using Generics or Inheritance -


i have interface, resource, supposed wrap something , expose few operations on wrapped object.
first approach write following, strategy pattern in mind.

interface resource<t> {     resourcestate read();     void write(resourcestate); }  abstract class abstractresource<t> implements resource<t> {     // strategy comes in.     protected abstractresource(resourcestrategy<t> strat) {         // ...     }      // both read , write implementations delegate strategy. }  class exclusiveresource<t> extends abstractresource<t> { ... } class shareableresource<t> extends abstractresource<t> { ... } 

the 2 implementations above differ in locking scheme used (regular locks, or read-write locks).

there resourcemanager, entity responsible managing these things. idea of usage client, be:

resourcemanager rm = ... mycustomobject o = ... mycustomreadwritestrategy strat = ... rm.newresourcefor(o, "id", strat); 

this way, client know resources, wouldn't have deal directly resources (hence package-private classes). also, make own implementation of common resources, sockets, , client ask them (ie, have write socketstrategy implements resourcestrategy<socket>).

resourcemanager rm = ... rm.newsocketresource("id", host, port); 

to access resources, request handler manager. due each thread having specific access privileges, , manager create handler appropriate access privileges.

// in resourcemanager class. public resourcehandler gethandlerfor(string id) {     if (!canthreadusethisresource(id)) throw ...;     if (isthreadreaderonly()) {          return new resourcereadhandler( ... );     } else {          return new resourcewritehandler( ... );     } } 

this problem kicks in.
approach seems clean , clear me, seems intuitive user. but, hinted, manager keeps mapping identifiers resources. how declared, , how manager retrieve resources map?

map<string, resource<?>> map; // can go around without specific cast? not sure yet. resource<?> r = map.get(id); // have enum resourcetype, check if thread has privileges // specific type. 

is design acceptable, and/or following practices?


alternatively, wipe out generics, , have exclusiveresource , shareableresource abstract , public.
these classes extended, both me , client, every type of resource needed (fileresource extends exclusiveresource, socketresource extends exclusiveresource, ...).
eliminate need strategy pattern, expose more of package user.

which of these alternatives correct, or accepted practice?


edit: after thought, think able remove generic resource interface, since that's 1 causing trouble, , leave on abstractresource , subclasses. latter still grant me compile-time verification of strategies used.

public <t> void newexclusiveresourcefor(         t obj, string id, resourcestrategy<t> strat) {     exclusiveresource<t> r = new exclusiveresource<>(obj, strat);     map.put(id, r); } 

however, following inheritance way seems more correct.

as suggested dkaustubh , paul bellora, stands, there no plausible justification generic in resource interface. had gone unnoticed me, @ first, since wanted implementations generic, assumed interface should generic. that's not case.

i still have 2 options here.

using generics

i should remove generic in interface. then, end following.

interface resource {     resourcestate read();     void write(resourcestate);     void dispose(); }  abstract class abstractresource<t> implements resource {     /* strategy comes in.      * generic ensures compile-time verification of      * strategy's type. */     protected abstractresource(resourcestrategy<t> strat) {         // ...     }      // both read , write implementations delegate strategy. }  class exclusiveresource<t> extends abstractresource<t> { ... } class shareableresource<t> extends abstractresource<t> { ... }  // behaviour client implements, custom resources. public abstract class resourcestrategy<t> {     public abstract resourcestate read(t obj);     public abstract void write(resourcestate state);     public abstract void dispose(t obj); } 

only resourcehandler, resourcemanager, resourcestate , resourcestrategy need public, client.


using inheritance

using inheritance, can achieve same results, trade-offs.

public interface resource {     resourcestate read();     void write(resourcestate);     void dispose(); }  /* these implement locking schemes. */ abstract class exclusiveresource implements resource { ... } abstract class shareableresource implements resource { ... }  /* user extends these custom content , behaviour. */ public abstract class customexclusiveresource         extends exclusiveresource { ... } public abstract class customshareableresource         extends shareableresource { ... } 

resources public client.


conclusions

  1. there ways misuse resources both approaches, bypassing expected contracts , thread permissions. both approaches equal here.

  2. with generics, inner representation of resources need not known client, since manager creates resources in background. inheritance, resource creation takes place on client side, manager's api change accept provided resources.

  3. even though resources not public, using generics, client needs know strategies. inheritance, these gone, , public status assigned resources instead.

  4. with strategies, behaviour can changed in runtime, or there different behaviours same kind of resource. without them, client needs dispose of resource, , them re-create using subclass implements different behaviour.
    e.g.: small files can read memory, while large files may require appropriately sized buffer.

unless else missing, may matter of choice, , thinking desired api , use cases.


Comments

Popular posts from this blog

Perl - how to grep a block of text from a file -

delphi - How to remove all the grips on a coolbar if I have several coolbands? -

javascript - Animating array of divs; only the final element is modified -