I am building a relatively simple app and a little bit confused on a better practice of design.
I have a main class MClass. Classes Child1 and Chil2 both inherit from MClass. Now, there is another class AClass, which can inherit from either Child1 or Child2, but not both at the same time (which is only possible through, I believe, interface).
How do I go about having this optional inheritance from one or the other class?
There are also classes AChild1 and AChild2, which both inherit from AClass. The end result would be as follows:
MClass:Child1:AClass:AChild1
MClass:Child2:AClass:AChild2
These are the only two options possible. Is it better to simply combine AClass with its children having
MClass:Child1:AClass1
MClass:Child2:AClass2
I could do this but AClass1 and AClass2 would have a lot of redundant fields... Any reccomendations?
Thank you!
EDIT:
Here is a specific situation:
I have a piece of Equipment that can be either Type1 or Type2. Class Equipment has a bunch of properties. Type1 and Type2 have their own properties and they inherit from Equipment.
Both Type1 and Type2 have cables. There is a class Cable with specific properties. In addition, Type1 and Type2 have different types of cables, CableType1 CableType2, which have their own specific properties and inherit fields from either Type1 or Type2.
VB.NET does not allow multiple inheritance. Depending on your concrete use case, there are various things you can do:
Describe common functionality between the classes in interfaces. Of course you still need to implement the functionality in all classes separate and it does not help you with fields, but you can use a shared interface to access all classes that provide the functionality.
Put the functionality in the child classes like you suggested. This is possible but would mean some duplicate fields. In some cases this might be okay, in other cases not.
Put the functionality in the common base class MClass. Again this depends on the concrete scenario
Use composition over inheritance. The need for multiple inheritance often indicates a bad class design where the inheritance relationship ("is a") is misused and you really want to express a composition ("has a"). This would meaning putting the fields and/or methods in a separate class which is used by both childs. You should use the Single responsibility principle as a guidance, so that each of the classes has only one clearly defined responsibility.
Unfortunately you did not give us a concrete example, so it's difficult to say what would be best in your case. Quite possible a combination of these techniques will lead to best results.
As someone has already mentioned, .NET does not support multiple inheritance. That being said, a class can implement multiple interfaces, or an interface can inherit multiple interfaces, which in conjunction with extension methods provides a nice way to share implementation. This isn't as analogous to multiple inheritance as it is to a mixin, but the effect is largely the same.
If you rethink your model in terms of interfaces, you can do what you want in terms of multiple inheritance. The implementation classes would just be POCO's, and the implementation logic would be static methods in the form of extension methods.
For encapsulation, you can implement certain properties on the implementation class using explicit interface implementation, so that certain properties aren't visible when working with the class itself.
I've found that using this technique helps a lot with testability and prevents a lot of coupling.
Related
I'm modeling a web application, which has some HTML pages, javascript files and 6 servlets.
Right now I have all the servlets in separate classes, but they all share the same methods (doPost, doGet, processRequest, with different implementations) and all of them have the <servlet> stereotype.
I was wondering if there is a way to represent all of them with one class. I'm going to do a text to describe the diagram, so maybe I can explain what that class represents.
As all the methods you cite (doPost, doGet, processRequest) seem to be inherited from Java's HttpServlet, you may as well represent all the implementations with their common parent class HttpServlet.
If the design goes ahead of implementation, I would suggest you create an interface with the common methods(doPost, doGet, processRequest); then different classes implement the same interface. You can optionally introduce an class with default implementation of the interface and let your classes generalize from this class.
If the implementation was already there, to be honest, it is not well designed. A refactor will be much better.
I am trying to develop a conceptual model (object-oriented) of GPS-collected data. Usually, common classes are Track, which represents an ordered sequence of Trackpoints, and the class Trackpoint itself, which has properties such as latitude, longitude, elevation, timestamp, speed, accumulated distance, etc.
The fact is: since a Trackpoint instance only "makes sense" as an item of a Track (or a Segment, or a ConnectedSegment, or other possible similar collection types), the question is:
Is it good/common practice to design a class so that it "behaves" better (or exclusively) as member of a collection? And should I design the collection itself to enforce this?
I think most languages provide various collections implementations and they are well optimized. There is not much point in rolling your own implementations.
If you really don't want "TrackPoint" to be visible outside "Track", then, in Java, one can make TrackPoint a private class inside the definition of Trackclass. I guess in other languages too, you can apply similar visibility restrictions. Again, normally one does not need to to this kind of design either.
Design a Track class which has list of TrackPoint as member. It is as simple as that, and is perfectly good OO design.
I'm wondering about the performance differences between imports and inherits in a .net app.
I currently program by creating multiple classes that logically define my objects. e.g. a class for customers, users and product.
When i want to use these classes in a page i have to import them eg. "Imports Custmomers" and then later in my code i have to create a variable and datatype it before i can use the sub routines and functions from class.
I understand from a coding perspective this keeps it all neat and tidy.
So my question Would it be not better to combine all my classes into a base class, inherit that base class, rather than import it, when i want to use it and so cut down on the extra declarations and associated code that come from importing a class; and if i did this would it aid performance?
No, it will not improve performance to use a base class instead of separate classes, it will just make the application harder to maintain and extend. Prefer composition over inheritance.
If you're having performance problems with your application use a profiler and check where the hotspots are.
"Importing" a class is just a way to tell the compiler that you are too lazy to type the fully qualified names of the types all over your code and has no impact on the runtime performance.
Assume we create 3-tier module, which enables us to display/create/edit articles. Articles are:
• organized into categories
• before article can be published, admin has to approve it by setting Approve field of Articles DB table to true
• by setting MembersOnly field ( Articles table ) admin can also specify whether particular article can be viewed by anybody or only by registered users
• Articles table also has ExpiredDate field, which tells when will the article expire and thus no longer be published
a) At DAL layer we provide methods GetAllArticles, GetArticlesByCategory, GetPublishedArticles and GetPublishedArticlesByCategory for retrieving articles from the DB
At BLL layer we use GetArticles() overloads to call all of the above DAL methods.
What are the some of the benefits of using single overloaded method at BLL layer instead of BLL methods having one-to-one correspondence with DAL methods? Only advantage I can think of is that this way same ObjectDataSource control can call two or more of GetArticles() overloads, depending on the value of parameters, for example:
public static List<Article> GetArticles(bool publishedOnly)
{
if (!publishedOnly)
return GetArticles();
...
}
If you don’t also design UI layer and thus can’t be sure which methods UI programmer will prefer the most, would it be best practice for DLL layer to provide four overloads of GetArticles + GetAllArticles, GetArticlesByCategory, GetPublishedArticles and GetPublishedArticlesByCategory?
2) When designing DAL methods to retrieve data from DB, how can you in advance know/predict ( without first designing the UI ), exactly which methods (for accessing DB) we should create at the DAL layer?
Namely, in the previous example I’ve had several methods for retrieving articles based on number of parameters ( based on category they belong to, whether we only want published articles etc). Assuming I’m selling this module to third party UI developers, then there is no way to know which data access methods they would prefer the most:
a) so should I create as many data access methods as I can think of ( one for getting all articles that are already expired, one for getting all articles that are already expired, but were never published, one for getting all articles that are not published, one for getting all articles that can be view by registered users only… ) ?
b) Even if all three layer are written by myself – should I still create as many data access methods as I can think of?
thanx
EDIT:
A common way to achieve this is to use interfaces to define the behavior of the API.
a) I’m not sure I understand this. Which class should implement this interface? Perhaps DLL class? In other words, if the name of my DLL class is Article, then third party would derive class named ChildArticle from Article, where ChildArticle would also implement this interface? Or did you mean something else?
b) Anyways, as far as I understand it, providing interface ( which declares defines additional DLL methods to retrieve articles from DB ) would also require DAL class to already have appropriate methods defined, which would be called by methods declared in the interface?
To your point, I believe it is a good idea to prefer fewer coarse-grained methods in the BLL to cover all the functionality required by an entire business operation
I’m not familiar with this term, but you’re prob suggesting that we should prefer overloaded GetArticles() over GetAllArticles, GetArticlesByCategory, GetPublishedArticles and GetPublishedArticlesByCategory?
A) The design of an API is strictly related to what it is meant to achieve and by whom it will be used.
In practice, this means that you should know the target audience of your API, and give them only what they need to get the job done.
Unless I personally interview the people that would buy my product, I can generally guess which methods they would find useful, but within that space, there are still any number of possible methods I could define. Thus, how should I know whether they would also find use for, say, GetArticles() overload which retrieves articles that already expired?!
On the other side it is perfectly fine to have many smaller data-centric methods in the DAL to work with specific pieces of data.
If not DLL, should DAL have as many data access methods as I can come up with ( for particular target audience of course )?
SECOND EDIT:
A few extensibility points can be built into the API to obtain a certain degree of flexibility. A common way to achieve this is to use interfaces to define the behavior of the API. This will allow consumers to replace or extend the pieces of the built-in functionality by providing custom implementations.
Assume I create a BLL layer and then provide some additional interfaces, which consumers could implement to extend BLL’s build-in functionality. But for consumers to be able to implement these interfaces, they will need to have access to BLL’s source code, right? But what if I don’t want consumers to view BLL’s source code?
Interfaces should exist between layers. More specifically, classes should interact with classes from other layers exclusively through interfaces
a) So even DAL’s built-in functionality should be exposed through interfaces? But why? Namely, if we’d use abstract class instead of interfaces, then this class could already implement some utility functions common to all provider classes that inherit from this abstract class?! On the other hand, if DAL uses interfaces instead, then utility functions common to all providers will have to be implemented once for each provider, which could mean a lot of redundant coding?!
b) Anyways, I don’t quite see the benefits ( except when we provide interfaces with which consumers could extend the basic functionality ) in having classes from different layers interacting through interfaces?
For added clarity, instead of overloading methods to work with different parameters, I believe it is better to have one method that accepts a single parameter. This parameter would be an object containing all the data for the method to work with. Some of that data could be required, some could be optional and would influence the effect of the operation.
If I know UI will extensively make use Object Data Source controls, should I still prefer BLL to define a single method (this method having as parameter an object with all the data for the method to work with) instead of method overloads?
cheers mate
I took the liberty to summarize your post in two main questions. I hope I managed to capture the essence of what you are asking.
Q) What is the relationship between the intefaces exposed by the DAL and the ones exposed by the BLL?
A) The BLL is an outward-facing API, and as such it should implement functionality that is useful to the external consumers of the application and expose it in a way that makes sense to them.
The DAL, on the contrary, is a inward-facing API that exposes functionality to retrieve and persist data in way that hides the details of the storage mechanism being used.
In short, the DAL focuses on how data is being represented and managed internally in the application, while the BLL focuses on exposing data in way that is meaningful to consumers.
Q) How many methods should a public API have, and which ones?
A) The design of an API is strictly related to what it is meant to achieve and by whom it will be used.In practice, this means that you should know the target audience of your API, and give them only what they need to get the job done.
Since it is impossible to predict all the possible ways an API will be used, it is important to decide which main use cases to support, and work to make them really straightforward in the API. A good principle to keep in mind is what Alan Kay once said:
Simple things should be simple,
complex things should be possible.
A few extensibility points can be built into the API to obtain a certain degree of flexibility. A common way to achieve this is to use interfaces to define the behavior of the API. This will allow consumers to replace or extend the pieces of the built-in functionality by providing custom implementations.
To your point, I believe it is a good idea to prefer fewer coarse-grained methods in the BLL to cover all the functionality required by an entire business operation.On the other side it is perfectly fine to have many smaller data-centric methods in the DAL to work with specific pieces of data.
UPDATE:
About interfaces
Interfaces should exist between layers. More specifically, classes should interact with classes from other layers exclusively through interfaces. For example, the DAL should expose interfaces for the classes used to access data, like IOrderHeaderTable or IOrderRepository depending on the design pattern being used.
The BLL should expose classes used to execute business operations, like IOrderManagementWorkflow, or ICustomerService.
Note: common functionality inside a layer can still be placed in base classes, since in modern Object-Oriented languages like C#, VB.NET and Java a class can both inherit from a base class and implement one or more interfaces.
Also, external parties who wish to customize the built-in functionality by implementing any of the provided public interfaces can do so without needing access to the source code. Interfaces should however be self-describing and well-documented, in order to make it easy for extenders to understand its semantics.
About the BLL
The BLL should be explicit about the business logic it supports. Therefore it is generally a good idea to have methods that are directly related to business operations.For added clarity, instead of overloading methods to work with different parameters, I believe it is better to have one method that accepts a single parameter. This parameter would be an object containing all the data for the method to work with. Some of that data could be required, some could be optional and would influence the effect of the operation.
Implementation detail: this kind of BLL API is fully supported by ObjectDataSource control built into ASP.NET Web Forms.
About the API
An API should contain all methods the designer can come up with, within the scope defined by the use cases the API is intended to support.
For example: a compatibility layer between scripting objects (like strings, arrays) or scripting engines( eval() ,readFile() etc.).
Without more context, I'd have to say interfaces as well. Consider that you can represent a function or delegate as an interface with a single method and that abstract classes are just interfaces with some methods potentially already implemented.
That said, it really depends on what you're trying to accomplish. Interfaces lend themselves to cases where you have lots of objects with a common interface but potentially varying implementations. If you are, for example, designing a very simple callback system for plugins (i.e.: let the plugin hook certain events in the host application) then delegates are probably simpler and sufficient for your needs.
Also keep in mind that if you do go with interfaces, you'll probably need some way for the host to instantiate instances. The easiest way to do this is by registering a delegate with the host under some unique name.
Abstract classes are only useful if you want to use interfaces and provide a default implementation of some things. A better solution in that case is to have an actual interface instead, and provide the default implementation as a mixin.
Interfaces have my vote. That way, as long as you define the interface any developer will be able to write something compatible fairly easily without you having to distribute too much code to them.