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 5 years ago.
Improve this question
Hey,
If my application is called "Media Player", is it a best practice to name classes: MPSong, MPSinger, MPAlbumsViewController ... ?
Apple's Coding Guidelines for Cocoa has lots of advice along these lines.
In short, using a prefix for class and protocol names is encouraged, especially if you're developing a framework. However, Apple already uses the MP prefix for its MediaPlayer framework on the iPhone, so you probably want to pick another.
All capital two-letter prefixes are reserved by Apple, so you shouldn’t use those. But otherwise there is no definite answer to this question - it’s a matter of personal taste. I personally use a prefix for library classes but not for application classes.
I don't know if the way I name classes is a best practice or not, but if I have a class that is unique to the project I just give it a meaningful name and start with a capital letter. However if it is a class that I intend to reuse I may give it a prefix like the initials of my company or myself so I see the class is meant for reuse.
Another reason for a prefix would be if you have the same name because of similar titling in the same project but have different functionality and run the risk of becoming confusing. For example if you decide to make a class called state as in the state in which you live. Then you wish to create a class called state meaning the current state of you application. It would be a good idea to use a prefix like ADState and APState (AD for address and AP for application). In other frameworks they have namespaces that do the same job.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 6 years ago.
Improve this question
If I have many classes which are pretty similar with each other then, does making them inherit from an abstract class a good option?
Only if they are a true abstraction in the Dog is an Animal kind of sense. Stuff on your abstract classes must make sense to all derived.
Otherwise you risk using your base class to sort of import an API. Although you see some frameworks do this, without deliberate design you are usually better off extracting the commonality out to shared dependencies which all the classes commonly use.
Abstract classes that no client code directly references or uses is typically a sign you may be running off track.
Absolutely. Though I would use an interface/protocol where possible. They're more flexible, as they give you the freedom to inherit another class.
The best choice depends on the nature of your classes, and what their duplicated code is.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I'm currently developing a school project and we are instructed that we are required to implement Object-Oriented Programming concepts in our software. But I don't want to implement it just by simply inheriting this class to that class and overriding this method to implement its own functionality and so on. Though it is still acceptable but I want to do it differently. By differently, I mean by using design patterns. I'm trying to understand it one by one and I noticed that some of them are very useful(Builder, Memento and Adapter). But the problem is there are so many of them and if possible I want to put/implement it all(those 3 design pattern). Is it okay if I do that? Would it mess up the project as a whole?
As always: It depends.
Overusage of patterns on small and simple bits of code can obscure the code. But it can also make it more clear.
Don't use patterns wherever possible. Use them when it serves a purpose. Every pattern has its purpose and if you can't find that purpose in your code, you shouldn't rewrite it to match a pattern. Try to keep your code a) maintainable and b) easy to read. If a pattern fulfills these criteria more than your approach without patterns: go for it.
You can have code with dozens of patterns and code with none. In both cases it can be the ideal choice.
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 8 years ago.
Improve this question
What do you prefer to use and what is the best practice - to make long but very meaningful names or to make shorter ones?
For example, if you are writing a class House, will be
int numberOfRooms;
or
int nRooms;
Sure, long names are better for understandig when you read foreign code or give yours to somebody, but they make code longer -> more complicated to read. So I messed up with it. :)
One of the most important things is understanding code.
It's better to name the variable numberOfRooms or numOfRooms than nRooms - nRooms could mean something else and numOfRooms is just 4 characters longer - so, I think, it worths to name it a little longer.
Use the house naming style for wherever you are working. Other colleagues will be maintaining your code in the future and it is best to make it easy for them.
If you are working for yourself then use the standard naming style for the language you are using. Delphi, Java, C# and others all have standard styles.
If you are working on a collaborative project then follow the house naming style for that project.
As Miroslav says, longer names are generally better, within reason.
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 am not quite sure if this question is relevant here; maybe it's too high level.
Say I have an interface Foo which is implemented by two other concrete classes FooProduction and FooTest. The first one is the production code and the other one the test implementation. Now I want to package everything up but I am not sure which is more suitable. Moving the FooTest class in the test package (where I keep all my tests) or keeping Foo, FooProduction and FooTest in the another package, lets say the foo package?
I would say that making sure FooTest can never find it's way onto a production machine would be the highest priority. As such my vote would be for dividing things along the Test/Production boundary.
I don't know what language you're actually implementing, but in the Java world, the Maven software management system is extremely popular and generally well-regarded, and it makes extremely strong distinctions between so-called "main" and "test" code, resource files, and dependencies. Indeed in their documentation they indicate this is a "testing best practice".
As to where to put the interface Foo and its FooProduction implementation, that's really a question of personal (or site) preference. I like having a package that holds all the domain model objects together for example.
FooTest should be in a separate package than the production code
Whether or not IFoo and FooProduction should go on the same package or on two separate ones depends on the variability of FooProduction (how many implementations are you looking for in the future)
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
What are the best practices for separating data in different classes? Not just objective c, but programming in general.
For example, if someone was making a game like angry birds, how one manage classes?
Would you have a separate class for just the projectiles (in angry birds case, the birds) and have different classes for the targets, music and images, etc?
There is no simple answer to this. You first need to really understand, deep in your soul, how object-oriented programming works and what it represents. Then you need to make your own decisions based on that understanding and your understanding of the problem at hand.
I've seen many "cookbook" applications of OO and MVC and the like that are terrible, even though the writers dotted all the i's and crossed all the t's and their college professors would have given them an A+ on the project.
But in general I'd probably have a common superclass (with several subclasses) for entities that represent visible, movable objects, but probably not use that for music, eg.
not even data but your functional approach must be modular. create as many smaller components in terms of classes and define their behavior as methods and set the interaction between them through the Game Manager/Logic control system that you design for your game...
Best of luck..!!