I'm writing a setup routine with several configuration parameters (for now, could be int, double, or String). In order to avoid long method signatures, I'd like to create a data structure to store these parameters. The main setup routine calls several methods/factories, each with their own set of required parameters, and I'd like to only pass the relevant piece of the data structure to each routine.
My initial thought was to use some kind of recursive/tree dictionary-like structure, where String keys could be associated with either a value, or a subtree that behaves exactly like the top-level tree.
A rough example of what I'm trying to do follows:
public class A {
// some common methods here
}
public class A1 extends A {
public A1(int x, double y) {
// do stuff
}
}
public class A2 extends A {
public A2(double z) {
// do stuff
}
}
public A SetupA(ConfigOptions opts) {
if (opts.get("typeA").equals("A1")) {
return SetupA1(opts.get("A1opts"));
} else {
return SetupA2(opts.get("A2opts"));
}
}
public A1 SetupA1(ConfigOptions A1opts) {
return new A1(A1opts.get("x"), A1opts.get("y"));
}
public A2 SetupA2(ConfigOptions A2opts) {
return new A2(A2opts.get("z"));
}
When I fill the ConfigOptions structure, I'd like to have a character, e.g. :, that separates levels of the tree. I.e. for the example above, I could specify that I want an A2 object with z = 1.0 something like this:
opts.set("typeA", "A2");
opts.set("A2opts:z", 1.0);
I know that what I've just laid out won't work as written since it's not type-safe. What modifications to the interface, and/or what implementation techniques could I consider that would allow me to accomplish my objectives?
Notes:
The setup routine has a relatively small one-time cost. Therefore readability and a convenient interface is a much higher priority for me than speed.
This is a learning project for me, so I'm looking for a solution that doesn't depend on external libraries or built-in collection classes.
Error checking does not need to be considered by the data structure, since it will be handled by the routines that receive the parameters.
Related
I want to create a class of objects to compare to each other, without using values to compare them with. Is there a library in Java which is able to provide this functionality for me? In terms of ordering, the most frequently mentioned library is Comparator, but all the examples I have seen so far use some kinds of value from the objects in order to perform this ordering with.
For example, I want to be able to say that within a class of objects that:
Object A is more important than Object B.
Object B is more important than Object C.
Therefore, I want the library to be able to perform some kind of analysis, and to be able to order the items according to these values, and say to me, that the order of the values above are A, B, C, in that order.
Is there a library which is able to do this in Java?
Are you thinking of something like this?
enum Importance {
High,
Medium,
Low;
}
class Thing implements Comparable<Thing> {
private Importance importance = Importance.Medium;
public Importance getImportance() {
return importance;
}
public void setImportance(Importance importance) {
this.importance = importance;
}
#Override
public int compareTo(Thing o) {
return importance.compareTo(o.importance);
}
}
Alternatively - if you want to control the relativity of each object then record that in a Map. You will need to be careful to tightly control the map to ensure there are no cycles - if there is then your sorting will become unstable.
static Map<Thing, Set<Thing>> moreImportant = new HashMap<>();
class Thing implements Comparable<Thing> {
#Override
public int compareTo(Thing o) {
Set<Thing> more = moreImportant.get(this);
return more == null ? 0 : more.contains(o) ? 1 : -1;
}
}
I tried googling and searching for this question but somehow couldn't find anything relevant about it. I'm wondering if there is a bbest-practise guide on when to use attributes in a class and when not, but rather use parameters to the single methods.
Many cases are clear to me, e.g.
public class Dog
{
private name;
public setName(...) {....}
}
But sometimes it's not clear to me what's better to use.
E.g. the following, either use:
public class calculation
XYZ bla;
public calculation(XYZ something)
{
this.bla = something;
}
public void calc1()
{
// some calculations with this.bla
}
public void calc1()
{
// some more calculations with this.bla
}
public XYZ getBla()
{
return this.bla;
}
}
or maybe do:
public class calculation
public calculation() {}
public static XYZ calc1(XYZ bla) // maybe static, if not dependant on other attributes/instance-variables etc
{
// some calculations with bla
return bla;
}
public static XYZ calc1() // maybe static, if not dependant on other attributes/instance-variables etc
{
// some more calculations with bla
return bla;
}
}
I mean you can argue for both cases. I see advantages and maybe disadvantages for both different styles, but somehow I prefer the second one as far as long as there are not too many arguments/parameters needed. Sure, if I need many many more attributes etc., then the first one will be better, simpler etc. because I dont need to pass so many parameters to the method...
Just a question of personal style?
Or how to decide for one approach?
Thanks
EDIT: A better example: I'm curently doing much image processing and the question would be wether to store the image internally in the state of the object or not. I'm currently NOT doing it because I'm using static methods, and psasing the image itself I to each method:
public class ImageProcessing
{
/**
*
*/
public static Mat cannyEdges(Mat I, int low, int high)
{
// ...
return I;
}
public static Mat cannyEdges(Mat I)
{
return ImageProcessing.cannyEdges(I, ContourDetection.CANNY_LOWTHRES, ContourDetection.CANNY_HIGHTHRES);
}
/**
*
*/
public static Mat getHoughLines(Mat Edges, ...some_conf_vars...)
{
// ...
return I;
}
}
and then I'm calling it from the outside like this e.g.:
// here: read image to I...
Mat edges = ImageProcessing.cannyEdges(I, 20, 100);
Mat lines = ImageProcessing.getHoughLines(I);
// draw lines...
question is: Does I belong to the state of the object? Would it make sense to convert to non-static and then use for example:
// here: read image to I...
ImageProcessing IP = new ImageProcessing(I);
IP.cannyEdges(20, 100); // CHANGE OF cannyEdges: Also save `edges` internally as property!?
IP.calcHoughLines(); // also save the lines internally maybe?
Mat lines = IP.getLines();
// draw lines...
is this nicer?
The question arising is then again: Should I for example store the result of getHoughLines() (i.e. the lines) internally or should I directly return it to the caller!?
I can use some examples:
public class Multiplier {
private int number;
public Multiplier(int number) {
this.number = number;
}
public int multiply(int other) {
return number * other;
}
}
This class could be instantiated like:
Multiplier multiplyByTwo = new Multiplier(2);
I could use it to multiply many elements on a list by 2.
But I could need to multiply pairs of numbers. So the following class could be what I neeed:
public class Multiplier {
public static int multiply(int number, int other) {
return number * other;
}
}
I could make it static since no state is needed.
This example could be used like this on a list:
for (int x:listOfInts) {
print(Multiplier.multiply(x * 2));
}
But probably in this specific case the 1st example was nicer.
for (int x:listOfInts) {
print(multiplyByTwo(x));
}
or even nicer used with a Java 8 ''map''
If I need to get the elements of the multiplication and the result at many points in my code i could do.
class Multiplier {
private int x;
private int y;
public int multiply() {
return x * y;
}
// getters and setters for x and y
}
In this last case I may consider not adding setters and pass x, y in the constructor.
Every structure could be used in some specific cases.
It's not entirely a question of personal style. But nevertheless, I assume that this topic might be slightly controversial (opinion-based) and thus not perfectly suited for a Q/A-site.
However, the obvious question is: Does an object of the respective class really carry a state? That is, is there any benefit in having the state represented by an instance? If the sole purpose of the instance is to be an accumulator of variables that are modified with a sequence of set... calls and a final call to an execute() method, then there is usually no real justification for such an instance - except for avoiding to have a static method with "many" parameters.
I think that the advantages of static methods outweigh most of the potential clumsiness of calling a method with "many" parameters. One of the most important ones is probably that the approach with static methods doesn't increase the state space. Every field is another dimension in the state space, and documenting state space properly can be hard. Static methods enforce a more "functional" programming style: They don't have any side-effects, and thus, are thread-safe (which is becoming increasingly important).
(Note: All this refers to static methods that are not related to any static state - that should be avoided anyhow. And of course, this refers to methods that are not involved in or aiming at anything related to polymorphism).
And after all, one can easily call any static method from anywhere - even from within an instance method, and pass in some fields as parameters. The opposite is not so easy: When you want to call a method that depends on many instance fields, it can be a hassle when you first have to create an object and set the fields appropriately (still not knowing whether it is in a valid state to call the method). I also see the default methods of Java 8 as a nice application case where static utility methods come in handy: The default method may easily delegate to the utility method, because no state is involved.
There are a few reasons I'd go with the first option, i.e. an object with state over static functions, particularly for complex calculations but also for simpler ones.
Objects work better for the command pattern.
Objects work better for the strategy pattern.
Static methods can turn unit tests into a nightmare.
Static is an anti-pattern in OOP because it breaks polymorphism, with the side-effect that related techniques will break with it, e.g. open/closed, mocking, proxies, etc.
That's my 2c at least.
The weird part of your first example is that those calcX methods don't say anything about idempotency, so it's unclear what this.bla is when it's being manipulated. For complex computations with optional settings, an alternative is to construct an immutable object using a builder pattern, and then offer calcX methods that return the result based on fixed object state and parameters. But the applicability of that really depends on the use case, so YMMV.
Update: With your new code, a more OOP approach would be to decorate Mat. Favouring delegation over inheritance, you'd get something like
public class MyMat
{
private Mat i;
public MyMat(Mat i) {
this.i = i;
}
public Mat getBackingMat() {
return this.i;
}
public MyMat cannyEdges(int low, int high)
{
// ...
return new MyMat(I); // lets you chain operations
}
public MyMat cannyEdges()
{
return new MyMat(ImageProcessing.cannyEdges(I, ContourDetection.CANNY_LOWTHRES, ContourDetection.CANNY_HIGHTHRES));
}
public MyMat getHoughLines(...some_conf_vars...)
{
// ...
}
}
MyMat myMat = new MyMat(I);
lines = myMat.cannyEdges(20, 100).calcHoughLines();
This is just a guess, cause I have no idea what those things mean. :)
When not to use static:
If the result that will be returned is dependent on other variables (state) that make up your "calculation" class then static cannot be used.
However, if you are simply doing calculations on a variable, as the example implies, static is probably the way to go as it requires less code (For example to perform calc1 and then calc2 on a variable by the first method you would have to do:
calculation calc = new calculation(x)
calc.calc1();
calc.calc2();
XYZ y = calc.getBla();
while with the second example you could do
static import ...calculation.*;
...
XYZ y = calc2(calc1(x));
I am trying to parse a binary file format with nested structures. In procedural pseudo-code, the process would be as such:
// A structure contains:
// tag | oneof(a, b, c) | oneof(oneof(aa, ab, ac), oneof(ba, bb, bc), oneof(ca, cb, cc))
PROCEDURE parse() {
RECORD read_type;
read_tag(read_type);
if (read_type == TYPE_A) {
read_a(read_type);
if (read_type == TYPE_AA) {
read_aa();
} else if (read_type == TYPE_AB) {
read_ab();
} else if (read_type == TYPE_AC) {
read_ac();
}
} else if (read_type == TYPE_B) {
// see above
} else if (read_type == TYPE_C) {
// see above
}
}
An outer structure such as AA can not be interpreted without context from its parent object A, which in turn requires its tag/header to interpret. When working with these structures, it makes sense to manipulate structures that contain A, that contain AA, etc., but never only the A or AA portion of a structure.
My question is then how to create a class model for this procedure. Should the structure be:
class Base;
class A: Base;
class B: Base;
class C: Base;
class AA: A;
class AB: A;
class AC: A;
// ...
In which case, AA might be constructed as such:
AA::AA(): A() {
read_aa();
}
A::A(): Base() {
read_a();
}
Base::Base() {
read_tag();
}
However, the issue would be that it would not be possible to know what derived object to construct without first constructing the base object. This could be worked around by having a constructor AA::AA(A*) that copy constructs its parent, but this seems like an unnecessary inefficiency. Further, this would require an external factory function such as:
Base *read_object() {
Base *base = new Base();
if (b->tag_type == TYPE_A) {
A *a = new A(base);
if (a->tag_type == TYPE_AA) {
return new AA(a);
} else if (a->tag_type == TYPE_AB) {
// ...
} else if (a->tag_type == TYPE_AC) {
// ...
}
} else if (b->tag_type == TYPE_B) {
// ...
} else if (b->tag_type == TYPE_C) {
// ...
}
}
The other option is to have classes that refer to sub-regions of the structure such as:
class CompleteStructure;
class StructureA;
class StructureB;
class StructureC;
class StructureAA;
class StructureAB;
class StructureAC;
// ...
class CompleteStructure {
union {StructureA a, StructureB b, StructureC c} sub;
}
class StructureA {
CompleteStructure *parent;
union {StructureAA aa, StructureAB ab, StructureAC ac} sub;
}
class StructureAA {
StructureA *parent;
}
In this case, the constructor CompleteStructure::CompleteStructure() would read the tag and then construct one of StructureA, StructureB, or StructureC, which would in turn construct is own sub-structure. The issue with this is that each sub-structure would need an explicit reference to its parent in order to "cast" up the hierarchy and implement its methods/functions.
Is one of these approaches better than the other in terms of space/time efficiency and "cleanness"? Is there a superior third approach?
EDIT:
To respond to the two answers below, the question is both about parsing and object behavior. My initial goal is merely to read the structures from the file, print out their fields, and then write them back to disk in the same order. Later on, there will be additional goals such as finding all instances of A-derived structures and sorting them by certain fields or checking for illegal combinations of structures (e.g. having both BA and BB).
EDIT2:
Here is an example schema of one of the structures I refer to (with generic field names). u8/16/32 refer to integer types, sz is a C string, upper-case names are fields that need to be read, and constants are prefixed with underscores.
DEF AA {
// Identifies and deliminates complete records.
TAG {
u32 SYNC_CODE = 0xFFFFFFFF;
}
// Metadata for high level identification of data.
A {
u32 TYPE = __TYPE_A;
u16 CATEGORY = __CATEGORY_1; // A defines the "category" of the following file data
u32 NUM_OF_KV_PAIRS;
for (int i = 0; i < NUM_OF_KV_PAIRS; ++i) { // unspecified metadata
sz KEY;
sz VALUE;
}
u8 HAS_EXTENSION_FLAG = true; // indicates presence of next record
if (!HAS_EXTENSION_FLAG) {
DEFAULT_PARAMS; // legacy
}
}
// Indicates a specific data layout and version.
AA {
u32 TYPE = __TYPE_AA;
u8[16] ACCESS_KEY;
u32 NUM_OFFSETS;
for (int i = 0; i < NUM_OFFSETS; ++i) {
// stuff
}
}
}
It is difficult to answer if some approach is better in terms of effeciency without a more concrete problem description. Below you can find some food for thought.
Point 1: When thinking about class design it worths to also examine the desired behaviour and not just the data. The fact that the binary format used for storage, may or may not imply a hierarchy, should be taken into account of course, but it should not be the primary concern.
As an example, assume we have a Person class that has a height field and a Rectangle class that also has a height field. They both share some data but having only this information makes them rather irrelevant to each other. If we define the context and we say we want to draw them on the screen then suddenly the height field has a more specific meaning. Now inheriting a Drawable perhaps makes more sense.
The question in your case is how we will use them? What common operations can we do if we have a list of {A, B} or {AA, BB} or even {A, BB}? Can we somehow manage them together? This is an important point that you should take into account.
Point 2: You say that "it makes sense to manipulate structures that contain A, that contain AA, etc, but never only the A or AA portion of a structure". So I understand that AA is-a A, but that the opposite is also true. If this is the case, then it makes sense to have Base, A, B, C as abstract classes and only be able to instatiate directly the last level AA, BB etc.
Point 3: On the other hand it might be better to use composition over inheritance if the different structures just define some data and not some behaviour. E.g. will we invoke a method on them like process() that would operate on the data? Or do we want to use the structures themselves as data?
class X {
Base base;
A a;
AA aa;
process() {
// this is different than calling base.process() + a.process() + aa.process()
// do we need one over the other? both?
process(base) + process(a) + process(aa);
}
}
Point 4: Regarding the order of instantiation while reading, this should not be a problem. Perhaps you could read the information as you go storing it temporarily and only instantiate a class after you know its full type (i.e. you reach the last level).
I hope that helps
The question doesn't clearly explain what you think you are doing, or what the actual problem is (ie. what you should be doing).
You need to very clearly define which of A, AA, AB are entities with their own distinct existence -- and where are the child relationships which you're supposedly parsing. You say nested structure but don't detail it.
As another answer mentioned -- OO is about behaviour, not about data modelling.
Leaning heavily on inheritance, especially since you don't know what you're constructing, sound like it would be a complete mistake. Inheritance heirarchies in general are only useful when you need behavior (methods that calculate or do things) & can efficiently divide that behavior-space by some class heirarchy and benefit from that.
Your problem as stated above, is just a parsing problem. You could as well use a Stack and some internal state (say a StringBuilder, at the most trivial) to read & build up parsing-state while using the Stack to push & pop nesting levels.
In fact, the above is a great way to implement most kinds of parsers.
A more-sophisticated alternative (also common in parsers) is to build an AST. These are very efficient & light-weight to build & traverse.
class AstNode {
protected AstNode down; // first child.
protected AstNode across; // next sibling.
public void addChild (AstNode child) {
if (getDown() == null) {
// First Child;
this.down = child;
return;
}
// Sibling to existing Children.
AstNode last = down;
while (last.getAcross() != null)
last = last.getAcross();
last.across = child;
// done.
}
}
With an AST, you can also put properties/ members on for NodeType, Data, Type (lexical) etc and effectively build a powerful data-structure in its own right.
Hope this helps.
I'm receiving from a webservice a list of key-value pairs, and have inherited the following code:
public String iconValue = null;
... (over 50 class variables assigned in MyObject constructor below)
public MyObject(List<Attribute> attrs) {
String attrName, attrValue;
for (Attribute a : attrs) {
try
{
attrName = a.getName();
attrValue = a.getValue();
if (attrValue == null || "".equals(attrValue.trim()))
continue;
if (ICONS.equals(attrName)) {
//Do something including assignment
this.iconValue = attrValue;
}
else if (URL.equals(attrName))
{
//Do something including assignment
}
else if (...) A giant list of over 50 different attributes hardcoded
{
//Do something including assignment
}
...
So,except for keeping a hashmap - is there a better way than the above to keep hard coded variables within the class and use this "when-if" pattern.
Also,does this pattern have a name?
One way I can think about is to use ENUMs and dynamically dispatch the works to each of the ENUM object, instead of doing a huge if else, esp. since ENUMs can be looked up by their names.
That would be like a strategy pattern.
For example:
Implement an ENUM to have a method doJob() for each of the instances;
Use the valueOf() method to dispatch the works.
Code sample:
public enum Strategies {
URL {
#Override
public void doJob(MyObject mo) {
// do the work
}
},
ICONS {
#Override
public void doJob(MyObject mo) {
// another work
}
};
public abstract void doJob(MyObject mo);
}
And when using it,
try {
Strategies.valueOf(attrName).doJob();
} catch (IllegalArgumentException e) {
// ENUM does not exist, illegal parameter
}
If you want to take a different action for each possible value of attribute, you will end up with something about that verbose, I'm afraid. Some improvements though:
If you are using Java7 or above, you can now use switch statements with Strings (link)
If you are not, you could create an Enum that has a static method that returns an Enum element you could switch on. It's no performance improvement, but it might help with readability of your code.
Does this pattern have a name?
Nope.
In Java 7 you can express that as:
switch (attrName) {
case ICONS:
//Do something including assignment
break;
case URL:
//Do something including assignment
break;
// and so on
}
... provided that ICONS, URL and the other strings are compile-time constants.
That is more concise and more robust. It is also (probably) more efficient because the switch can most likely be implemented using hashing.
I don't think it has a name, but you could call it "using polymorphism wrong" (if type safety is a concern). It depends on whether you have a well defined data contract or not. Is the data you're receiving a proper object, or just "random" data?
If it's a proper object I would create a concrete representation and use something like Dozer (or if you don't want to be tied down wit dependency, roll your own mapper using reflection) to convert between them.
If it's more or less random data, I'd just use a Map, or similar data structure.
I am trying to do a very simple command line library for interactive Java programs. You start the Java program and it prompts you for commands. The syntax is:
> action [object_1, [object_2, [... object_n] ... ]]
for example:
> addUser name "John Doe" age 42
Here action = "addUser", object_1 = "name", object_2 = "John Doe", object_3 = "age", object_4 = "42".
Everything after action is an object (that is, an action uses objects). You can see that the action and the object are simple strings. Object strings can also be converted to numbers if necessary.
My plan is that the user of this command line library would simply create methods (belonging to any suitable Java object) and assign each method to a specific action. The objects in the command line become parameters for the method the user assigns. A suitable class that implements a method for the example above would be:
class Foo {
public void addUserHandler(
String param1, String param2, String param3, Integer param4) {
do.someThing();
}
}
When a user types a command, the corresponding function assigned by the programmer gets called with the parameters specified in the command line.
I know that Java doesn't have function pointers (like C) or delegates (like C#) and the way to implement callbacks is through an interface, however, I don't see how can I use interfaces in this scenario. The problem I see with interfaces is that they have:
A fixed number of functions to be implemented
The functions to be implemented have a fixed declaration.
The problem with (1) is that the user of my library may decide to implement any number of functions, for as many actions as he wants to support. The problem with (2) is that the user would want to assign functions with descriptive names, like addUserHandler() for "addUSer" action.
If Java had delegates or function pointers I would just create a Map between Strings (representing actions) and delegates (for the actual implementation of the action in the program). I think I can emulate delegates with Reflection, but it is gory and I lose the type safety, as I'd have to use String names for classes and methods. Is there any better way?
Thanks,
If you want the user to get automagic type translation (e.g. from strings to ints), then reflection is the only way. if you make the user do the work, then you don't need reflection (and you get type safety):
your command interface:
public interface MyCommand {
public void execute(String[] args);
}
an implementation:
public class MyObj {
public void doSomething(String param1, Integer param2) {
}
private void register() {
mainApp.registerCommand("doSomething", new MyCommand() {
#Override public void execute(String[] args) {
doSomething(args[0], Integer.parseInt(args[1]));
}});
}
}
Kudos to you for the sheer awesomeness of this question. You're pretty much up against the limits of what Java can do. (Though, of course, delegating like you describe would be a breeze in any functional language.)
First of all, limitation #2 should not be an issue. As of 1.5, Java no longer restricts you to fixed declarations in methods. You can use an ellipsis to indicate a variable number of arguments, like so
public static double average( double... numbers ) {
double total = 0.0;
for (double d : numbers) {
total += d;
}
return total / numbers.length;
}
I'm not entirely sure how to get around limitation #1, but I'm thinking about something with generics and/or anonymous inner classes. I'm guessing here -- I haven't tried doing this myself -- but you could create a map of function names and delegate classes like so:
public interface Callback {...}
public interface AddUserCallBack extends Callback {...}
public class UserImpl<T extends Callback> {
public T getDelegateRoutine();
...
}
Generics in Java have some hair-pulling frustrations associated with them, primarily due to type erasure. You may need to juggle both interfaces and abstract base classes before you get it to do what you want. But something like this should work for you.
The reflective solution is not so bad. You can do something like (syntax may not be 100%, Java is not my best language and I've no compiler here):
interface Action {
public void Apply(object[] args);
}
class AddUser implements Action {
Type[] argTypes;
public AddUser() {
argTypes = {String, String, String, Integer};
}
public void Apply(object[] args) {
// Now interpret args based on the contents of argTypes, and do your thing.
// The map would look like "adduser" => new AddUser()
// and could be invoked as map["adduser"].Apply(args)
}
}
But as rtperson said, you are running up against some fundamental limits of Java. Almost any other modern language would serve you better.