REAL programmers don't like these luxuries.

Clifford Nelson wrote:

I would have looked forward to JavaScript and HTML dying.

What is wrong with these technologies? They enabled you to be here.

BobJanova wrote:

I don't understand what the problem with allowing users to create instances of their classes directly is. (Users in this case meaning users of the framework; that could well be you as well.)

Last month I developed a Microsoft Exchange Server wrapper component. Interfaces will expose methods and there is a wrapper class to resolve the implementation using an IOC container. That was for an old version of exchange server. I uploaded the code to the code database. Few days later the Exchange Server upgraded and there was a requirement to implement the new API. So I created new classes for the newer version and also changed the wrapper class to register new classes with IOC container. But some developers from other projects directly access the classes of old version so that they lost the new changes. As you said I can advise them to follow this discipline. But I feel it is a burden for me. I have to spend my precious time to watch them. Hope you understand my situation.

jschell wrote:

Those are feel good subjective terms, especially the first two.
One can create code using interfaces that meet none of those.

So you think dependency injection does not solve these issues?

jschell wrote:

Not everything needs interfaces and there is very seldom a need to "protect" code from users. In a very large number of cases code that is using other code will always directly create other classes, because it is expedient and no other requirements exist.

Though I agree with you that not all the code are need not protected, still i have to implement interfaces in core areas. This is because the reason to implement interfaces is to develop extendable, maintainable and testable code.

jschell wrote:

However to solve a 'creation' problem one uses a Factory Pattern. This of course supposes that there is a problem in the first place.

I didnt get this. Can you please explain it?

There are two problems for MonoDroid. 1) It is commercial. 2) It is complex(Framework on the top of another framework.)

dalvikvm.com[^]

Quote:

It is optimized for low memory requirements, and is designed to allow multiple VM instances to run at once, relying on the underlying operating system for process isolation, memory management and threading support. Dalvik is often referred to as a Java Virtual Machine, but this is not strictly accurate, as the bytecode on which it operates is not Java bytecode. Instead, a tool named dx, included in the Android SDK, transforms the Java Class files of Java classes compiled by a regular Java compiler into another class file format (the .dex format).

Recently I fell in love with dependency injection and interface based programming. Though, as a beginner, I couldn’t grasp all the advantages of this methodology, I greatly influenced in the discipline we can bring into the project to handle the army of objects. What I learned that by using interface based programming, components are expose their functionalities only though an interface. At first I designed as like below.

namespace Component1
{
public interface Interface1
{
void Func();
}

public class Class1 : Interface1
{
    public void Func() { }
}

public static class IOContainer
{
    public static void Register() { }

    public static TInterface Resolve() { }
}

}

One drawback I found here that someone can directly create objects of Class1 and use its functions. This will break the essence of interface based programming. So I redesigned it like below.

namespace Component1
{
public interface Interface1
{
void Func();
}

internal class Class1 : Interface1
{
    public void Func() { }
}

public static class IOContainer
{
    internal static void Register() { }

    public static void Register()
    {
        Register();
    }

    public static TInterface Resolve() { }
}

}

This will work fine. So no one can access the implementations from outside the assembly. They have to call Register function and Resolve function to create objects. The component will use only in one discipline. But I fell I lost flexibility. Outsider can't determine which class should resolve at run time. Both methods have their own advantages and disadvantages. Kindly help me to choose a suitable method. Thanks in advance, Thomas

Mycroft Holmes wrote:

be thankfull you have some work around

I thank god for not make me as a 'PLZ GV ME CODZ' programmer ;)

jschell wrote:

It is a "basic" requirement for GUIs. Which is no more relevant to a database than the color that you use to display the results.

I agree. I was just worrying about the overkill of fetching entrie table. Think about TOP{no of records}. Can the pagination implement like this? Oky, I am not ignoring the additional overhead to calculate the 'current page' on Sql Server.

jschell wrote:

The 'best' solution is to require your users to provide enough information that you don't need to page at all. Users do NOT use large lists in a random fashion. They know what they are looking for so make them tell you that.

This is not pratical in many situations. Consider a shopping web site which have a statergy is to force the customer to buy products even though they really dont require it. The customer may doesnt have idea what they want and like to surf through available items.

Hi All, Every time I do paging on database results, I feel wonder why there is no native commands to do paging on Sql queries. Pagination is a basic requirement to fetch data from large tables. All I can do that to fetch entire data into a temporary result set like temporary table or CTE and apply paging into that result set. But why I have to fetch entire table to get 20 or 30 records? I know there is a better alternative for this is that to select only primary key fields instead of entire columns and use the primary keys to create the page. But still I have to select entire table at first. Is there any better solution for this? Thanks in advance. Regards, Thomas

There are a number of aspects we should consider to judge a good code. Unfortunately these are really vague and relative to the situation

public int Add(int num1, int num2)
{
return num1 + num2;
}

public int Add(int num1, int num2)
{
return num1 + num2 - 0;
}

Both code will work as it designed for. But which one is the best code?

Thanks for your reply. All the day I was trying to find a solution on google. I concluded with the solution to use a service locator. By the way, several people mentioned that service locator is an anti-pattern. I think it is true in some sense. What do you think about it? Thanks, Thomas

In my recent project, I am trying to implement the dependency injection. This project implements with three tire architecture. One layer is to access database, second one is to manage business logic and last one is for the UI. Suppose there is a class "Customer" in data layer which implements the "ICustomer" interface for necessary data operations related to the customer. In the business layer, there is another "Customer" class for implement the business logic for the customer entity. This class has an "ICustomer" type property to inject the customer data layer class. Now my question is, from where I should inject this data objects to business objects? To do this, I have following solutions. 1. Construct the business object and inject the data object from UI layer. But I feel it is ugly because I have to access data layer from UI layer to do this. 2. Create something like factory pattern from business layer to extract business objects with injected data objects. So factory pattern is the correct design pattern for this? If so, how can I implement it? Is there any other method to do this? Thanks, Thomas