Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
Simply put, is it a good idea to name collections and composite objects using plurality?
class PandaBears {
PandaBear[] bears;
class PandaBear {
}
}
My concern is that the class names are quite similar. On the other hand, PandaBearList reveals the implementation, but is more easily distinguishable.
I would prefer PandaBearCollection. A class name that is a countable noun just agrees better with the fundamental metaphor of OOP, an "object".
For example, try describing the signature of the following two functions:
void func(PandaBearCollection collection1, PandaBearCollection collection2);
void func(PandaBears pandaBears1, PandaBears pandaBears2);
The first one would naturally be: "A function that takes two collections of panda bears".
What would be the second one? "A function that takes two panda bears"? No, it just doesn't work.
I would avoid plurality.
If you don't want to include the suffix List, you could always use the suffix Collection which is a standard convention and does not reveal the implementation details. Of course this depends on the language you are using.
There is also a C#-specific work-around which I like to use if the structure is not very complex. You can avoid creating the Collection class at all, by declaring all the methods as extension methods of the related IEnumerable<T>. So, in this case, you could declare extension methods on IEnumerable<PandaBear>, provided that your collection does not have other private variables.
I prefer using plurality because as you mention it does not indicate the implementation, which could easily change in the future. Another consideration on the naming convention is if you are using an ORM and what type of convention will it use when translating your database schema, as discussed here. You will probably get a lot of advice both ways. I think what is more important is that you pick a convention that works for you and your team and you stick with it.
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 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 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
I've learned C/C++, Python, Matlab and many other language, but I was really surprised by the long method name in objective-c.
What's the advantage of using long name?
Why no other language use long name?
Thanks a lot.
It is something like code convention. Usually it is very useful.
But you can name your methods as you want. Also notice that it is not strongly required to name all parameters. For example you can create method
- (void)makeDateFromDay:(int)day month:(int)month year:(int)year
and call this way
[someObject makeDateFromDay:18 month:2 year:2014];
but you also can name it shorter
- (void)makeDateFrom:(int)day :(int)month :(int)year
and call like this
[someObject makeDateFrom:18:2:2014];
But it is not so readable, yes?
The plain answer is that the long method names are self-descriptive. (And since each argument is introduced through another method name part, the method name gets even longer.) The advantage is that the code reads really easily, and thanks to code completion there is no extra penalty for typing the whole thing by hand.
More methods are longer, more they speak themselves.
If you consider delegate method, in the method there is also the references
to class from the method being called because it can be very userfull to make some
kind of operation on class that conforms to protocol.
If you suppose to have an app where you have to do a lot of calc, like a shop application,
you can't declare all methods with the same name (for example sum) because when you have more than two methods with the same name you start to lose control on your code.
A lot of programmers using short syntax like name vars as:
a, b
But when you open code some months later you have to reconstruct the logic of program to know what a certain var does.
Give a long name to methods can be also usefull when you work in team to be more safe on method name replication.
Obj-C method names closely respect a convention with more rules than other languages. For example the last word of the method name is the name of the first argument.
- (id)valueForRow:(int)row Column:(int)column
In C++ this would probably be:
void getValue(int row, int column)
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.
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 6 years ago.
Improve this question
I'm trying to figure out the best way to register my C++ Classes constructors with Lua (from a software design perspective, not a coding perspective)
How shall I do this ?
My Ideas:
1) Make some kind of "init Lua bindings" file which binds each of the C++ constructors that I want to have available in Lua ? (problem: this file would tend to get bigger and bigger and difficult to sync/debug)
2) Each class is responsable to register it's own constructor with my "LuaManager" Class
(problem: it would be stupid to bind the same constructor to Lua over and over again for the same Class of kind A, so ideally, each kind of scriptable Class should bind it's constructor with Lua only Once when using this approach.)
Ideas, or opinions are very welcome.
I understand what you mean by asking
from a software design perspective,
not a coding perspective
however I'm not sure there's clear distinction between the two. Or, more correctly, the coding approach you take will determine your design options. For example, if you use SWIG, the options in your question don't really make sense, since you write a separate "interface" file. If you are using luabind, the options do make sense, but I would definitely choose 1) in that case as luabind headers slow compilation dramatically and I'd like to have them included in as few compilation units as possible. If your "coding" approach doesn't have that luabind shortcoming then 2) seems like the more sensible thing to do.
Your second approach will work well. One way to avoid multiple registrations is to use a static initialization list approach. Each class would add a Lua registration function to a static std::set pre-main. Then you'd walk this std::set when your application starts and add each class constructor binding to your Lua runtime. This would ensure your class bindings are registered only once.