I apologize in advance if this is a "downvotable" question but I really need help in understanding how to know what to make classes out of in a VBA project.
NOTE: I am not asking how to code a class. I am asking how to determine what to make a class for.
Example
I want to draw shapes on a PowerPoint slide. 2 of the 3 kinds of shapes I need to draw have the same properties and methods. Would I create one class called CShape or 3 classes: CCircle, CSquare, CRectangle? Furthermore, lines are considered shapes in PowerPoint. Should I add a CLine class or just lump everything together in CShape?
I have searched Google for Methodologies on determining classes in VBA and the like but can not find anything. Does anybody out there have a method or way they go about determining how to create classes for their projects (and the reasons behind it)?
Also, I am just getting into classes and interfaces and this is the first project I am using them in. Thanks!
UPDATE
I did find this: When to use a Class in VBA?
When you work with code that can be reusable, this is the perfect time to use classes.
You need to create classes that have procedure to handle errors and possible wrong entries. As much robust you can create your code, your class will work as you expect.
I worked with PowerPoint and build some classes to manipulate document properties, another to manipulate slides, another to resize shapes.
You can find several classes examples from Chip Pearson site and you can figure out how to make your own classes.
http://www.cpearson.com/Downloads/Downloads.aspx
Hope this helps.
VBA (which is almost the same as Visual Basic 6) doesn't support inheritance.
So you have some options, using Interfaces would the normal way to deal with this, so probably three classes each on which implements the IDrawable interface. You may want to have a base class that deals with these features and have the outer classes call down to the base.
IDrawable might have public members for drawing, position, color and penwidth with the other parameters being part of the individual classes.
In particular you should read up on the Liskov substitution principle. I've seen examples of it using rectangles and squares as examples of what not to do.
See this older question for example Is deriving square from rectangle a violation of Liskov's Substitution Principle?
I have been using VBA for over 20 years, and made very little use of class modules.
The most useful cases for me were to build classes representing some structured spreadsheets or complex text files (with logical rows spanning over several physical lines) you may have to query or browse.
You can then implement a .MoveNext method and some properties like .EoF, .Price, .Rate to read them sequentially, being able to reuse that class everywhere you use that specific input file 'layout', and having the complex logic encapsulated in the class.
How efficiently we can apply object oriented-ness, extensability and modularity for simple program? If it is application I can identify Entities and relations between them. When it comes to simple program I am not able to do this.
Please help me in achieving object oriented-ness, extensability and modularity in the Berlin clock program in the link.
http://technologyconversations.com/2014/02/25/java-8-tutorial-through-katas-berlin-clock-easy/
Thanks in Advance.
Here's how I would tackle the problem
object oriented-ness
First of all find out all the entities involved in your problem. Then intepret them as classes. In this case for example the clock is based on different Lights and their inter communication to display actual time.
So I would consider Light as an abstract class and would also inherit different other lights (E.g. RedLight, YelloLight etc) from this abstract Light class and extend them.
Extensability
Always use interfaces rather than directly accessing the classes. In this way you could replace or extend your classes
Modularity
Have your Model (Classes), Business Logic, UI Logic etc separated in different class libraries (or separate projects).
Hope this simple explanation helped.
I am a newbie with Objective C programming.
My first steps to learn Objective C is to read the PDF "Programming with Objective C" from the Apple Developers site.
At the end of every chapter there are exercises to make. Chapter 1 has 4 questions. The first 3 questions are not so dificult to make. But the 4th question I can't figure it out what the anwser is.
The question is:
Add a declaration for a class factory method, called "Person". Don't worry about implementation this method until the next chapter.
I hope that anybody can and will help me.
Thank you
Carlos Wiesemann
Take another look at the section just before the exercises, Objective-C Classes Are also Objects. That section talks about how classes themselves are objects that can have methods separate from the methods that an instance of the class has. When the question asks for a "class factory" method, it means a class method that creates a new instance of that class, just like the string methods in the linked section.
Class method declarations look just like instance methods, except they are prefixed with a plus sign instead of a minus sign. For example,suppose you have a class named Car
let’s add the following class-level method to Car.h:
+ (void)setDefaultModel:(NSString *)aModel;
I have been coding for a year but I've only been introduced and taught in lesson about OOP recently.
I posted a question earlier and somebody said that my program would be a lot better off using a player Class
I was wondering if it is of standard convention to use an object array?
So I need 10 players in my program. Is it okay to have an array of the Class Player with 10 instances? Or is this bad?
Thank you for your time.
It depends on how you plan on using the objects. There is certainly no problem at all creating a array of 10 Player objects. Another option, which may or may not be relevant to your program, could be to create an additional class that contains this array of 10 player instances (maybe call it "Team"?). This would make sense if you want to define methods or members that relate to the 10 players, such as wins/losses, or something of that nature.
Yes, that would be a perfectly valid (and very common) usage.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 12 years ago.
I am trying to understand the core of object oriented programming for php or actionscript proect. As far as I understand, we will have a Main class that control different elements of the project. For example, photoslider class, music control class..etc. I created instance of those classes inside my Main class and use their method or property to control those objects.
I have studied many OOP articles but most of them only talks about inheritance, encapsulation...etc I am not sure if I am right about this and I would appreciate if someone can explain more about it. Thanks!
Same question , i was asking when i were just starting my career but i understood Object Orientation as i progress in my career.
but for very basic startng point in oop.
1- think about object just try to relate your daily household things like ( your laptop, your ipad, your Mobile, your pet)
Step 2-
Try to relate objects like ( Your TV an your remote ) this gives you the basic idea how object should relate to each other.
Step 3-
Try to visulize how things compose to create a full feature like your Body compose of (Heart, Lungs and many other organs)
Step 4-
Try to think about object lifetime ( Like as a example a car enigne is less useful outside Car , so if car is a object than this object must contain a engine and when actual car object destroys engine is also destroyed)
Step 5-
Try to learn about a polymorphism ( Like a ScrewDriver can take may shapes according to your need then map to your objects if your using c# than try to leran about ToString() method overriding)
Step 6 -
Try to create a real life boundry to your real life object ( Like your House ; You secure your house by various means )
this is the initial learning .. read as much as text as you find and try to learn by your own examples
in the last ; oop is an art first , try to visulize it.
my main suggestion is to look at the objects as "smart serfs": each one of these will have memory (the data members) and logic (the member functions).
In my experience, the biggest strength of OOP is the control that you have on the evolution of your design: if your software is remotely useful, it will change, and OOP gives you tools to make the change sustainable. In particular:
a class should change for only one reason, so it must be solve only one problem (SINGLE RESPONSABILITY PRINCIPLE)
changing the behaviour of a class should be made by extending it, not by modifying it (OPEN CLOSED PRINCIPLE)
Focus on interfaces, not on inheritance
Tell, don't ask! Give orders to your objects, do not use them as "data stores"
There are other principles, but I think that these are the ones that must be really understood to succeed in OOP.
I'm not sure I ever understood OOP until I started programming in Ruby but I think I have a reasonable grasp of it now.
It was once explained to me as the components of a car and that helped a lot...
There's such a thing as a Car (the class).
my_car and girlfriends_car are both instances of Car.
my_car has these things that exist called Tyres.
my_car has four instances of Tyres - tyre1, tyre2, tyre3, tyre4
So I have two classes - Car, Tyre
and I have multiple instances of each class.
The Car class has an attribute called Car.colour.
my_car.colour is blue
girlfriends_car is pink
The sticking point for me was understanding the difference between class methods and instance methods.
Instance Methods
An instance method is something like my_car.paint_green. It wouldn't make any sense to call Car.paint_green. Paint what car green? Nope. It has to be girlfriend_car.wrap_around_tree because an instance method has to apply to an instance of that Class.
Class Methods
Say I wanted to build a car? my_new_car = Car.build
I call a Class method because it wouldn't make any sense to call it on an instance? my_car.build? my_car is already built.
Conclusion
If you're struggling to understand OOP then you should make sure that you understand the difference between the Class itself and instances of that Class. Furthermore, you should try to undesrstand the difference between class methods and instance methods. I'd recommend learning some Ruby or Python just so you can get a fuller understanding of OOP withouth the added complicaitons of writing OOP in a non-OOP language.
Great things happen with a true OOP language. In Ruby, EVERYTHING is a class. Even nothing (Nil) is a class. Strings are classes. Numbers are classes and every class is descended from the Object class so you can do neat things like inherit the instance_methods method from Object so String.instance_methods tells you all the instance methods for a string.
Hope that helps!
Kevin.
It seems like you're asking about the procedures or "how-tos" of OOP, not the concepts.
For the how-tos, you're mostly correct: I'm not specifically familiar with PHP or ActionScript, but for those of us in .NET, your program will have some entry point which will take control, and then it will call vairous objects, functions, methods, or whatever- often passing control to other pieces of code- to perform whatever you've decided.
In psuedo-code, it might look something like:
EntryPoint
Initialize (instanciate) a Person
Validate the Person's current properties
Perform some kind of update and/or calculation
provide result to user
Exit
If what you're looking for is the "why" then you're already looking in the right places. The very definitions of the terms Encapsulation, Inheritance, etc. will shed light on why we do OOP.
It's mostly about grouping code that belongs to certain areas together. In non-OOP languages you often have the problem that you can't tell which function is used for what/modifies which structures or functions tend to do too many loosely related things. One work around is to introduce a strict naming scheme (e.g. start every function name with the structure name it's associated with). With OOP, every function is tied to a data structure (the object) and thus makes it easier to organize your code. If you code gets larger/the number of tasks bigger inheritance starts to make a difference.
Good example is a structure representing a shape and a function that returns its center. In non-OOP, that function must distinguish between each structure. That's a problem if you add a new shape. You have to teach your function how to calculate the center for that shape. Now imagine you also had functions to return the circumfence and area and ... Inheritance solves that problem.
Note that you can do OOP programming in non-OOP languages (see for example glib/gtk+ in C) but a "real" OOP language makes it easier and often less error-prone to code in OOP-style. On the other hand, you can mis-use almost every OOP language to write purely imperative code :-) And no language prevents one from writing stupid and inefficient code, but that's another story.
Not sure what sort of answer you're looking for, but I think 10s of 1000s of newly graduated comp sci students will agree: no amount of books and theory is a substitute for practice. In other words, I can explain encapsulation, polymorphism, inheritance at length, but it won't help teach you how to use OO effectively.
No one can tell you how to program. Over time, you'll discover that, no matter how many different projects your working on, you're solving essentially the same problems over and over again. You'll probably ask yourself regularly:
How to represent an object or a process in a meaningful way to the client?
How do I reuse functionality without copy-pasting code?
What actually goes in a class / how fine-grained should classes be?
How do support variations in functionality in a class of objects based on specialization or type?
How do support variations in functionality without rewriting existing code?
How do I structure large applications to make them easy to maintain?
How do I make my code easy to test?
What I'm doing seems really convoluted / hacky, is there an easier way?
Will someone else be able to maintain the code when I'm finished?
Will I be able to maintain the code in 6 months or a year from now?
etc.
There are lots of books on the subject, and they can give you a good head start if you need a little advice. But trust me, time and practice are all you need, and it won't be too long -- maybe 6 or 9 months on a real project -- when OO idioms will be second nature.