Site Sponsors:
ClassIO 1.2 Released 
Just a quick note to let everyone know that we just released another version of [ClassIO]. Still a Java tool, but we plan to create one for C# as time permits.

Enjoy,

-Rn


[ view entry ] ( 1700 views )   |  permalink  |  related link
Generic Object Placeholders in Templates 
I am reminded that it is good to remember that we can use templates to take advantage of "isa:" In C# and Java specifically, since all classes are reference types (object pointers), the universal object-placeholder is Object. From a template's point of view, Everything 'isan' Object.

What does having a universal Object for absolutely all classes, mean? -Well, much like using "void *" in C/C++, Java and C#'s Object offers us all of that polymorphic goodness, as well as some sophisticated base operations.

To demonstrate the former, given the following template + interface combination:


public interface OmniAdapter<T> {
// Adapter: Convert one object, to another
Object xForm(T ref);
}


-We can support a simple child 'Object'-conversion:


public class Event3 extends Day2
implements OmniAdapter<Day2> {

public MyNewClass xForm(Day2 ref)
{
return new MyNewClass(ref);
}
}


What is interesting to keep in-mind here is that, because MyNewClass is-an Object, that we can xForm one type, to another. -Even if MyNewClass is only used by a single, solitary function - as long as the compiler can find it - then we can return it.

Enjoy,

-Rn


[ view entry ] ( 2238 views )   |  permalink
C#, C++, and Java: Types, Templates, & Parameterized Factories 

Too Much Knowledge?


For the tenured C++ developer, both C# and Java have their thrills - as well as their chills.

For many, one of the chills can occur when your templates are prematurely inspected by that Java or C# Compiler. While absolutely similar to C++ in many ways, in other ways the C# and Java compilers arguably check templates far too early to ensure that a class member might (or might not) be there!

Templates (aka "parameterized types")


Take for example the need to return a generic object - classically referenced as a generic type T - via a template. While templates are common to C++, Java, and C# (order of plagiarism), there are some very subtle differences in when those me-too compilers allow templates to be applied.

In C++, for example, template implementations are comparatively overlooked until they are required. Ignoring templates until they are used means that while the intention behind:


class MyClass<T> {
...
}


-is clear in all 3 languages, the compile-time realties can be very different, indeed.





How different? Well, the intent to declare a T as our yet-to-be defined class is obvious. But what if we want T to also be used in a certain way? What if we need to be sure that T has a T.read(RandomAccessFile), for example?

Interface Compliance


Upon first blush, one might quite naturally assume that a C# or Java interface can be used. Something like (in Java):


class MyClass<T implements MyCommonStufToDo> {
...
}


Yet, try as we might, at the time of this writing there seems to be no way in either C# or Java to do what - because of a far more relaxed template-checking policy - we can easily do in C++. Namely, insure that our T has implemented a few member functions.

After a few head-scratching moments however, there IS indeed another way to proffer BOTH a reusable template implementation, as well as to assure required operational support, too: Just provide your template with an Object-Factory as a template Interface.

Templates & the Factory Interface



While the C++ way of assuming class-members for a parametrized type is impossible in C# and Java, one great work-around is to leverage a touted feature: The Java & C# need to avoid multiple-inheritance, by using Interfaces. Rather than having MyCommonStufToDo a descendant of T therefore, we simply provide a factory for T where needed:


class MyClass<T> {
public MyClass(MyCommonStufToDo factory) {
this.factory = factory;
}
}


Okay - so let's call providing an interface to use as factory PART ONE. --What did THAT do for us?

Trudging Onward...



Depending upon what we want to do, a parameterized "T factory" can be very handy, indeed! For the purposes of this article, let's assume that we want to read a T from a RandomAccessFile.

In Java, our interface might look like:


public interface iIndexReader<T> {
public T read(RandomAccessFile raf);


Now comes the beautiful part - where using that factory-parameter makes the most sense!

Let's update MyClass to re-use that read member function. To wit:


public T read(long iQuest) {
if (open()) {
long iTally = FileIndex.RecordCount(index);
if (iQuest < iTally) {
IndexLogical logical = new IndexLogical(iQuest);
IndexPayload pay = FileIndex.Read(index, logical);
if (pay.isNull()) {
return null;
}
try {
reader.seek(pay.id);
} catch (IOException ex) {
close();
return null;
}
T result = factory.read(reader);
close();
return result;
}
}
return null;
}


That T result = factory.read(reader); is the important bit. -If you are not familiar with the rest, then feel free to ignore the use of my com.soft9000.dbo file-indexing framework (IndexLogical, etc..)

That factory.read(reader) demonstration nicely completes a succinct pattern for C# and Java. I have found it to be a viable stratagem. One that allows us to have our re-use (templates), strong-type checking (T), as well as a ubiquitous signature guarantee (interface<T>) for a yet-undefined template-type, as well.

Enjoy!

-Rn


p.s. If I have given the reader the impression that C++ template support is superior to those of Java or C#, make no mistake: When it comes time to link-together objects - certainly those that have been compiled between divergent Standard C++ Template libraries - then the tao of the template is an entirely different story! If we do not have the source code, then give us C# or Java over template-laden C++, A-N-Y-T-I-M-E! :)

(Come to think of it, knowing several technologies is far, far, better than knowing just a few. -Knowing the alternatives allows one to avoid the nearsighted language-camps & technology "religious wars." --We are instead free to pick the right tool, for the right job, for the right-reasons! (requirements, anyone?))



[ view entry ] ( 1673 views )   |  permalink  |  related link

<<First <Back | 78 | 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | Next> Last>>