Alik Elzin

Greenhorn
+ Follow
since Sep 19, 2002
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Alik Elzin

Hey Andrew.

You are right about everything you wrote.

Designing is difficult and fun

What I can say is that first you are very correct when you write interfaces and not classes (implementations).
It is always good to think about objects as interfaces for a whole lot of reasons such as encapsulation, modulation,...

Regarding the specific Animal example:
I think that one should not put a method into an interfaces if the method does not belong to it.
It is logical and will help you not breaking LSP later.
If an Animal interface would have a tail and not all animals that extends it would have a tail, such as humans and bears, how could humans and bears wag the tail ?

If you would like all animals that have a tail (not including humans, bears, ...) to be able to wag their tail, than:
Create an interface that identifies all the animals that have a tail and give some methods to use the tail.
Example:

Interface Tailed extends Animal {
void wagTail();
void raiseTail();
void lowerTail();
}

interface Dog extends Tailed {
// Dog's specific methods
}

class DogImpl implements Dog {
public void wagTail() {
//implementation...
}
//Other methods implementations...
}

Now consider the case of having a collection of animals and you the ones with a tail to wag it.
One solution would be to traverse the animals and for each animal ask if it is Tailed (animal instance of Tailed).
If so, you can cast the animal to Tailed and invoke tailed.wagTail().
This solution is ok but have a big disadvantage of using instance of.
It is a good practice to avoid instance of whenever possible.

Another solution can be to use a visitor.
With a visitor you need to write a bit more code and it needs to know all of the types in compilation type but i think is more strong and more modular.

Usually, one would have at least one method in a base interface, unless it is a markup interface.

Hope this was helpful.
Regards,
Alik.
Hey.

I think it's better in a tree structure for the visitor to traverse itself in the tree rather than the nodes passing their children to the decorator in addition to themselves.
The above is true because you don't always want to visit the children of a node, but rather just the node itself.
If the node passes its children as well, such a case cannot be implemented.

Creating a traversing visitor is very easy to implement because it already knows the structure of the elements it visits.

Than, if you want to reuse the traversing algorithm, just inherit it by your own logic visitor.

Using a traversing visitor (DFS, BFS) encapsulates the iteration logic from the nodes of the tree.

Regards,
Alik.
Look at the following code:

//specific logging visitor
public class ElementVisitorLogger extends VisitorDecorator implements Visitor{

public ElementVisitorLogger(Visitor decorated) {
super(decorated);
}

void visit(ElementSpecificA a) {
write("Visiting element " + a);
getDecorated().visit(a);
write("Finished visiting element " + a);
}

}

public interface Visitor {
void visit(ElementSpecificA a);
//visits to other specific elements...
}

public interface Element {
void accept(Visitor visitor);
}

//specific element
public class ElementSpecificA implements Element {
List<Element> getChildren();
}

//specific visitor
public class TraversingVisitor implements Visitor {
void visit(ElementSpecificA a) {
//do "a"'s logic...

for(Element child : a.getChildren()) {
a.accept(this);
}
}
}

What is written above is logic for logging visitor actions.

We try doing so by decorating a visitor (specifically "TraversingVisitor" but we should not know this - just some Visitor).

But, when the visitor will pass itself further on to child elements, the decoration will vanish.

This is just an example.
I'm sure you saw objects in your past that pass themselves ("this") to methods as a parameter.
The interfaces of such classes cannot be decorated or the decoration will vanish during the program flow.
Hi
You are correct - The "accept" would just need to be written twice -
In the decorated class and in the decorating one (We cannot always inherit this code...).

The bigger problem is that the visitor cannot be decorated.

The general problem is that when a class passes itself (this),
the class cannot be decorated, because the decoration will vanish.

What I'm trying to ask is whether
we should avoid passing "this" ?

If we should avoid passing ourselves on,
people should know that - it is a good practice.
If not, how can we overcome the problem stated here ?

Regards,
Alik.

[ January 11, 2007: Message edited by: Alik Elzin ]
[ January 11, 2007: Message edited by: Alik Elzin ]
Hi all.
I just realized that passing this (myself) to methods
is very dangerous because classes that do that can never be decorated.
Why ?
Consider a case where a class "AImpl" is decorated by class "ADecImpl" (both implementing "A").
"AImpl" passes itself to some method "Temp.temp(A a)".

When "AImpl" passes itself,
the decorated class gets lost and
from now on never used in Temp.temp(
a a).


Specifically, the visitor design pattern is based on passing itself
(in recursion like structures of trees) and
the elements it visits are passing themselves to the visitor.

Thus, whenever I have a visitor, or more generally, a class that passes itself on,
I cannot use decoration on it - not on the visitors and not on the visited.

I c the decorator design pattern as a sort of dynamic inheritance and
suggest that each object in the world be "Decoratable", having 2 methods:
setThis() and getThis().

The problem of this solution is when having TWO decorators to ONE object - which one of them is this ?

What do you think ?
Is there a proper solution to the problem ?

I like the decorator very much because
it helps us design applications using interfaces and not implementations, because
it encapsulates data and for a whole other reasons.

Hope to find solution to the problem....

Regards,
Alik.

[ January 11, 2007: Message edited by: Alik Elzin ]

[ January 11, 2007: Message edited by: Alik Elzin ]
[ January 11, 2007: Message edited by: Alik Elzin ]
Hi.
Try compiling MathFace.java first and then the implementing class.
Interfaces should be compiled as well - contrary to C/C++.

I also recommend using a Java IDE that can simplify the development process, such as IntelliJ, Eclipse, NetBeans...
There is a forum on Java IDEs and tools in Javaranch:
https://coderanch.com/forums/f-12/vc

Regards,
Alik.
17 years ago
Hi,

Threads in Java and OS processes are 2 different things.
One should not even look @ Java threads as OS threads.
Look @ Java threads as internal threads handled by a single Java process - the JVM.
This way platform dependency is taken out - one of Java objectives.

Taken from wikipedia: http://en.wikipedia.org/wiki/Round-robin_scheduling:
"Round-robin is one of the simplest scheduling algorithms for processes in an operating system, which assigns time slices to each process in equal portions and in order, handling all processes without priority"

Java threads have priorities thus executed with consideration to them and not in round robin way.

I think it is wrong to count on thread scheduling for flow correctness and rather use synchronization and locking.

Regards,
Alik.
[ January 09, 2007: Message edited by: Alik Elzin ]
Hi gaurav abbi.

Protected means that only inherited classes can use protected code.

One exception is that a class can use all of it's (private,protected,package,public) code.


Thus, it is not surprising that the first clone compiled correctly ("works fine") - it invokes a protected code but from the same class.

The second line is invoked from ErrorRpt but invokes clone of class SmDrivedClass - that is why you get an error in compilation.

BTW,
If you do not mark a class to be Clonable ("implements Clonable") we will fail on runtime.

Good luck,
Alik.
[ January 08, 2007: Message edited by: Alik Elzin ]
17 years ago
Sorry for not writting this earlier, but I'm using JDK 1.3.1.
The method applyPattern() in JDK 1.3.1 does not throw an exception.
Can you give a way to valid the pattern in JDK 1.3.1 ?
21 years ago
Hi Avi,
I looked at the javadocs on java.text.SimpleDateFormat.applyPattern() and the method is not throwing an exception.
Thanks for the effort.
21 years ago
Hi Rene,
thanks for the advise, but I want to give the user a free hand to choose his format.
21 years ago
I want ot create a new instance of SimpleDateFormat with a pattern, which the user of the program gave. How do I know the pattern, given by the user, is a valid one ?
Thanks.
Alik
21 years ago
Thank you Jessica and Andrew
21 years ago
Hi All.
If I have two same methods in the inner class and in the outer class, such as "String getName()".
How do I invoke the outer class method form within the inner class ?
Thanks.
[ November 20, 2002: Message edited by: Alik Elzin ]
21 years ago
Hi all.
How can I get the platform's default character encoding ?
21 years ago