yap, saya kira semuanya sudah memahami konsep OOP dan saya sangat setuju dgn artikel "VB as an Object-Oriented Programming" dimana disitu sdh cukup jelas dikatakan jika vb dibandingkan dgn C tentunya sangat berbeda. Karena secara basicly tujuan developnya berbeda. Kalau C memang di develop utk Cross Multiplatform sedangkan visual basic sendiri memang dirancang utk OS Windows.
OOP di VB secara langsung bukan merupakan basis bahasa yg utama, jadi OOP di VB itu sendiri menggunakan feature dari windows.Contohnya : ActiveX Regard's Rudi Harsono --- In [email protected], "ahmad syaukani" <asauk...@...> wrote: > > Memang VB bukanlah language yang sepenuhnya mendukung tetapi bukan berarti > tidak bisa melakukannya, berikut sedikit bahan bacaan tentang OOP di VB yang > saya ambil dari 'Advance VB6" terbitan Microsoft Press > kalau ada yang berminat file lengkapnya silahkan japri > ---------------------- > 56. Stuff About Objects, Types, and Data Structures > Code reuse is mostly about object orientationthe effective packaging of > components to suit some plan or design. This section examines the mechanisms > that exist in Visual Basic to effectively bring about code reuse. In > particular, we'll look at how we can extend the type system in Visual Basic. > 56.1 Visual Basic as an Object-Oriented Language > People often say that Visual Basic is not properly object oriented. I would > answer that if you were comparing it with C++, you're both right and wrong. > Yes, it isn't C++; it's Visual Basic! > C++ is a generic, cross-platform programming language designed around a > particular programming paradigm that is, subjectively, object oriented. It is > based on and influenced by other programming languages such as Simula, C, and > C with Objects2. > Visual Basic has evolvedand has been influenced, tooaccording to system > considerations, not primarily to different languages. It was designed to be > platform specific; there's not an implementation for the VAX computer, for > example. Visual Basic's object orientation, then, is not primarily language > based. Its object-oriented language constructs are not there to implement > object orientation directly but rather to best utilize the object-oriented > features of the operating systemin Windows, of course, this means ActiveX. > ActiveX itself, however, is not a language definition but a systems-level > object technology built directly into a specific range of operating systems. > It is not subject to committees either, although you might consider this to > be a negative point. Additionally, I think I'd call ActiveX and Visual Basic > "commercial," whereas I'd probably call C++ "academic." I have nothing > against C++ or any other programming language. Indeed, I'm a proponent of > mixed-language programming and use C++ almost daily. What I am against, > however, is a comparison of Visual Basic with C++. These two languages are as > different as COBOL and FORTRAN, and both were designed to solve different > problems and to cater to different markets. This all said, I'm still keen to > model the world realistically in terms of objects, and I also want to > encourage both high cohesion and loose coupling between and within those > objects. (Here's a quick tip for the latter: Use ByValit helps!) Whether or > not I achieve this cohesion and coupling with Visual Basic and ActiveX is the > real question. > 56.1.1 Cohesion and coupling > cohesion and coupling. A component is said to be cohesive if it exhibits a > high degree of functional relatedness with other related components. These > related components (routines typically) should form cohesive program units > (modules and classes). Every routine in a module should, for example, be > essential for that module to accomplish its purpose. Generally, there are > seven recognized levels of cohesion (none of which I'll cover here). Coupling > is an indication of the strength of the interconnections and interactions > exhibited by different program components. If components are strongly > coupled, they obviously have a dependency on each otherneither can typically > work without the other, and if you break one of the components, you'll > invariably break the others that are dependent upon it. In Visual Basic, > tight coupling typically comes about through the overuse and sharing of > public symbols (variables, constants, properties, and routines exported by > other units). > 56.1.2 What are your intentions? > Having an object implies intention; that is, you're about to do something > with the object. This intention should, in turn, define the object's behavior > and its interfaces. Indeed, a strong type system implies that you know what > you'll do with an object when you acquire one. After all, you know what you > can do with a hammer when you pick one up! A sense of encapsulation, > identity, and meaning is an obvious requirement. To add both external and > procedural meaning to an object, you need to be able to add desirable > qualities such as methods and properties. What does all this boil down to in > Visual Basic? The class, the interface, and the object variable. > Classes are essentially Visual Basic's way of wrapping both method, which is > ideally the interface, and statethat is, providing real type extensions (or > as good as it gets currently). A real type is more than a description of mere > data (state); it also describes the set of operations that can be applied to > that state (method). Unfortunately, methods are currently nonsymbolic. One > feature that C++ has that I'd love to have in Visual Basic is the ability to > define symbolic methods that relate directly to a set of operators. With this > ability, I could, for example, define what it means to literally add a > deposit to an account using the addition operator (+). After all, the plus > sign is already overloaded (defined for) in Visual Basic. For example the > String type supports addition. Also, a solution will have nothing to do with > ActiveX; the ability to define symbolic methods is a mere language feature. > 56.1.3 Visual Basic "inheritance" > Visual Basic lacks an inheritance mechanism (definitely more of an ActiveX > constraint) that is comparable with that of C++. To reuse another object's > properties in Visual Basic, you must use something elseeither composition or > association (composition meaning aggregationlike in a UDT; association > meaning, in Visual Basic-speak, an object reference). Historically, > association is "late" compositionas a result it also invalidates strong > typing. A Visual Basic object cannot, in the C++ sense, be a superclass of > another type. In other words, you cannot describe a PC, say, as being either > a specialization of or composed of a CPU. > NOTE > ________________________________________ > By the way, C++ type inheritance is often used badly; that is, an object that > inherits from other objects exports their public interfaces. The result is > that top-level objects are often bloated because they are the sum of all the > public interfaces of the objects they are derived froma sort of > overprivileged and overfed upper class! > Components that are highly cohesive, yet loosely coupled, are more easily > sharedif code reuse is an issue, consider rigorously promoting both of these > simple philosophies. > 56.1.4 Object polymorphism > Polymorphism is a characteristic by which an object is able to respond to > stimuli in accordance with its underlying object type rather than in > accordance with the type of reference used to apply the stimulus. The > Implements statement, discussed in the next section, is Visual Basic's way of > extending polymorphic types beyond that allowed by the Object type. > Polymorphic types might be assigned (or "set") to point to and use one > another, and they're useful when you know that one type has the same > interface as another type (one you'd like to treat it as). The really > important thing is that with polymorphism, an object responds according to > its type rather than the type of reference you have to it. > Let me give you an example using two constructs that are probably familiar to > you, the Object type and a window handle. > What is the result of this code? > > Dim o As Object > > Set o = frmMainForm > > MsgBox o.Caption > You can see here that the Caption property evaluation is applied to what the > pointer/object reference o points to rather than according to what > Object.Caption means. That is, that object to which we bind the Caption > access to is decided in the context of what o is set to when o.Caption is > executed. (We call this behavior late binding, by the way.) Notice that the > code doesn't error with a message that says, "The Object class doesn't > support this property or method." Polymorphism says that an object responds > as the type of object it is rather than according to the type of the > reference we have to it. Again, notice that I didn't have to cast the > reference, (using a fabricated cast operator that you might take at first > glance to be an array index), like this one, for instance: > CForm(o).Caption > The object o knows what it is (currently) and responds accordingly. > Obviously, we can alter what o points to: > > Dim o As Object > If blnUseForm = True Then > Set o = frmMainForm > Else > Set o = cmdMainButton > End If > MsgBox o.Caption > Again, o.Caption works in either case because of polymorphism. > The second example is a window handle. This window handle is something like > the object reference we used above, meaning it's basically a pointer that's > bound to an object at run time. The object, of course, is a Windows' windowa > data structure maintained by the operating system, an abstract type. You can > treat an hWnd in a more consistent fashion than you can something declared As > Object, however. Basically you can apply any method call to hWnd and it'll be > safe. You're right in thinking that windows are sent messages, but the > message value denotes some action in the underlying hWnd. Therefore, we can > think of a call to SendMessage not as sending a window a message but rather > as invoking some method, meaning that we can treat SendMessage(Me.hWnd, > WM_NULL, 0, 0) as something like hWnd.WM_NULL 0, 0. The WM_NULL (a message > you're not meant to respond to) is the method name, and the 0, 0 are the > method's parameters. All totally polymorphican hWnd value is a particular > window and it will respond accordingly. > Another similarity between the window handle and the Object type is that a > window is truly an abstract type (meaning that you cannot create one without > being specific), and so is the Object type. You can declare something As > Object though now it seems what I've just said is not truebut what you've > done, in fact, is not create an Object instance but an instance of a pointer > to any specific object (an uninitialized object reference). It's like > defining a void pointer in C. The pointer has potential to point somewhere > but has no implementation and therefore no sense in itself. It's only > meaningful when it's actually pointing to something! > I hope you can see that polymorphism is great for extending the type system > and for being able to treat objects generically while having them respond > according to what they actually are. Treating objects as generically as > possible is good; specialize only when you really need to. > OK, so what's the catch? Well, the problem with As-Object polymorphism is > that it isn't typesafe. What would happen in my earlier example if, once I'd > set o to point to the cmdMainButton command button, I tried to access the > WindowState property instead of the Caption property? We'd get an error, > obviously, and that's bad news all around. What we really need is a more > typesafe version of Object, with which we can be more certain about what we > might find at the other end of an object reference (but at the same time > keeping the polymorphic behavior that we all want). Enter Implements. > 56.1.5 Using Implements > The Implements statement provides a form of interface inheritance. A class > that uses the Implements statement inherits the interface that follows the > Implements keyword but not, by some magic, an implementation of that > interface. A class is free to define code for the inherited interface > methods, or the class can choose to leave the interface methods as blank > stubs. On the other side of the Implements equation, we can define an > interface that other classes can inherit but have nothing to do with a > particular implementation. > When you inherit an interface by using the Implements statement, you're > providing methods and properties with certain names on an object. Now, when > your containing class is initialized, it should create a suitable > implementation of these promised methods and properties. This can happen in > one of two ways: > 1. Pass method and property invocations on to the underlying > implementation (by creating and maintaining a local copy of an object that > actually implements the methods and properties). This mechanism is often > called forwarding. > 2. Handle the invocation entirely by itself. > How does this differ from As-Object polymorphism? Basically, when you set a > typed object reference to point to an object, the object instance to which > you set it must implement the interfaces specified by the type of the object > reference you use in the declaration. This adds an element of type safety to > the dynamic typecast, which is what you're implicitly doing, of course. > When you choose not to implement an interface other than by forwarding > requests to the underlying base type (the thing you've said you implement) > you can get these problems: > 1. The derived class now acts like a base classyou've just provided a > pass-through mechanism. > 2. The base object reference is made public in the derived class (by > accident), and because you cannot declare Const references, the reference to > your implementation might be reassigned. (Actually, it's just as easy to do > this via composition in Visual Basic.) > A consequence of the second problem is that you can accidentally "negate" the > reference to the base object. Say, for argument's sake, that you set it to > point to a Form; clearly the derived class no longer implements a base but a > Form. Better hope your method names are different in a base and a Form or > you're in for a surprise! > It's important to realize that Implements can be used with forwarding or via > composition. The only difference in Visual Basic is the keyword Newin fact, > it's even grayer than that. In class Derived, does the following code mean > we're using forwarding or composition? > Implements Base > > Private o As New Base > Do we contain a Base object or do we simply have a variable reference to a > Base instance? Yes, it's the latter. In Visual Basic you cannot compose an > object from others because you cannot really define an objectonly an object > reference. > Let me summarize this statement and the meaning of Implements. When you're > given an object reference you have to consider two types: the type of the > reference and the type of the object referenced (the "reference" and the > "referent"). Implements ensures that the type of the referent must be "at > least as derived as" the type of the reference. In other words, if a Set > works, you have at least a reference type referent object attached to the > reference. This leads us to the following guarantee: If the class of the > reference has the indicated method or property > (Reference_Type.Reference_Method), then the object referencethe > referentwill have it, too. > 56.1.6 Delegating objects > Delegating objects consists of two parts. Part one deals with who > respondsthrough my interface I might get an actual implementor of the > interface (the object type I have said that I implement) to respond (possibly > before I respond), or I might elect to generate the whole response entirely > by myself. Part two deals with who is responsible for an object; this is used > in conjunction with association. Two containers might deal with a single > provider object at various times. This use of association raises the question > of object ownership (which container should clean up the object, reinitialize > and repair it, and so forth). > Object orientation is modeling the requirements. Defining the requirements > therefore dictates the object model and implementation method you'll employ. > You can build effective sets of objects in Visual Basic, but you cannot do > today all of what is possible in C++. As I said earlier, Visual Basic and C++ > are two different languages, and you should learn to adapt to and utilize the > strengths of each as appropriate. > ------- > semoga membantu > untuk codenya mungkin bisa dicari di sourceforge atau lainnya > > ahmad > > --- In [email protected], "Aiska" <aiska_hendra@> wrote: > > > > Mungkin saya luruskan sedikit, VB6 itu bukanlah Pemmogramman Berbasis > > Object (OOP). memang beberapa konsep OOP telah di Implementasikan oleh > > VB6, tapi tidak semua, namun ada juga yang mengatakan bahwa VB6 itu > > separuh OOP, tapi yang jelas bukan OOP > > > > Sebenarnya VB6 tidak mendukung Inheritance, tapi beberapa programmer > > telah melakukan trik agar di VB6 bisa dilakukan Inheritance. > > > > buat mas bram mungkin saya koreksi dan luruskan sedikit biar ngga > > bingung. Suatu program dikatakan object-oriented programming (OOP) > > adalah jika memenuhi semua konsep OOP, jadi sebagian atau salah satu > > saja tidak terpenuhi maka belum bisa dikatakan OOP. > > > > OOP memang agak sulit untuk dipelajari, tapi ketika anda sudah memahami > > konsep OOP anda tidak akan kesulitan jika harus menangani sebuah project > > besar, begitu pula sebaliknya. > > > > Maaf klo ada yang tersinggung dengan tulisan saya, dan semoga tulisan > > saya bisa mencerahkan bagi yang membaca > > Terima Kasih. > > > > CMIIWW > > > > FYI : > > > > klo anda mau belajar mengenai trik inheritance bisa di liat di > > http://msdn.microsoft.com/en-us/library/aa260821(VS.60).aspx > > <http://msdn.microsoft.com/en-us/library/aa260821%28VS.60%29.aspx> > > > > untuk penjelasan mengenai OOP bisa diliat di > > http://id.wikipedia.org/wiki/Pemrograman_berorientasi_objek > > <http://id.wikipedia.org/wiki/Pemrograman_berorientasi_objek> > > > > Best Regard, > > > > Aiska Hendra > > > > --- In [email protected], "r.harsono" <binapusat@> wrote: > > > > > > mungkin ada yang pernah tau nggak membuat object class di VB. Object > > class yang kita buat tersebut dapat diturunkan pada modul2 kita di > > sebuah project atau project lainnya. Kalau mau lebih jelas lagi anda > > bisa pelajari aplikasi sederhana TimeBillingUI yg bisa dicari di sitenya > > VBCode, ini bukan snippet Code namun aplikasi sederhana yang > > mengimplementasikan konsep OOP di VB. Dan menurut saya ini sebuah contoh > > yang sangat bagus dalam mempelajari konsep OOP di VB, namun kalau memang > > mau belajar konsep arsitektur OOP yg sangat bagus adalah di Java > > language > > > > > > Selamat melakukan explorasi... > > > > > > --- In [email protected], Bram AK j3j4k4_bdg@ wrote: > > > > > > > > > > > > > > > > Setau saya suatu program di katakan program berorientasi obyek (OOP) > > jika Salah satu inti dari OOP adalah inheritance(suatu obyek diturunkan > > menjadi obyek baru) terpenuhi.. > > > > Mungkin di antara rekan2 ada yg tau bagaimana cara menurunkan suatu > > object baru pada VB 6 > > > > > > > > > > > > Terima kasih > > > > > > > > Orang Tua Groups IT Team > > > > > > > > ________________________________ > > > > Kunjungi halaman depan Yahoo! Indonesia yang baru! > > > > > > > > > > > > Terhubung langsung dengan banyak teman di blog dan situs > > pribadi Anda? Buat Pingbox terbaru Anda sekarang! > > http://id.messenger.yahoo.com/pingbox/ > > > > > > > > [Non-text portions of this message have been removed] > > > > > > > > > > > > > > > [Non-text portions of this message have been removed] > > >
