very simple problem, but i want to see how experts look at it.
This is just imaginary software just to understand OOP.
I have a school administration software. So I have classes
Student
ClassRoom
Teacher
Now I assign a teacher as class-teacher for a particular classroom. Thus
ClassRoom contains
Teacher classTeacher;
Student[] students;
Now the complete program is written and everything works fine ...
Problem:
Now what If the principal puts a new rule, that there should not exist a student to whom the Teacher is the Parent.
Now we need to bring more parameters and lot of changes in our code for a small requirement.
How should the design be in order for future changes in requirements (which will inevitably come) to only require minor changes in the code?
This should not be a big code change, this should be a validation change.
Psuedo-Code:
Class ClassRoom {
List<Student> students
Teacher teacher
ClassRoom(Teacher _teacher, List<Student> students) {
teacher = _teacher;
SetStudents(students);
}
void SetStudents(List<Student> _students) {
foreach (Student s in _students) {
if (validate(s)) {
students.add(s);
} else {
// error handling logic
}
}
}
void validate(Student student) {
if (student.parent == teacher) {
return false;
}
return true;
}
}
class Student : Person {
Person parent
}
class Teacher : Person { }
Sure you are going to have to go into the database and the codebase and add "Parent" properties to all your students. But that also shouldn't be too hard.
Related
I've been asked some kind of interesting questions related to OOP.
Here's the question.
Alice has started a restaurant and created software the determine the price of all the items on the menu
She started by creating a class for each menu item so that the price can be calculated using an interface.
interface HasPrice {
getPrice(): number;
}
class Ramen implements HasPrice {
getPrice() {
return 5;
}
}
class Spaghetti implements HasPrice {
getPrice() {
return 10;
}
}
She then decided there should be topping so she used the decorator pattern.
class RamenWithPork extends Ramen {
getPrice() {
super.getPrice() + 3;
}
}
This worked until she decided to expand the topping menu and it became too cumbersome to deal combinatorial amount of classes. How should she fix it?
follow up question: With all the choices, customers have started asking whether or not their choice of ingredients contains certain allergens.
Alice would prefer not to have to add a million methods to all her classes to specify true/false for each allergen. How can she add this check without having to add one function per allergen for each ingredient?
Language doesn't matter, it is generic object-oriented question(take java/C# etc). Take a simple concept.
A Person has a Car. The Person can drive the Car. Car doesn't usually drive or wander around, right? ``
But, usually in codes, we see methods like myCarObject.Drive().
Now when a Person is introduced, and the Person drives the car:
======================= First Way =================================
class Car{
int odometer;void drive(){ odometer++; }
}
class Person{
void driveCar(Car c) { c.drive(); }
}
========================================================================
================================ Alternative Way =======================
public Car{
int odometer; // car doesn't do the driving, it's the person, so no drive()
}
public Person{
void driveCar(Car c) { c.odometer++; }
}
========================== and other ways....============================
===========================================================================
So, my question is clear: what is the best way to design/implement/name methods in similar cases?
It's a bit difficult to make simplified examples like that make any sense, but here is an attemt:
A Car class would generally contain methods for the things that the object can do by itself with the information that it has, for example:
public class Car {
private bool engineOn;
public int Speed { get; private set; }
public void Start() { engineOn = true; Speed = 0; }
public void Accelerate() { Speed++; }
public void Break() { if (Speed > 0) Speed--; }
public void Stop() { Speed = 0; engineOn = false; };
}
A Person class would would manage a car by controlling the things that the car itself is not aware of in its environment. Example:
public class Person {
public void Drive(Car car, int speedLimit) {
car.Start();
while (car.Speed < speedLimit) {
car.Accelerate();
}
while (car.Speed > 0) {
car.Break();
}
car.Stop();
}
}
There are of course many different variations of how you can use OO in each situation.
If you wish to express your logic in a way that closely resembles human language semantics, you'll want to invoke an action or function on an entity which is logically capable of carrying it out.
When behavior cannot be placed on an object (in the sense that it has state), you put it in a Service or Utility class, or some similar construct. Authenticate is a classic example of something that doesn't make much sense to invoke on a user, or on any other object. For this purpose, we create an AuthenticationProvider (or service, whichever you prefer).
In your scenario of a Person and a Car, it's one object invoking behavior on another. person.Drive(car) would therefore make the most sense.
If a Person owns a Car (and a Car is always owned by a Person), then person.Drive() might be the only thing you need to do. The Drive() method will have access to the properties of person, one of which is its car.
An important thing to note here is the concept of loose coupling. In more complex scenario's, you don't want to all sorts of cross-references within your model. But by using interfaces and abstractions you'll often find yourself putting methods on objects where they don't really belong from a real-world perspective. The trick is to be aware of, and utilize a language's features for achieving loose coupling and realistic semantics simultaneously.
Keeping in mind that in a real application you'll have the bootstrapping code tucked away elsewhere, here is an example of how that might look like in C#:
We start off by defining interfaces for the things that can transport (ITransporter), and the things that can be transported (ITransportable):
public interface ITransportable
{
void Transport(Transportation offset);
}
public interface ITransporter
{
void StartTransportation(ITransportable transportable);
void StopTransportation(ITransportable transportable);
}
Note the Transportation helper class which contains the information necessary to re-calculate the current location of an ITransportable after it has been transported for a certain period of time with a certain velocity and whatnot. A simple example:
public class Transportation
{
public double Velocity { get; set; }
public TimeSpan Duration { get; set; }
}
We then proceed to create our implementations for these. As you might have guessed, Person will derive from ITransportable and Car derives from ITransporter:
public class Person : ITransportable
{
public Tuple<double, double> Location { get; set; }
private ITransporter _transporter;
void ITransportable.Transport(Transportation offset)
{
// Set new location based on the offset passed in by the car
}
public void Drive<TCar>(TCar car) where TCar : ITransporter
{
car.StartTransportation(this);
_transporter = car;
}
public void StopDriving()
{
if (_transporter != null)
{
_transporter.StopTransportation(this);
}
}
}
Pay close attention to what I did there. I provided an explicit interface implementation on the Person class. What this means is that Transport can only be invoked when the person is actually referenced as an ITransportable - if you reference it as a Person, only the Drive and StopDriving methods are visible.
Now the Car:
public class Car : ITransporter
{
public double MaxVelocity { get; set; }
public double Acceleration { get; set; }
public string FuelType { get; set; }
private Dictionary<ITransportable, DateTime> _transportations = new Dictionary<ITransportable, DateTime>();
void ITransporter.StartTransportation(ITransportable transportable)
{
_transportations.Add(transportable, DateTime.UtcNow);
}
void ITransporter.StopTransportation(ITransportable transportable)
{
if (_transportations.ContainsKey(transportable))
{
DateTime startTime = _transportations[transportable];
TimeSpan duration = DateTime.UtcNow - startTime;
var offset = new Transportation
{
Duration = duration,
Velocity = Math.Max((Acceleration*duration.Seconds), MaxVelocity)/2
};
transportable.Transport(offset);
_transportations.Remove(transportable);
}
}
}
Following the guidelines we set earlier, a Car will not have any (visible) methods on it, either. Unless you explicitly reference it as an ITransporter, which is exactly what happens inside of the Person's Drive and StopDriving methods.
So a Car here is just a Car. It has some properties, just like a real car, based on which you can determine a location offset after a person drove it for a certain amount of time. A Car cannot "Drive", "Start", or anything like that. A Person does that to a Car - a Car does not do that to itself.
To make it more realistic you would have to add all sorts of additional metadata that affect a Car's average velocity over a certain period of time on a certain route. Truth is, you probably won't end up modeling something like this anyway. I stuck with your model just to illustrate how you could retain natural language semantics if you were working with objects that make it challenging to do so.
An example of how these classes may be used by a client:
Person person = new Person();
Car car = new Car();
// car.Transport(); will not compile unless we explicitly
// cast it to an ITransporter first.
// The only thing we can do to set things in motion (no pun intended)
// is invoke person.Drive(car);
person.Drive(car);
// some time passes..
person.StopDriving();
// currentLocation should now be updated because the Car
// passed a Transportation object to the Person with information
// about how quickly it moved and for how long.
var currentLocation = person.Location;
As I already eluded before, this is by no means a good implementation of this particular scenario. It should, however, illustrate the concept of how to solve your problem: to keep the logic of "transportation" inside of the "transporter", without the need to expose that logic through public methods. This gives you natural language semantics in your client code while retaining proper separation of concerns.
Sometimes you just need to be creative with the tools you have.
In second case, it's like you're saying that the task of driving a car consist in incrementing the odometer. It's clearly not the driver's business, and a violation of encapsulation. The odometer should probably be an implementation detail.
In first case, the car maybe does not drive itself, but it advances, so you could use another verb. But car.advance() is maybe not how a Person drives cars... Even if it was thru vocal commands, the decoding of the command would probably result in a sequence of more basic commands.
I very much like the answer of Guffa which tries to address what driving a car could mean. But of course, you may have another context...
I am new to Laravel and a bit confused about some definitions of ORM.
I am currently working on a simple Trouble ticket management system, and here is my question :
(table: column, column,...)
tickets : id, description, equipment_id
equipments: id, name, vendor_id
vendor: id, name
This is a very short resume of my tables and its relations, following Laravel's conventions. How can I build these models?
Basically I need to retrieve, for example, how many tickets were opened to a certain vendor (how many times I called the vendor for support).
Thank you in advance
What zwacky said is entirely (edit: maybe not entirely correct in the end) true for close relations, but in your situation there is nested relation:
Vendor -> Equipment -> Ticket
Then to retrieve tickets for particular vendor you would define relation on Vendor model like this:
class Vendor extends Eloquent {
public function equipment()
{
return $this->hasMany('Equipment');
}
public function tickets()
{
return $this->hasManyThrough('Ticket', 'Equipment');
}
class Equipment extends Eloquent {
public function tickets()
{
return $this->hasMany('Ticket');
}
public function vendor()
{
return $this->belongsTo('Vendor');
}
class Ticket extends Eloquent {
public function equipment()
{
return $this->belongsTo('Equipment');
}
and to get count of total tickets for the vendor (not currently open):
Vendor::find($id) // retrieve particular vendor
->tickets()->count(); // get count on tickets table
// and this way you retrieve collection of related tickets
Vendor::find($id) // retrieve particular vendor
->tickets; // get Eloquent Collection
Also you may find it helpful: http://softonsofa.com/querying-relations-with-eloquent-in-laravel-4/
you'd need to declare these relationships within their models. e.g. your Ticket.php model could look like this:
class Ticket extends Eloquent {
public function equipment()
{
return $this->hasOne('Equipment');
}
public function vendor()
{
return $this->hasOne('Vendor');
}
...
}
for retrieval you'd do it like this:
foreach (Ticket::all() as $ticket) {
$ticket->vendor()->id;
}
check this section of the laravel docs.
edit: for the specific query how many tickets are open to a certain vendor:
Ticket::where('open', '=', 1)->vendor()->where('id', '=', 42);
are there general rules, common pitfalls, about object creation responsability?
how should i decide who is responsible of object creation?
sometimes it is obvious, sometimes not, i'm trying to avoid redundant code and limit only to the minimum necessary.
what i should ask to myself when i have to decide where to write the creation method?
class State
{
...
public [City] getCapitalCity()
{
return new City(this.capitalCityID);
}
}
class City
{
...
public static [City] getCapitalOf(State s)
{
return new City(s.capitalCityID)
}
}
thank you in advance
A flaw of your first method is that it creates a new City object for every call. Something like that would be more natural to me:
class State
{
protected [City] capitalCity;
...
public [City] getCapitalCity()
{
if (this.capitalCity == null) {
this.capitalCity = City::getCapitalOf(this);
}
return this.capitalCity;
}
}
class City
{
...
public static [City] getCapitalOf(State s)
{
return new City(s.capitalCityID)
}
}
Note that I kept both methods in place but delegated one to the other. Another thing, which is still unsolved after this change, is that you won't be able to exchange the City object, i.e. for a mock in unit testing. The dependency is hard-wired.
Talking about design patterns, for a loosely coupled design the only classes that instantiate objects should be factories.
If we apply that here, it might look like that:
class CityFactory
{
...
public static [City] createCapitalFromState(State s)
{
return new City(s.capitalCityID);
}
}
class State
{
protected [City] capitalCity;
...
public [City] getCapitalCity()
{
if (this.capitalCity == null) {
this.capitalCity = CityFactory::getCapitalOf(this);
}
return this.capitalCity;
}
}
class City
{
....
}
For the sake of simplicity I kept the factory method static, in reality you would have access to some instance of CityFactory. And this could easily be exchanged to yield different objects.
what i should ask to myself when i have to decide where to write the creation method?
Two things:
do I introduce a new hard-wired dependency?
could I extract object creation to an own class?
One could think that two domain objects like City and State are not the best example for decoupling exercises because they obviously will always be used together, right?
But if you think about it, it's not too far-fetched: Maybe at some point you will subclass or decorate your Cities to distinguish certain differences in behaviour. With a City factory you will only have to change the creation of cities at one point if you ever want to change it. And this is an important goal in OOD: if you have to change something, it should not be necessary to change it all over the place, but only at one point.
I would probably say that it depends entirely on how your classes are going to be used. In this case, I'd opt for the State.getCapitalCity() since it's more likely that a developer's workflow would be to inquire what the capital city is of a state object they already have.
My class design would probably look similar to the following. That way, I can go back and forth between the two entities if need be.
class State
{
...
public City CapitalCity()
{
return new City(this.capitalCityId);
}
}
class City
{
...
public State State()
{
return new State(this.stateId);
}
public bool IsCapitalCity()
{
return this.isCapitalCity;
}
}
I have the following classes:
class Person
{
public string Name { get; set; }
}
class Employee : Person
{
public int Salary { get; set; }
}
class Company
{
public IList<Person> PeopleWhoAreNotEmployees { get; set; }
}
Person and Employee are mapped using table-per-class-heirarchy strategy.
When I retrieve the PeopleWhoAreNotEmployees collection, I want it only to contain elements that are Person, and NOT Employees.
How can I (fluently) configure the collection to only retrieve elements of the super class?
I think it's something to do with the Polymorphism property, but I couldn't really figure out how to do that.
thanks,
Jhonny
EDIT:
following the discussion with Jamie, I feel I need to clarify that the case here isn't really Person and Employee, but more like Employee and HistoricalEmployee.
Meaning- when an employee 'dies', they're not really deleted, but they become HistoricalEmployee (with a few more attributes, such as termination date etc.).
Obviously, over time, the number of HistoricalEmployees will exceed the number of Employees by magnitudes, so I can't fetch all HistoricalEmployees when I only need current Employees.
Sorry for the ambigiuity of the original question...
J
P.S. I didn't change the original question since it would make the answer irrelevant. a new version of this question is available here
I don't think you can, but that's not how I would approach it anyway. I would use a private field for the collection and expose methods that filter the list. This is much easier to map and work with and performance will be fine if the collection is reasonably sized (I don't know what's reasonable but I wouldn't worry about it if it's < 1000). It would make it easier if you had an abstract PersonBase class that both Person and Employee extend so that you don't have to deal with uncertainty that a Person might be an Employee.
public class Company
{
private IList<Person> _allPeople;
public IEnumerable<Employee> Employees()
{
return _allPeople.OfType<Employee>();
}
public IEnumerable<Person> PeopleWhoAreNotEmployees()
{
return _allPeople.Where(x => !(x is Employee));
}
}
EDIT:
In response to your comment, the filtering would take place in the class. The private collection would cause all the People to be loaded, and the properties would dynamically filter that collection. The mapping wold look like:
public class CompanyMap : ClassMap<Company>
{
public CompanyMap ()
{
// only collection is shown w/o cascade option
HasManyToMany(x => x.Person).Access.CamelCaseField(Prefix.Underscore);
}
}
what I ended up doing was using a 'where' clause on my property.
the fluent configuration looks like so:
mapping.HasMany(x => x.Employees)
.Where("IsFired = 0")