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.
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 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.
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 do in most programming languages do you get the ability to have private and or public methods/functions classes and properties?
Does it make much of a difrence to let's say.. have all classes, methods and properties be public?
I know that if you have all your methods, classe ans properties set to private nothing will work.
So at least I know that much.
But does the distinction between the two matter? What's the big deal if one class knows another Class "that is meant to be private" exists?
When you make something public, you enter a contract with the user class: "Hey, this is, what I offer, use it or not." Changing the public interface is expensive, because you have to change all code using that public interface, too. Think of a developer of a framework like Cocoa used by thousands of developers. If you change one public methods, for example removing one, thousands of apps break. They have to be changed, too.
So making everything public simply means that you cannot change anything anymore. (You can, but the people will get angry at one point.)
Let's think of having a class implementing a list. There is a method to sort it: sortListWithKey. You make that public because you want the users of the class to get a sorted list. This is good.
There are several algorithms for sorting. Let's say, you implement one that needs to calculate the meridian (the middle element). You need this method internally for your sorting algorithm. So it is enough, to implement it privately. Changing the whole structure of data holding including the implemented sorting algorithm is no problem and will not break existing code using that class.
But if you made the meridian method public (remember: you implemented it, because you needed it internally), you still have to keep it, even the new sorting algorithm does not need it. You cannot remove it anymore, even with the new structure it is very hard (and/or expensive) to keep the method.
So make that part of your implementation public that is useful for the users, but no more. Otherwise you shackle yourself.
If humans had perfect memory, documentation and communication skills, and made no mistakes, then there might not be a useful difference. But using or changing something from the wrong file and then forgetting about it (or not documenting it clearly for the rest of the team, or yourself in the future) is too common a cause of hard-to-find bugs.
Marking things private makes it a bit more work to create the same types of bugs, and thus less likely that lazy/sleepy programmers will do all that extra work just to mess up the application.
In computer science it is called information hiding. You, as a programmer, want to offer only necessary methods or properties to other programmers which will use your public API and this is the way how you can achieve so-called low coupling between modules.
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
In OO apps, it's common to have an Application class which holds your top-level managers or whatever. This makes it hard to avoid having a theApp global object, or using a Singleton or something.
Does it matter? Should we seek to make this as OO as possible, or accept that OO principles break down sometimes?
Does it matter? Should we seek to make this as OO as possible, or accept that OO principles break down sometimes?
Sometimes OO theory meets the real world, and you should strive to make things work for your customers first and foremost. A singleton here or there is not a problem for your customer, or for maintainability.
OOP is mainly there to make code easier to maintain, reuse and understand. As long as those goals are met, there is no need to refactor for purity reasons only.
Having a global theApp object singleton doesn't necessarily violate OO principles, so long as data tied to it is properly encapsulated and whatnot.
There's also the situation that few OS's actually have an OO core, meaning that the Application Loader isn't Object Oriented to begin with.
In any case, absolutism on this point is dangerous; some programming languages have an (IMO) overly zealous approach to the whole thing, dictating every function be a method or the like, even when this doesn't make a lick of sense. (System.Math.sin(x), anyone?)
The most effective approach is usually mixing the two methodologies, using functions for functions, and methods for methods; and by extension, using Singletons for things that truly are singular; such as the application object or interfaces to some system services.
Edit: On System.Math.sin(x), it should be made clear that sin(x) is a function in quite literally every sense of the word, and putting it as a method on a singleton is wildly irresponsible, or at least a bit silly. In the comments a case could exist where another class wanted to use the name sin() for a method, but as methods and functions reside in separate namespaces in any case, this really isn't relevant.
I think the goal should be to design as well as possible. I don't want to have a mindset of seek "badges" or stamps of approval, so I'm not interested being as as "OO as possible", rather I seek to make concious trades-off. We favour concepts such as de-coupling and single-responsibility not because it's OO or because we can claim to be using a Design Pattern, but because we increase the ease of development, maintainability, testability and so on. We also favour simplicity because that too increases mainatainability and testability - the "You ain't gonna need it" principle leads us sometimes to leave things a little mre tightly coupled because we don't need flexibility right now.
So, to consider you example, there may well be a singleton in the sense that yes, there is only one of something (a thread pool or some such) but does the code using it need to know that it's a singleton? With a bit of care, use of factories or injection we can limit the knowledge of the n-gleton-ness.
There is no breakdown of OO by having a "theApp" object.
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.