This is the closest thing I could find to my problem on here
I'm working on a projects and I want to add a security model to it, so since I have experience first hand how bad jumping into coding and skipping the planning phase is I decided to do that first. So I created an ERD, cool do it all the time, then the UML Class diagram, haven't done one of these since college, ok a little bit of google, go it.
See ERD And UML Class Diagram Here
The image above is an exert of what I have so far, I know that I certainly need a User Class and a Permission Class but I'm not sure how to handle the relationship between the two. I know generally in an M-N relationship you model it with a property that is a collection of the related class but what about the properties of the related class? Below is my best guess, if anyone has corrections, comments, or links to material to read that would be awesome. My goal is the proper implementation of OOP thanks in advance.
class User{
private $id;
private $password;
private $active;
private $permissions;
/* skip getters and setters */
function getUserPermissions(){
return UserPermission[];
}
}
class UserPermission{
private $id;
private $deny;
private $grant;
private $active;
/* skip getters and setters */
function getPermissions(){
return Permission[];
}
}
class Permission{
private $id;
private $name;
private $description;
private $active;
/* skip getters and setters */
}
You could have these arrays that you return directly, as arrays or lists. But that is not so important.
What is more important, every UserPermission, that is a class association, should have an array of User's and an array of Permission's.
Also, every User should have his UserPermission and every Permission should have its UserPermission, too.
And User should have no array for UserPermission's. Their association is 1:n, with n on the side of User. That means: UserPermission has many User's, User has 1 UserPermission.
Related
I'm learning how to use Symfony and I have a logical issue.
Here is what I want to do :
I have two entities: post and category.
Between them, I have a ManyToMany relationship.
Here, everything works as I expected. I have two forms and a relational table between the entities named: post_category
I'd like to give a range for each post which is in a category.
So I thought that I have to insert the third column in my relational table.
But here I'm lost.
How can I create this?
Should I do it manually and create a custom query in a repository?
I never used a custom query yet, so if someone can give some clues to do it...
Thanks a lot!
Here are my (simplified) entities:
class Category
{
private $id;
private $title;
private $description;
private $relPosts;
}
class Post
{
private $id;
private $title;
private $content;
private $slug;
private $relCategories;
private $range;
private $createdAt;
}
My conditional table "post_contenu":
post_id | contenu_id
I'm reading Grady Booch's book Object-Oriented Analysis and Design with Applications, third edition. In page 94, Booch said that:
We can furthur devide the interface of a class into four parts:
Public: a declaration that is accessible to all clients
Protected: a declaration that is accessible only to the class itself and its subclasses
Private: a declaration that is accessible only to the class itself
Package: a declaration that is accessible only by classes in the same package
I can understand why protected declaration can be considered a interface, becuase subclasses of a class is this class's client, too.
But I don't understand why the private declaration can be considered as interface. Please enlight me.
But I don't understand why the private declaration can be considered as interface.
Private declarations may be said to constitute an interface, since they have their own clients, though not as many as protected or public interface of a class.
These clients are:
The class itself. Obviously, you can access your classes' private members from any static or non-static method of any instance of your class.
Inner classes of your class. Remember that inner classes of your class have access to all of the members of your class, including private ones.
(In C++) Friends of your class. Though from the quote in your question, I see that the book you refer to is about Java, I'll add this item anyway, for completeness, since your question isn't tagged java. In C++ there is a friend keyword, which allows a programmer of a class to designate certain other classes and/or functions as friends of this class. Such "friendly" classes and functions have access to all the members of the class, including private ones, and so they are also clients of the class' private interface.
So, it may be useful to have a well-defined private interface, since it makes the implementation of methods in both your class, its friends and inner classes simpler and more manageable for other developers, who may be working on your class.
But still, I find an "interface to itself" is quite odd.
Interface to itself may be important. Here's a little thought experiment.
Imagine that two developers, Alice and Bob, are working on the same class, called MissileLauncher. Bob is responsible for implementing the logic to clear the launching pad after the missile is fired. (This is a private mechanism, clients of the public or protected interface may not request the pad to be cleared - it's just an implementation detail of this class).
So, Bob knows that to clear the launching pad one has to decrement missleCounter, set currentMissle to null and call pendingOperations.remove(this.currentOp). There is only one place in the code of the class, where this has to be done. Bob could encapsulate all of this in a private method, called clearLaunchingPad() but he figured that the logic is too simple, so he didn't bother.
Several months later, Alice discovers that there is another scenario, where the launching pad needs to be cleared. If Bob had thought about a proper "interface to itself", Alice would be able to simply write a call to this.clearLaunchingPad() and be done with it in several seconds. But, as we know, Bob didn't. Now Alice has to go and ask Bob what she needs to do to clear the pad. But several months have already passed, Bob doesn't remember the implementation details anymore, or worse, he may have been fired since then (and no surprise either, given his coding culture).
So now Alice has to dig into the code of MissileLauncher and try to figure out what she needs to do, hoping that Bob has at least had the decency to comment his code.
In this way several seconds turn into several hours and a few possible bugs (Alice might forget to call pendingOperations.remove(this.currentOp) at the end), just because Bob didn't pay attention to the design of this class` interface to itself.
I read it one more time and that is very simple it's just say's that interface can be private,protected,Package and public and after that he tells you for what you need it and how you using them :)
example for private interface : interface that can be implemented only inside the class!
public class MyClass
{
private interface IFoo
{
int MyProp { get; }
}
private class Foo : IFoo
{
int _mamboNumber = 5;
public int MyProp { get { return _mamboNumber; } set { _mamboNumber = value; } }
}
private class FooSec : IFoo
{
int _mamboNumber = 10;
public int MyProp { get { return _mamboNumber; } set { _mamboNumber = value; } }
}
public static void Main(string[] args)
{
IFoo foo = new Foo();
int fooProp = foo.MyProp; // return 5
IFoo foo2 = new FooSec();
int foo2Prop = foo2.MyProp; // return 10
}
}
I am learning php oop. But I can not understand in which situations use public, private and protected. I know that public is accessable inside the class and outside the class, protected inside the class and inside classes which inherites it, private is accessable only inside the class. But how to know that the property or method must be protected or private ? I know that if write class for connecting database they must be protected or private. But, an example: I am writing registrating class(is the code below true ?):
private $email;
private $username;
private $password;
private $securitycode;
private function register {
//here registrations codes, may be I must use public function ?
}
Another example: I have news section in the website and want to get news details (id, title, text, author) and write News class (is given code below true ?):
private $id;
private $title;
private $text;
private $author;
public function get_one_news($this->id) {
//here the code for getting the news, may be I must use protected function ?
}
Another example: I want to get number of users or news: Which I have to use : public, protected or private function ?
Another example: Every user(registered or unregistered) can add comment(id, comment): Can I use public $id; public $comment ? or I have to use protected or private ?
Please, I need your advices. Which(public, protected, private properties and functions) to use if I want to add/get news, to register/login user, to add/edit/get data from database tables, to make fileuploading and etc. ?
I could not find answers to my question.
You can think about it like this. The non-private parts of your class are its interface to the outside world. You can change the private inner workings as much as you want, without thinking about breaking other code in your system. However as soon as you start changing the non private parts you have to take into consideration all the users of your code depending on your current public interface. So I think as a general rule of thumb you should try to make your code as private as possible.By that you can greatly increase the encapsulation of your codebase, allowing you to change the internal implementation details without affecting the code using your class.
So in a first step think about what functionality your new class should offer its users. This should then become its public interface. Then think about whether or not your class should be inherited from and what parts should be allowed to be changed in its subclasses. Everything else should be private as it is the classes internal implementation.
I'm trying to follow the Law Of Demeter ( see http://en.wikipedia.org/wiki/Law_of_Demeter , http://misko.hevery.com/code-reviewers-guide/flaw-digging-into-collaborators/ ) as I can see the benefits, however I've become a little stuck when it comes to domain objects.
Domain objects do naturally have a chain and sometimes it's necessary to display the information about the entire chain.
For instance, a shopping basket:
Each order contains a user, delivery info and a list of items
Each order item contains a product and quantity
Each product has a name and price.
Each user contains a name and address
The code which displays the order information has to use all the information about the order, users and products.
Surely it's better and more reusable to get this information through the order object e.g. "order.user.address.city" than for some code higher up to do queries for all the objects I listed above then pass them into the code separately?
Any comments/suggestions/tips are welcome!
One problem with using chained references, such as order.user.address.city, is that higher-order dependencies get "baked into" the structure of code outside the class.
Ideally, in cases when you refactor your class, your "forced changes" should be limited to the methods of the class being refactored. When you have multiple chained references in the client code, refactoring drives you to make changes in other places of your code.
Consider an example: suppose that you'd like to replace User with an OrderPlacingParty, an abstraction encapsulating users, companies, and electronic agents that can place an order. This refactoring immediately presents multiple problems:
The User property will be called something else, and it will have a different type
The new property may not have an address that has city in cases when the order is placed by an electronic agent
The human User associated with the order (suppose that your system needs one for legal reasons) may be related to the order indirectly, - for example, by being a designated go-to person in the definition of the OrderPlacingParty.
A solution to these problems would be to pass the order presentation logic everything that it needs directly, rather than having it "understand" the structure of the objects passed in. This way you would be able to localize the changes to the code being refactored, without spreading the changes to other code that is potentially stable.
interface OrderPresenter {
void present(Order order, User user, Address address);
}
interface Address {
...
}
class PhysicalAddress implements Address {
public String getStreetNumber();
public String getCity();
public String getState();
public String getCountry();
}
class ElectronicAddress implements Address {
public URL getUrl();
}
interface OrderPlacingParty {
Address getAddress();
}
interface Order {
OrderPlacingParty getParty();
}
class User implements OrderPlacingParty {
}
class Company implements OrderPlacingParty {
public User getResponsibleUser();
}
class ElectronicAgent implements OrderPlacingParty {
public User getResponsibleUser();
}
I think, when chaining is used to access some property, it is done in two (or at least two) different situation. One is the case that you have mentioned, for example, in your presentation module, you have an Order object and you would like to just display the owner's/user's address, or details like city. In that case, I think it is of not much problem if you do so. Why? Because you are not performing any business logic on the accessed property, which can (potentially) cause tight coupling.
But, things are different if you use such chaining for the purpose of performing some logic on the accessed property. For example, if you have,
String city = order.user.address.city;
...
order.user.address.city = "New York";
This is problematic. Because, this logic is/should more appropriately be performed in a module closer to the target attribute - city. Like, in a place where the Address object is constructed in the first place, or if not that, at least when the User object is constructed (if say User is the entity and address the value type). But, if it goes farther than that, the farther it goes, the more illogical and problematic it becomes. Because there are too many intermediaries are involved between the source and the target.
Thus, according to the the Law of Demeter, if you are performing some logic on the "city" attribute in a class, say OrderAssmebler, which accesses the city attribute in a chain like order.user.address.city, then you should think of moving this logic to a place/module closer to the target.
You're correct and you'll most likely model your value objects something like this
class Order {
User user;
}
class User {
Address shippingAddress;
Address deliveryAddress;
}
class Address {
String city;
...
}
When you start considering how you will persist this data to a database (e.g. ORM) do you start thinking about performance. Think eager vs lazy loading trade offs.
Generally speaking I adhere to the Law of Demeter since it helps to keep changes in a reduced scope, so that a new requirement or a bug fix doesn't spread all over your system. There are other design guidelines that help in this direction, e.g. the ones listed in this article. Having said that, I consider the Law of Demeter (as well as Design Patterns and other similar stuff) as helpful design guidelines that have their trade-offs and that you can break them if you judge it is ok to do so. For example I generally don't test private methods, mainly because it creates fragile tests. However, in some very particular cases I did test an object private method because I considered it to be very important in my app, knowing that that particular test will be subject to changes if the implementation of the object changed. Of course in those cases you have to be extra careful and leave more documentation for other developers explaining why you are doing that. But, in the end, you have to use your good judgement :).
Now, back to the original question. As far as I understand your problem here is writing the (web?) GUI for an object that is the root of a graph of objects that can be accessed through message chains. For that case I would modularize the GUI in a similar way that you created your model, by assigning a view component for each object of your model. As a result you would have classes like OrderView, AddressView, etc that know how to create the HTML for their respective models. You can then compose those views to create your final layout, either by delegating the responsibility to them (e.g. the OrderView creates the AddressView) or by having a Mediator that takes care of composing them and linking them to your model. As an example of the first approach you could have something like this (I'll use PHP for the example, I don't know which language you are using):
class ShoppingBasket
{
protected $orders;
protected $id;
public function getOrders(){...}
public function getId(){...}
}
class Order
{
protected $user;
public function getUser(){...}
}
class User
{
protected $address;
public function getAddress(){...}
}
and then the views:
class ShoppingBasketView
{
protected $basket;
protected $orderViews;
public function __construct($basket)
{
$this->basket = $basket;
$this->orederViews = array();
foreach ($basket->getOrders() as $order)
{
$this->orederViews[] = new OrderView($order);
}
}
public function render()
{
$contents = $this->renderBasketDetails();
$contents .= $this->renderOrders();
return $contents;
}
protected function renderBasketDetails()
{
//Return the HTML representing the basket details
return '<H1>Shopping basket (id=' . $this->basket->getId() .')</H1>';
}
protected function renderOrders()
{
$contents = '<div id="orders">';
foreach ($this->orderViews as $orderView)
{
$contents .= orderViews->render();
}
$contents .= '</div>';
return $contents;
}
}
class OrderView
{
//The same basic pattern; store your domain model object
//and create the related sub-views
public function render()
{
$contents = $this->renderOrderDetails();
$contents .= $this->renderSubViews();
return $contents;
}
protected function renderOrderDetails()
{
//Return the HTML representing the order details
}
protected function renderOrders()
{
//Return the HTML representing the subviews by
//forwarding the render() message
}
}
and in your view.php you would do something like:
$basket = //Get the basket based on the session credentials
$view = new ShoppingBasketView($basket);
echo $view->render();
This approach is based on a component model, where the views are treated as composable components. In this schema you respect the object's boundaries and each view has a single responsibility.
Edit (Added based on the OP comment)
I'll assume that there is no way of organizing the views in subviews and that you need to render the basket id, order date and user name in a single line. As I said in the comment, for that case I would make sure that the "bad" access is performed in a single, well documented place, leaving the view unaware of this.
class MixedView
{
protected $basketId;
protected $orderDate;
protected $userName;
public function __construct($basketId, $orderDate, $userName)
{
//Set internal state
}
public function render()
{
return '<H2>' . $this->userName . "'s basket (" . $this->basketId . ")<H2> " .
'<p>Last order placed on: ' . $this->orderDate. '</p>';
}
}
class ViewBuilder
{
protected $basket;
public function __construct($basket)
{
$this->basket = $basket;
}
public function getView()
{
$basketId = $this->basket->getID();
$orderDate = $this->basket->getLastOrder()->getDate();
$userName = $this->basket->getUser()->getName();
return new MixedView($basketId, $orderDate, $userName);
}
}
If later on you rearrange your domain model and your ShoppingBasket class can't implement the getUser() message anymore then you will have to change a single point in your application, avoid having that change spread all over your system.
HTH
The Law Of Demeter is about calling methods, not accessing properties/fields. I know technically properties are methods, but logically they're meant to be data. So, your example of order.user.address.city seems fine to me.
This article is interesting further reading: http://haacked.com/archive/2009/07/13/law-of-demeter-dot-counting.aspx
I'm doing a basic exercise of object-oriented design for a simple use case: A Book can be tagged with many Tags.
I have many solutions, and I would like your input on which is better in term of OOD principles and maintanability.
Option 1
public class Book {
private String title;
//... other attributes
private List<Tag> tags;
}
The thing that bothers me is that we mixed core attributes of a Book with additional categorization or search data. I may have in the future a requirement where certain Books can't be tagged. In the future, the Book class can become bloated when I add more responsabilities: category, list of users that read it, ratings...
Option 2
public class TaggedBook extends Book {
private Book book;
private List<Tag> tags;
}
I think this is similar to the Decorator pattern, but I don't see it fit here because I'm not extending behavior.
Option 3
Decouple Books and Tags comnpletely, and use a service to retrieve Tags from a book (given each Book has a unique identifier)
List<Tag> TagService.getTags(Book book)
However, I don't find this solution very elegant (is it?), and I may have to send two queries: one to retrieve the book, the other for the tags.
I am planning on applying the best options to other requirements: A Book has a rating, a Book can be categorized...
I'm also planning on using a DMS to store Books and Tags objects. Since it's not a relations database, its schema will likely correspond to the class design.
Thank you
All three options can be valid and good choices for your class design. It all depends on the complete context/requirements. The requirement you listed are very likely not enough to make the "right" decision. For example, if your application is rather book centric and tags do not need to evolve or be authored independently from books, option 3 would probably introduce unnecessary complexity. If you design a public API that acts as a facade around your actual logic you still might go for option 1 or 2 even though internally both Book and Tag are totally decoupled aggregate roots. Scalability, performance, extensibilty ... those are all possible requirements that you need to balance and that will influence your design.
If you are looking for a good formalized methodology and guidance for class design for enterprise applications, I'd suggest you look into Domain Driven Design.
Also, do not design you classes for unknown future requirements. This will also again add useless complexity (think: cost). Just make sure you have enough unit test that cover your back when you need to refactor for new requirements.
The concept of decorator pattern fits well in your case.But I think strategy pattern
is more useful and effective in you case.If you don't know about strategy pattern then Take a look on This.It will give you a good idea on strategy pattern.If you need more suggestion or have any query then ask in comment.
Thank you
All the best..
If Books are not the only Entity in your Model that can be tagged. I'll go with this interface:
public interface Taggeable {
public List<Tag> getTags();
public void setTags (List<Tag> tags)
}
And
public class Book implements Taggeable {
//Book attributes and methods
The kinds of Books/Entities that can be Tagged only need to implement this interface. That way, you can have Book objects that allow tagging and others that doesn't. Also, the tagging mechanism can be used with other Objects of your model.
I think it would be better to mix pattern for a better solution. Remember a particular pattern only solves one particular problem.
My suggestion is to isolate different interfaces and join them accordingly. The base class should have the ability to query for supported interfaces, so that it can call the appropriate interface functions.
First interface is the query supported interface:
public interface QueryInterface {
public boolean isTaggable();
public boolean isRatable();
}
...next comes particular interfaces.
Suppose the first particular interface is taggable:
public interface Taggable {
public Vector<Tag> getTags();
public boolean addTag(Tag newTag);
}
...and the second one is rateable...
public interface Rateable {
public Rating getRating();
public void setRating(Rating newRating);
}
The plain old base class itself: :)
public class Book implements QueryInterface {
private String title;
public boolean isTaggable() {
return false;
}
public boolean isRateable() {
return false;
}
}
Now the special derived class which complies to the taggable interface:
public class TaggedBook extends Book implements Taggable {
private Vector<Tag> tags;
public Vector<Tag> getTags() {
return tags;
}
#override
public boolean isTaggable() {
return true;
}
public boolean addTag(Tag newTag) {
return tags.insert(newTag);
}
}
...and the different book which is rateable only:
public class RatedBook extends Book implements Rateable {
private Rating rating;
public Rating getRating() {
return rating;
}
public void setRating(Rating newRating) {
this.rating = newRating;
}
#override
public boolean isRateable() {
return true;
}
}
Hope this helps. :)
Option 1
The first solution supports the concept of a has-a relationship. I don't see that there is any drawback to this design. You say there is a possibility of code bloat when you add responsibilities to the class, however this is a completely separate issue (breaking the S in SOLID). A class with many members is not inherently a bad thing (It can sometimes be an indication that something has gone wrong, but not always).
The other problem you give is that in the future you might have a Book without Tags. Since I do not know the whole picture I am only guessing, but I would argue strongly that this Book would/could simply be a Book with 0 Tags.
Option 3
I think that this is the non OO way of doing things. Implementing a has-a relationship by association of some ID. I don't like it at all.
For each additional property you wanted to add to a Book you would need to also create an appropriate Service type object and make lots of additional and unnecessary calls with no benefit for doing so over Option 1 that i can see.
Another reason that i don't like this is that this implies that a Tag has a has-a relationship with books. I don't think that they do.
Option 2
This is not good in my opinion, but that is mostly because i think the decorator pattern was not designed for use in this sort of situation, and because you would likely need to make use of rtti to be able to use your resulting objects, or implement a lot of empty methods in your base class.
I think that your first solution is overwhelmingly the best. If you are worried about code bloat you may consider having a Tags object as a member of Book, which is responsible for searching itself (This also helps with the S in SOLID) and the same for any additional properties of Book. If a Book has no tags then Tags would simply return false when queried, and Book would echo that.
Summary
For such a simple problem, don't over think it. The basic principles of OO design (has-a, is-a) are the most important.
I would suggest to think about it as a design problem first, and then try to express the design in code.
So, we have to decide what classes (entities) we have. The Book is a class because is central to the problem, has distinct instances and, probably, several attributes and operations. The Tag may be both a value-object and a class.
Let us consider the first option. It can be a value object because it does not have internal structure, any operations, and its instances may not be distinct. Thus a Tag can be thought of as a String marker. This way, Book has an attribute, say, tags that contains a collection of tag values. Values can be added and removed without any restrictions. Books can be searched by tags where tags are supplied by value. It is difficult t get a complete list of tags or get all books for a specific tag.
Now, the second option. The Tag can also be a class because it is related to another class (Book) and its instances may be distinct. Then we have two classes: Book and Tag, and a 'many-to-many' association between them - TaggedWith. As you may know, association is a sort of a class itself besides being a relation. Instances of TaggedWith association (links) connect instances of Book and Tag. Next we have to decide which class will be responsible for managing correspondence (create, read, lookup, destroy, update...) between Book and Tag. Most natural choice here is to assign this responsibility to the association TaggedWith.
Lets write some code.
Option 1
public class Book {
private Collection<String> tags;
/* methods to work with tags, e.g. */
public void addTag(String tag) {...}
public String[] getAllTags() {...}
...
}
It may look complex, but actually similar code can just be generated from the design description in a couple of mouse clicks. On the other hand, if you use DB a lot of code here becomes SQL queries.
Option 2
public class Tag {
/* we may wish to define a readable unique id for Tag instances */
#Id
private String name;
/* if you need navigation from tags to books */
private Collection<Book> taggedBooks;
public Collection<Book> getTaggedBooks() {...}
public void addBook(Book book) {...} // calls TaggedWith.create(this, book)
public void _addBook(Book book) {...} // adds book to taggedBooks
....
/* I think you get the idea */
/* methods to work with tags */
public String getName() {...}
...
/* Tags cannot be created without id (i.e. primary key...) */
public Tag(String name) {...}
/* if you'd like to know all tags in the system,
you have to implement 'lookup' methods.
For this simple case, they may be put here.
We implement Factory Method and Singleton patterns here.
Also, change constructor visibility to private / protected.
*/
protected static HashMap<String, Tag> tags = ...; // you may wish to use a DB table instead
public static Tag getInstance(String name) {...} // this would transform to DAO for DB
}
public class Book {
/* if we need an id */
#Id // made up
private String bookId;
/* constructors and lookup the same as for Tag
If you wish to use a database, consider introducing data access layer or use ORM
*/
/* if you need navigation from Book to Tag */
private Collection<Tag> tags;
public Collection<Tag> getTags() {...}
...
}
public TaggedWith {
/* constructor and lookup the same as for Tag and Book (!) */
/* manage ends of the association */
private Book book;
private Tag tag;
public Book getBook() {...}
public Tag getTag() {...}
protected TaggedWith(Book book, Tag tag) {
this.book = book;
this.tag = tag;
book._addTag(tag); // if you need navigation from books to tags
tag._addBook(book); // if you need navigation from tags to books
}
/* if you need to search tags by books and books by tags */
private static Collection<TaggedWith> tagsBooks = ...;
public static TaggedWith create(Tag tag, Book book) {
// create new TaggedWith and add it to tagsBooks
}
}
I prefer the 3rd option, to separate them completely.
Books and tags have a mang-to-many relationship, by separating them, you can make it easier to make queries like "which books got tagged by 'Computer Science'".
Unless either the order of the tags on a book matters or a book can have the same tag twice, you should store your tags in a set rather than a list.
Once you've done that, I'd go with something like the third option. It seems to me that the books don't own the tags and the tags don't own the books (indeed, you'd want to look this up either way, probably). Later, when you want to associate other things with your books (e.g. reviews, ratings, libraries) you can create another association without modifying the book class.
I would do it totally different. Thinking a bit like labels in Gmail, I would make it so it would be easier to actually look for books with certain tags rather than find what tags are on the book. Namely, tags work as a filter to find books, not the other way around.
public interface ITaggable
{
string Name { get; }
}
public class Book : ITaggable
{
}
public class Tag
{
private List<ITaggable> objects;
private String name;
public void AddObject() {}
public void RemoveObject() {}
public void HasObject() {}
}
public class TagManager
{
private List<Tag> tags;
private void InitFromDatabase() {}
public void GetTagsForObject(o: ITaggable) {}
public void GetObjectsForTag(objectName: String) {} //
public void GetObjectsForTag(t: Tag) {} //
public void GetObjectsForTag(tagName: String) {} //
public void GetAllTags();
}
... somewhere else ...
public void SearchForTag(tag: Tag)
{
TagManager tagManager = new TagManager();
// Give me all tags with
List<ITaggable> books = tagManager.GetObjectsForTag("History");
}