every time you write a comment you failed. commented out code is an abomination that must be destroy before it spreads.
white space discipline is important Be consistent horizontal scrolls will not be tolerated(between 40 and 120 columns) keep file sizes under control average between 100 lines and never exceed 500
- Bags of functions that hide the implementation
- Use tell don't ask to avoid writting getters and setters
- When getters are necessary make sure you make sure you hide de implementation of the data by abtracting it
Manipulate private variables with public functions. From de outside a class is just a bunch of methods. From the outside looking in an object appears to have no observable state. But in most languajes we have getters and setters ???? If you expose through get/set you gave a bad design. An object who follows the discipline of tell don't ask do not need to expose getters. And then probably no need to have any setters neither.
The more variables manipulates a method of a class the most cohesive it is. Getters and setters only manipulates one variable. The more getters and setters a class have, the less cohesive a class is.
In those situations I want to have a getter.
Si por ejemplo queremos exponer la variable Car::gallonsOfGas what should we call that method ? -> getGallonsOfGas --> this exposes information of the implementation of the class. Users from the outside could infer that the class have a varible inside called gallonsOfGas.
There are a number of problems with being so specific. If we want to create a derivative class called DieselCar. DieselCar exposes a method getGallonsOfGas but diesel do not have Gas. What if we want a derivative called ElectricCar ??
When derivatives doesn't fit with the base something is wrong with that base. Often is that the base exposes some implementation that it shouldn't have. We could name the method in the base class -> getPercentFuelRemaining
What do you think the difference between a class and a data structure is ?
Is kind of the opposite of a class. It exposes data and do not have methods (It could exposes simple methods like getters, setters, navigation). They don't manipulate cohesive groups of variables. The software that manipulates data structures is the antithesis of tell don't ask. You can't ask a data structure to do something generic.
Data structures and switch statements are related as polymorphism and class are related.
When you see a switch statement you can be pretty sure there is data structure behind it.
Polymorphism of objects protects your client code from new kind of server code (objects protect you from new types). Switch statemetes exposes the changes in types. Whenever a new type is added all the switch statements needs to be modified. Client code needs to be modified.
When you add a new method to a base class code in the client needs to be modified. DataStructures and Switch statements on the other hand are inmune to the addition of new functions. When you add a new function only needs to add a switch on it. Nothing needs to be re compiled.
Classes protect as against new types but exposes to new methods
Data Structures protect as against new methods but exposes to new types.
We use Data Structures when methods are more likely to be added. We use Classes when types are more likely to be added.
Is there any way to protect from both ? This is called the Expression Problem.
Previously we discuss how to separate main from the rest of the application. This is a specific case of a much more general rule.
The code on the one side of the boundary is very different from the code on the other side of the boundary. Example Boundary that separates views from models, or the boundary that separates database from domain objects.
One side is concrete and the other side is abstract. E.g: Main is concrete and App is abstract(Main depends on App). Database is concrete and Domain objects is abstract(Database depends on Domain Objects)
Your database do not contain domain objects, they don't contian business objects, they don't contain any kind of objects at all. Databases contians data structures. And you cannot force a data structure to be an object.
Separate your domain objects from your database by putting a layer in between. That layer should depend upword on the application and downword on the database. The application should not know about the layer and definitively not know about the database.
What about object relation mappers ? -> they are not trully object relational mappers because there is no direct mapping between data structures and objects. These tools are relational tables to data structure mappers. What we'd like on the application side of the bundary are domain objects and the methods of those domain objects will be business rules. And it turns out that when you gather a bunch of business rule methods then you get classes that suprisingly they don't look like the database schema.
Most databases are design for the enterprise and not for a particular application.
In the app side of the boundary we can separate our selves from the application schema by actually designing the objects we'd like to use.These will be true objects with exposed methods and hidden data. This will make the application much more natural and easy to understand.