I've written a abstract base class TCPIP sever in its own namespace/library. Currently I have the derived class (more specific TCPIP server; with DataHandler) in the .exe project of the solution.
I'm almost 100% certain this is how I will go, but part of me wants to put the derived class in the base class project. What are some good reasons for/against this?
I believe YAGNI, KISS and The Rule Of Three apply here. If you don't have immediate plans to try to reuse the derived class, then keep it in the application namespace. If you find later there is a second project/application that can use something like your derived class then keep to your plan and use it as a "template" to create another similar derived class by cut and paste.
If you find a third occasion to do this again, then you can take a look and see if there is a reasonably useful subclass sitting in there. Don't get distracted trying to spot reusable abstractions too early.
"Why do I need the base class library"?
Usually because you want to use it in multiple projects.
If this is the case, do you need to use the derived class in other projects?
If you plan on having other exe's use the your derived class its helpful if it there and not in the exe.
My reasoning in favor of this approach is that if I put the dervied class in the .exe namespace, I will have access to all those classes (e.g. data queue). However, if I put the derived class in base project, I'd have to grant access to all the classes in the .exe namespace in order to use just one of them (using DotExeNamespace;).
Related
I'm relatively new in OOP.
I understand classes, methods, etc, etc but I'm having troubles with the philosophy.
Right now, I'm working on a project to manage projects, with project management, class, methods, variables, users, groups, log and task management.
So, starting with Project class, i've that:
public function create_project()
public function get_projects()
public function delete_project()
Then, ProjectClass class:
public class create_class()
public class get_classes()
public class delete_class()
But then, I though that is not the right way, so I've changed to:
Project class methods:
set_name, get_name (and similar methods)
add_class
get_classes
add_log
get_logs
ProjectClass class methods:
set_project_id (and get)
add_variables (and get)
add_method
...
So, in the first case, is the Project class who create new projects, the ProjectClass class who creates the clases and the Method class who creates the methods, and in the second case, is the Project class who creates and manages its classes and is the ProjectClass class who creates and manages its methods.
So, is any of theses "styles" correct?
If is the second case the correct case, who creates the projects? Itself?
Thank you so much
In the general case it is really hard to tell if a design is better than the other if you don't have clear responsibilities to assign (and by this I mean behavior outside from getters and setters). As time went by I moved away from upfront design to a iterative/incremental one, tackling one problem at a time and refactoring the design as needed. In this case I would try to lay down the basic requirements of your system and start a design-implementation cycle for each of them, re-structuring your model as you go tackling new requirements.
Just an an example consider this question: Does it make sense to have a class that is not bounded to a project? If the answer is no then it can be a good idea to have a method like Project>>createClass(aClassName), since you are explicitly stating that a class is created in the context of a project. Also you can make the proper connections between a class and the project it belongs to inside the method's implementation. However it is also a valid approach to define a constructor in the ProjectClass class that takes a project as a parameter. In that way you are saying "if you want to create a new class, then you must provide the project where it belongs to". Which approach to use depends on many things, one of them being programmer tastes :), so it is really hard to state if one is better than the other without having a specific context to evaluate them.
Finally, if it helps, there are a few things that are worth mentioning:
Assuming that public function create_project() is an instance method, why does an instance of a Project know how to create other projects? At first it doesn't make much sense, since that is basically a class-side responsibility, unless you have a specific motivation for this (e.g. like the Prototype pattern).
Why does a project answer to get_projects()? Are they related in some way? Or it just list all the projects? Then again, this sounds like a class-side responsibility.
I generally don't like to add the concept that the message receiver represents as part of the message. So, I wouldn't call the message delete_project(), since it is redundant to state $project->delete_project() (you already know the receiver of the message is a project).
You should be consistent with your class names. If you use ProjectClass to represent classes then you should use ProjectMethod to represents methods (though I personally don't like these names, IMHO they are misleading). It is quite important to chose proper names and keep them consistent in your domain model.
HTH
I'm trying to use ILGeoNames classes in my project. But I have problem with understanding in which way I can use this classes for my purpose. There is "simple project" in this framework. From it I want only one thing: country time zone (I already have county name). Because there are many method, variables and others staffs I can't understand what exactly I need to use. Please, help me solve this question.
If its a bunch of classes and you want to make use of a certain class's methods or properties, then you have to #import name_of_class_you_want_to_utilize; at the start of your file and then make your calls. Class methods can be called directly, whereas instance methods require you to create an instance of the class to access them.
I just want advice on whether I could improve structure around a particular class which handles all disk access functions
The structure of my program is that I have a class called Disk which gets data from flatfiles and databases on a, you guessed it, hard disk drive. I have functions like
LoadTextFileToStringList,
WriteStringToTextFile,
DeleteLineInTextFile
etc
which are kind of "generic methods"
In the same class I also have some more specific methods such as GetXFromDisk where X might be a particular field in a database table/query.
Should I separate out the generic methods from the specialised. Should I make another class which inherits the generic methods. At the moment my class is static as there is no need to have an internal state of the class.
I'm not really OOPing am I?
Thanks
Thomas
If you are using only static static functions you are not really OOPing as you said. It is writing procedural code in OO language.
You should look to create classes which represent objects in your problem domain like File and TextFile. These classes should have operations like DeleteLine, WriteLIne, Load etc.
Also, in which ever language you are programming, it is likely to have a good File IO library. Try to use that in your code as much as possible. If needed just write wrappers over the library classes to provide some additional functionality.
Well, what you seem to have in your code is a Utilities class where you bundle in all the file methods.
This could indicate some design issue but IMHO it is ok, since it is common to have utility classes in OOP designs.
It haves the benefit of being able to add extra methods or modify existing ones easy since you will not have any derived classes extending the Utility class to be affected.
For example java has static methods everywhere. E.g. Collection class.
I would suggest to have the class's contructor be private and have the naming such that is obvious that this is a Utilities class.
I have a function that 2 derived classes use, but the third doesn't, would it make sense to just leave it in the base class, even though one of the 3 derived classes doesn't use it?
The only way I could think of disallowing the third class is to basically create an intermediate class that is derived of the base, then the 2 that use the common function are derived off the second class.
Is it possible to prevent the 3rd class from using the function, while letting the two that are supposed to use it, use it?
Does that just seem to go overboard, I mean as long as I don't "try" to call the function from the 3rd class, it shouldn't be a problem, I just was interested if there was a way to prevent it all together without a lot of hassle.
There is not a way to do this directly. Basically, when you subclass, you're saying the subclass is a more specific version of the base class.
In this case, you're trying to say "the subclass is a more specific version of the base class, except for the fact that it shouldn't be able to touch XXX". That's, in essence, violating the Liskov Substitution Principle.
The best way to handle this is to add a second base class in your hierarchy, which is I believe the solution you mention.
Basically, make your hierarchy:
base
| \---- subclass without feature available
|
\--base+feature
\--subclass one with specific feature
\--subclass two with specific feature
You can make this function virtual. Then override the function in the 3rd class and throw an exception. It will prevent developers to use the function in the 3rd class.
Do you have any input on how to organize and name utility classes?
Whenever I run in to some code-duplication, could be just a couple of code lines, I move them to a utility class.
After a while, I tend to get a lot of small static classes, usually with only one method, which I usualy put in a utility namespace that gets bloated with classes.
Examples:
ParseCommaSeparatedIntegersFromString( string )
CreateCommaSeparatedStringFromIntegers( int[] )
CleanHtmlTags( string )
GetListOfIdsFromCollectionOfX( CollectionX )
CompressByteData( byte[] )
Usually, naming conventions tell you to name your class as a Noun. I often end up with a lot of classes like HtmlHelper, CompressHelper but they aren't very informative. I've also tried being really specific like HtmlTagCleaner, which usualy ends up with one class per utility method.
Have you any ideas on how to name and group these helper methods?
I believe there is a continuum of complexity, therefore corresponding organizations. Examples follow, choose depending of the complexity of your project and your utilities, and adapt to other constraints :
One class (called Helper), with a few methods
One package (called helper), with a few classes (called XXXHelper), each class with a few methods.
Alternatively, the classes may be split in several non-helper packages if they fit.
One project (called helper), with a few packages (called XXX), each package with ...
Alternatively, the packages can be split in several non-helper packages if they fit.
Several helper projects (split by tier, by library in use or otherwise)...
At each grouping level (package, class) :
the common part of the meaning is the name of the grouping name
inner codes don't need that meaning anymore (so their name is shorter, more focused, and doesn't need abbreviations, it uses full names).
For projects, I usually repeat the common meaning in a superpackage name. Although not my prefered choice in theory, I don't see in my IDE (Eclipse) from which project a class is imported, so I need the information repeated. The project is actually only used as :
a shipping unit : some deliverables or products will have the jar, those that don't need it won't),
to express dependencies : for example, a business project have no dependency on web tier helpers ; having expressed that in projects dependencies, we made an improvement in apparent complexity, good for us ; or finding such a dependency, we know something is wrong, and start to investigate... ; also, by reducing the dependencies, we may accelerate compilation and building ....
to categorize the code, to find it faster : only when it's huge, I'm talking about thousands of classes in the project
Please note that all the above applies to dynamic methods as well, not only static ones.
It's actually our good practices for all our code.
Now that I tried to answer your question (although in a broad way), let me add another thought
(I know you didn't ask for that).
Static methods (except those using static class members) work without context, all data have to be passed as parameters. We all know that, in OO code, this is not the preferred way. In theory, we should look for the object most relevant to the method, and move that method on that object. Remember that code sharing doesn't have to be static, it only has to be public (or otherwise visible).
Examples of where to move a static method :
If there is only one parameter, to that parameter.
If there are several parameters, choose between moving the method on :
the parameter that is used most : the one with several fields or methods used, or used by conditionals (ideally, some conditionnals would be removed by subclasses overriding) ...
one existing object that has already good access to several of the parameters.
build a new class for that need
Although this method moving may seem for OO-purist, we find this actually helps us in the long run (and it proves invaluable when we want to subclass it, to alter an algorithm). Eclipse moves a method in less than a minute (with all verifications), and we gain so much more than a minute when we look for some code, or when we don't code again a method that was coded already.
Limitations : some classes can't be extended, usually because they are out of control (JDK, libraries ...). I believe this is the real helper justification, when you need to put a method on a class that you can't change.
Our good practice then is to name the helper with the name of the class to extend, with Helper suffix. (StringHelper, DateHelper). This close matching between the class where we would like the code to be and the Helper helps us find those method in a few seconds, even without knowledge if someone else in our project wrote that method or not.
Helper suffix is a good convention, since it is used in other languages (at least in Java, IIRC rails use it).
The intent of your helper should be transported by the method name, and use the class only as placeholder. For example ParseCommaSeparatedIntegersFromString is a bad name for a couple of reasons:
too long, really
it is redundant, in a statically typed language you can remove FromString suffix since it is deduced from signature
What do you think about:
CSVHelper.parse(String)
CSVHelper.create(int[])
HTMLHelper.clean(String)
...