Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I have read why to use classes, but I don't understand how it makes my program better?
My example: I made a class called "PanelList" and within it are several subs and a few functions that all use related information that will Arrange panels, resizes panels, and Save/Load information from a database. I access it from my main form using:
dim myObj as new PanelList()
myObj.Gap = 20
myObj.ArrangePanels(Panel1, Panel2)
Why is that better than if I would just do something like this from a module which seems much more condensed and I don't have to create a new instance:
ArrangePanels(Panel1, Panel2, 20)
I would think creating a new instance of an object would take more resources, and if I need to create several objects it starts to make my code look unorganized in my view?
So why would I use my own Objects??
The function you describe in your question isn't really object-oriented, so indeed it doesn't sound like it would make much sense to create an object for it. It's just a helper function that you want to put somewhere.
Objects are exactly that... objects. They are "things" which are described semantically by attributes and operations. For example, you might have a Person object. It's not just a dumping ground for random functions, but rather a discrete instance representing a "person". It has data describing that instance of a person, it has operations that can be performed on or by a person, etc.
If you're not doing any object-oriented programming then, no, you don't really need objects. But if your domain space has discrete semantic concepts of "things" which can be packaged into objects, then it would make sense to do so.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
Is there some authority recommendations what form of prefix should be used for UITableView (UICollectionView) - plural or singular? On example:
UserNamesTableView or UserNameTableView? (table that presents many users), or ObjectsTableView vs ObjectTableView (table presents many objects) etc.
Accordingly: UserNamesTableViewCell or UserNameTableViewCell?
The naming convention should be focused on the object that is defined with the class rather than the objects that can be hold by the class.
So if you name something User it should define an object that is definition of one user.Possibly kind of NSObject.
But if you name something Users you may have defined a Type/Class that can hold Users.Possibly kind of NSArray.
So a UserTableViewController is definition of one table that is meant to address User objects and not Users objects even if it can hold cells which are feed by Users and each shows content of one User.
So with UsersTableViewController i would expect a TableViewController that can mangle multiple users per cell and not one user per cell.
https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/DefiningClasses/DefiningClasses.html#//apple_ref/doc/uid/TP40011210-CH3-SW1
So cause you asked for..
You can anser that allways when asking yourself what is the Object type that is defined and not what objects can be hold by the type.
What do would someone expect is UserTableView handling?
a TableView that handles objects of type User?
or a TableView that handles objects of type Users?
so the answer is quite simple. It would be most logic to use UserTableView.
In general the only rule is that you must not accidentally use a name that might be already in use by the built-in frameworks (because Objective-C has no namespaces). The way to avoid that is never to begin a type name with two prefix capital letters, such as ABThing, as that is what the built-in Cocoa frameworks do.
Starting with a word (so that the second character is a small letter) is generally fine, though in Swift you can never guarantee that you won't clash with an existing name (I see people make the mistake all the time in Swift of calling a type Data or Date, for instance).
Otherwise, no, there are no recommendations or rules; it would all just be a matter of convenience and convention. As a matter of best practices you should probably try to be clear as to what something is, but that's purely a matter of opinion right there.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
Just a litle question about good practices in Object oriented programming.
Let's Image that I have a class like this (pseudo-code) :
class Activity{
construct(duration){
this.duration = duration
}
}
Now I want to define 2 types of Activities : "workTask" and "freeTime". I can imagine 3 possibilities :
Add a property to each instances of my class 'Activity'. Something like "Activity::type"
Inherite twice of the class "Activity" without changing anything exept the type of those classes. One would be "WorkTask" and the other "FreeTime"
Delegate the type assignement. The easier way might be by creating 2 arrays "workTasks" and "freeTimes" and store activities in those arrays.
I actually prefer the last choice but I don't know if it's the recommended way to do that stuff. Are those 3 patterns acceptable (even the second one that is in my opinion the weirder) ? Is there any other good ways to do it ?
Best practices calls for (1) "Add a property to each instances of my class 'Activity'. Something like 'Activity::type'"
This will allow you to:
Put all activities in the same array and still know which are which.
Change the activity type at runtime.
Separate an array of activities into two arrays.
Neither of the other two options is as flexible.
The answer to this kind of question is always "It depends". There are many factors to consider when choosing which approach to use.
If you need to check the type of activities a lot, then 3 is a bad idea, as you need to loop through arrays in order to find out whether a particular activity is a WorkTask or FreeTime.
If WorkTask and FreeTime differs in behaviour/data (e.g. WorkTime could have an extra taskName field or something), then you should use 2. Also note that even if they are the same now, it doesn't mean it will stay this way forever.
Both 1 and 3 will allow you to accidentally assign WorkTasks to variables that are supposed to store FreeTime. This might not be such a big problem in a dynamically-typed language, since you can do this with 2 anyway.
Don't forget that there are a fourth way: Composition
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
Lets say we have a top level object, in a game for example that represents some physical thing in the game world. The top level object then owns several sub-objects, like a bounding box, graphical object, ect. By own I mean that when it dies so should it's sub-objects.
Lets also say there is a graphical manager object that keeps track of all existing graphical objects in order to draw them or something.
Now lets say that top level object leaves the game world, it's destroyed or we load another level, whatever. We can at this point remove it's reference and it will be GCed, however the graphical object it owns still has a reference to it in the graphical manager. So there needs to be some mechanism of informing the graphical manager to remove it's reference to the graphical object. It's this mechanism that I'm asking about.
The best way I can think of is that every object needs a public alive Boolean flag and any other object that doesn't own it but interacts with it and may need to keep a reference to it then needs logic to check for that flag and remove it's references if it's false. But this to me seems like a fairly inelegant solution.
You idea is not only inelegant; it is also the not good OOP. The last thing you want to do is to expose a field of a class; and have outside classes depend on the content of that field.
That is a direct violation of the Tell Don't Ask principle. State should be internal; you do not expose - especially not for the purpose of other objects making decisions based on this state. And of course: most languages do not allow you to synchronize on a field - meaning that this approach scream race conditions all over the place (when different threads are reading/writing to that field). You can mitigate this by making the field volatile (if your language allows for that).
One alternative approach would be to look into the observer pattern. Meaning: the graphical manager registers itself as listener; for example on a central "game manager" - that one component that is actually responsible for adding/removing your game objects. And each time the game manager adds/removes an object, the graphical manager gets notified and can adapt its data structures.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Why did kotlin drop the new keyword ?
It makes it harder to see the difference between a function call and an object allocation.
The Kotlin Coding Conventions clearly state that:
use of camelCase for names (and avoid underscore in names)
types start with upper case
methods and properties start with lower case
If you follow the above and treat constructor as regular function that can be called i.e. val invoice = Invoice() the new keyword becomes redundant.
Once you accommodate yourself with the convention it's clear what a code is doing.
In fact even in Java code you'll have many implicit allocations that happen just beneath a method call like Collections.singleton(o) or Guava's Lists.newArrayList() so I don't think your argument about allocation visibility being better with the new keyword is fully valid.
(IMO) It was done because there is NO real difference between functions and object construction, i.e. nothing prevents a function to allocate an object (and they often do).
A good example is factory functions. These functions create new objects, but they are in no way class constructors.
AFAIK, the new keyword was created because of a negative experience with C\C++, where functions, returning new objects, have to be specially marked (by name conventions) in order not to forget to (manually) free the memory. In a auto-memory-managing language like Java\Kotlin it is not a concern.
Several other languages have no new keyword (Python, Scala, maybe Ceylon) and people who have switched to those languages never seem to miss it. I know I dont.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
This is a probably a very basic question, but it's one I'm actually running into as I'm learning more about Actionscript 3 in particular. However, my first question is very general: When is appropriate to put functionality in a new class rather than a new function in the same class? According to this Java tutorial, which focuses on basic object-oriented principles, a class is supposed to be a "blueprint of an object". I always understood this to mean that any functionality or behavior that the object would use should be contained within the class. However, according to the single responsibility principle, each class should have only one reason to change. For example, you should have one class to compile a report and one class to print it rather than a single Report class.
Can you guys help me understand the pros and cons to creating a new class? What are the costs to splitting an object into multiple classes? Are there compile-time or performance costs for keeping related functionality in the same class, or for splitting it into two? Are there perhaps times that you would want to split things out, while you might want to keep them together other times?
As far as I remember, there isn't a big difference between having 1 class which can do everything or several classes which can do the same.
It's about readability and how you can extend the code. It's also just about clean code and coupling.
If you have a class called "Printer" you don't want to have "WaterCoolerSound()" in it. Of course the more objects you have the higher the chance is that you can run out of memory. But I am not entirely sure whether one object with all functionality or several classes with the same functionality spread out, takes more memory.
In fact, you could say that if you JUST need a little bag to hold on to some data and not be able to dance like a bear at the same time, it would make sense to have two separate classes.
It's advisable not to think about the performance before you have the code. From the maintainability and understandability viewpoint, of course, smaller classes, with smaller methods are superior. (see The Single Responsibility Principle again :)
Don't get so confused about making classes for just a function. A class should have only related functions.If the functions are of different kinds which will do totally different functionalities and use totally different kind of variables then only u should make a separate class.