Right now, I have the following design:
Item
|------------------------|
ImageUploader |
|--------------| |
| | |
AvatarUploader FaviconUploader NameChanger
These classes are various items that users can purchase and use.
However, I'm adding a new class IconUploader. Unlike the other classes, this is not an item that can be used, but an administrative panel. ImageUploader contains certain security checks to make sure only safe files are uploaded, and IconUploader needs these precautions as well.
However, I'm not sure what to do. Ideally, I'd make ImageUploader an interface, but you can't have actual code in interfaces, so I can't do that. I could move ImageUploader out of the Item class hierarchy and make its functions static, but that doesn't feel right to me. Is it? And if it isn't, what is the best way to restructure this?
N.B.: I'm using PHP, if that affects anything.
You should probably have a GenericUploader, and then each type of uploader can specify a list of valid files, then the GenericUploader will ensure those requirements are met (along with anything else you might wish it do to).
You need a ImageUploaderBase class which is abstract and have the common functionality.
You could move the security checking and common upload functionality for the uploaders into a separate Uploader class, and make ImageUploader use this Uploader class (so all derived classes like Avatar/FaviconUploader would use it as well).
Then you could make IconUploader use Uploader (without it being derived from Item).
Then you can make ImageUploader and IconUploader implement an IUploader interface, and have all calls to the interface forwarded to the Uploader class to implement.
Related
I am structuring given code base for iOS, which is used to create two kinds of apps, which share common functionality. The new structure would ideally look like this:
×-> General Implementation <-------------×
| |
×-- GeneralMainProject Implementation <---× SomeProjectX Implementation
|
MainProjectVersionX Implementation ----×
where each Implementation may include classes subclassing classes from upper level, and set of utility classes.
The problem is, that when I want to use a subclass, I would have to override every single use of it (for example, in GeneralMainProject AppDelegate).
Any idea how to solve this, with technology or different design? Class posing and categories don't help, because they would require dictionary of fields and or runtime disadvantages.
Thanks.
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.
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;).
I'm a student looking for resources which can help me further understand how to properly apply access modifiers to members/types as I code them.
I know (in C#) what restrictions access modifiers like private, public, protected, etc. put into place. When I code my own little projects I have a tendency to just make everything public. I'm certain this is an absolutely horrible practice as it just tosses encapsulation out the window. I just never know when it's correct to use something like internal vs. private.
Does anyone have any good resources to aid me in understanding the proper use of access modifiers?
This is an experience type question. Start from the level of least privilege and promote up as necessary.
In other words, make everything private. Until you discover that it needs to be promoted to protected or public. Over time you will get a feel for the intended and later discovered usages of your classes.
I simply make everything's access as restrictive as possible:
Private by default
Otherwise internal, if it's an API exposed to other classes within this assembly
Or, public if it's an API exposed outside the assembly
Or, protected if it's intended to be called only from subclasses.
Start putting everything private. If you feel the need, change the modifier accordingly, until you have the feeling to choose the right type.
To make things easier, try using TDD, or you might get into even more trouble when you get to write unit tests...
Any kind of tutorial or teaching material will give you the same guidance, namely the one that the other postings already gave you. So don't expect much useful information in this specific matter from "resources".
The primary resource that goes beyond that is code that other people have written. Take a large C# project (e.g. Mono, or SharpDevelop), and study how they specifically followed the principles that have been explained to you. Also, if you have a specific class to design, try to think of a similar class in the system libraries, and try to find out how it is implemented (either by looking at the Mono source, or by using the .NET reflector).
You should start by thinking about the interface of a class, that is the necessary and sufficient set of routines it needs to expose in order to achieve its purpose. Make that public. Everything else should be private.
I have a tendency to make everything protected that is not public. Leaving the freedom of my users to do whatever they want with my class. If their class breaks that would be their problem.
Every time you inherit from a class you need to know how it works even if oop is about hiding the implementation. You can hide the implementation, but you won't hide the documentation.
A lot of the time I will have a Business object that has a property for a user index or a set of indexes for some data. When I display this object in a form or some other view I need the users full name or some of the other properties of the data. Usually I create another class myObjectView or something similar. What is the best way to handle this case?
To further clarify:
If I had a class an issue tracker and my class for an issue has IxCreatedByUser as a property and a collection of IxAttachment values (indexes for attachment records). When I display this on a web page I want to show John Doe instead of the IxCreatedByUser and I want to show a link to the Attachment and the file name on the page. So usually I create a new class with a Collection of Attachment objects and a CreatedByUserFullName property or something of that nature. It just feels wrong creating this second class to display data on a page. Perhaps I am wrong?
The façade pattern.
I think your approach, creating a façade pattern to abstract the complexities with multiple datasources is often appropriate, and will make your code easy to understand.
Care should be taken to create too many layers of abstractions, because the level of indirection will ruin the initial attempt at making the code easier to read. Especially, if you feel you just write classes to match what you've done in other places. For intance if you have a myLoanView, doesn't necessarily you need to create a myView for every single dialogue in the system. Take 10-steps back from the code, and maybe make a façade which is a reusable and intuitive abstraction, you can use in several places.
Feel free to elaborate on the exact nature of your challenge.
One key principle is that each of your classes should have a defined purpose. If the purpose of your "Business object" class is to expose relevant data related to the business object, it may be entirely reasonable to create a property on the class that delegates the request for the lookup description to the related class that is responsible for that information. Any formatting that is specific to your class would be done in the property.
Here's some guidelines to help you with deciding how to handle this (pretty common, IMO) pattern:
If you all you need is a quickie link to a lookup table that does not change often (e.g. a table of addresses that links to a table of states and/or countries), you can keep a lazy-loaded, static copy of the lookup table.
If you have a really big class that would take a lot of joins or subqueries to load just for display purposes, you probably want to make a "view" or "info" class for display purposes like you've described above. Just make sure the XInfo class (for displaying) loads significantly faster than the X class (for editing). This is a situation where using a view on the database side may be a very good idea.