Re: Question to Interfaces/Objectcatalogue


"Peter" <Peter@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:481A62CD-FA73-4975-8C6D-8466723E3136@xxxxxxxxxxxxxxxx
> We assume, that our VB6-Project has reached the maximum numbers of Public
> members (the "Not enough Memory" Problem).
>
> We have an ActiveX-DLL, with many classes and every class exports a lot of
> Members. The classes are used in the Database-Layer and the code is
completly
> generated with a tool. This tool creates for every Table and View in the
> Database a CodeModule in the ActiveX-DLL.
>
> Many Members in these Classes has identical signatures (exact 29 Members).
> The Implementation is different - of course.
> e.g.: Clear(), Save(), Load(), IsModified(), ...
>
> Our Idea is now to write an Interface "IBaseTable", which contains all
these
> Members. The Classes implements the interface and offers only a Member
"Base":
>
> ...
> Implements IBaseTable
>
> Public Property Base() As IBaseTable
> Set Base = Me
> End Property
> ...
>
> Converting the existing code would be much more easier with this Member
"Base"
>
> ---------------------
> And now the question:
> We have 414 classes in the DLL. Every Class contains 29 "identical"
Members.
> Therefore we cut down the Public Members at (414-1) x 29 = 11977 Members!
>
> Is this a correct Bill?
> What do you think?
>
>
> Thanks in advance for answers and suggestions,
>
> Peter.

I am sure I don't understand exactly why you are getting "memory problems",
but it is not directly related to too many public members. It is however
related in the sense that your design in general, which resulted in so many
public members, is conducive to producing memory problems.

Merely reducing the number of members in the default interface isn't going
to make a substantive change. You still have to implement the additional
interfaces. In this case you will just be changing the signatures. (The code
and addresses will all be there just the same.) Interface Inheritance is a
technique to support polymorphism. It can simplify 'coding', but does
nothing to change size. Your objects will still be bloated.

Unfortunately, the original design is architecturally flawed from the
beginning and using a 'code generator' merely exacerbated the problem. How
can I make such a pompous remark? Simple. Because I have been there and done
that. <g>

This is not the forum for getting into detailed design technologies, but the
following might help provide a clue and an impetus to seek out some good
data access design books and articles.

There are multiple ways for an OO design to 'interface' to a relational
database - to over-come the impedance mismatch between the two worlds. One
size does not not fit all. Your strategy to 'mirror' the tables and views
with objects is merely providing a layer of indirection which leads to
procedural code disguised with an OOPL wrapper. While useful for some
isolated tasks, it is seldom an appropriate solution for most applications.
It scales poorly (your at 414 and probably still counting), leads to vast
numbers of amazingly bloated objects (memory problems), and quickly becomes
a maintenance nightmare if you have frequent changes to the presentation or
the database.

At this point, there is little you can do, 'code-wise', with your 414
objects to improve the situation.

-ralph




.

Relevant Pages

  • Re: weird problem
    ... Obviously plus a few missing members like prev, ... 'tmp' has for a relation to it - 'tmp' could point to an element ... it fails to obtain as much memory as requested. ... print out a human-readable string for what errno is set to. ...
    (comp.lang.c)
  • Re: how to allocate memory to a member dynamically
    ... int age; ... for all members memory is allocated. ... age only if sex is M else the memory should not allocate. ...
    (comp.lang.c)
  • Re: Need More ADO Suggestions
    ... It may be that the chances you'll run out of memory are exceedingly low, but to suggest GC prevents us from doing so makes no sense. ... No one can ever make you a rock-solid guarantee that these things won't happen, but if we just talk about what the GC has control over and we talk about that managed code written by someone with a basic understanding of object memory allocation, we do find that the GC protects us from running out of memory by cleaning the heap when memory resources begin to get low. ... I just don't understand your assertion that to investigate the members of a class to determine what the available members are and get a basic understanding of what those members do is counter to any OOP principle. ... You said that the GC cannot protect us from running out of memory, which is incorrect. ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: Methods within many instantiated classes?
    ... > Suppose I have a class with a bunch of members and methods. ... > will be instantiated many many times at once in memory. ... > wise and memory consumption wise, which method would be best to design the ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Instance Vs Static Methods and Memory Usage
    ... memory is allocated for the data members ... The "this" pointer points to the this data so the code only exists in ... > How does a static member or property differ concerning memory usage in the ...
    (microsoft.public.dotnet.languages.csharp)
Loading